Hi Daniel, > > > I'm not so sure doing the home/roaming on service level is > > > correct. Consider following case: I'm travelling from Germany to Italy > > > for a couple of days and then to Switzerland. The roaming statistics > > > would not distinguish between Italy and Switzerland. The prolbem is > > > that the roaming costs are different for both countries. So I'd like > > > to have different statistics for both countries. > > > > > > If I understand correctly the statistic counters should be in the > > > Network objects and not in the Service objects. Counter exposes the > > > Service as statistic source. Service could act as statistic proxy for > > > Network. In this case the Counter API doesn't have to change. But how > > > does this work out with different roaming counters? Counter API has > > > justs one home and _one_ roaming dict. Roaming counters could then > > > jump when we roam from one Network to another. At least the current > > > roaming ID would be nice to have. But then why not just expose only > > > one active statistic dictionary with an ID? It doesn't matter if home > > > or roaming. > > > > the network structs will be removed soon. We wanna simplify the internal > > APIs of ConnMan on a massive scale. > > Okay, that's good to know. > > > And while I see your point with different countries and different > > pricing models, it doesn't really matter. The difference here is home vs > > non-home (roaming) counting. Not counting on a country level. > > The point I'd like to make is to distighuish only between home and > roaming might not be enough. I have the feeling that naming even > naming home/roaming is not really needed. See below.
let me put is this way. The current Counter API is for realtime counters that the user is going to see. So at that point the user normally knows in which country they are. And then only the difference between being on a flat-rate data plan or do I have to pay by kb/minute matters. We give two different dicts to the user who wants to display these kind of information. And then it is up to the UI to present these properly. It gets all the information needed at this point. And if the UI wants to sum up home and roaming counters to display the magic summary. And just toggle colors for home/roaming, then that is fine as well. At least the UI has the chance to do so. As a side note, this fulfills the requirements from the operators. Mainly since they care about their own traffic and others. This doesn't mean that we stop here. As I mentioned in the long run I wanna monitor sessions and not just counting bytes. To summarize, once we have home vs. roaming counters working, we can mark this done. And then move on with doing proper session counting. > > The main focus is to figure out how much traffic/time you have spent > > outside your home network. > > Agreed ... > > > In the end, I do wanna record sessions and provide these information > > back to the user. So first of all, we have to be able to be doing > > exactly this. > > ... which will provide the additional information needed to say how > much traffic/time has been spend on which network. Later, it is > possible to merge all counters together into home/roaming statistic, > so that application don't have to do it. > > > I looked at SQLite and RRD and both are a bit too generic and drag in a > > bit too much dependencies for my taste. > > I also looked at RRD and I think it's quite complex. Especially the > code for manipulating data only partially loaded into memory. I don't > know how much data we should expect to handle. If there is only need > for a few kbytes of memory than the code for manipulating offline data > is propably larger than the data structure itself :) > > > Current idea is to store everything under /var/lib/connman/counter/ with > > the service identifier (wifi_xxxx_managed_none etc.) and then suffix > > like *.info for the summary and *.data for the actual session data. > > Okay, let me brainstorm a bit... > > What kind of information would be stored in *.data? > - timestamp > - number of bytes/... transfered > - online time > > I assume only binary data so that an entry is fixed sized (increase > performance and reduce code size). The new entries are always appended. > > A new entry is added when the Counter accuracy/period threshold is > reached. > > With above probosal it's not clear when a session starts/stopps. Is > this needed? > > Then *.info would then would be something like this: > - service name > - number of bytes/... transfered > - online time > > for a given period. The fields are updated in place? *.info has to > compacted now and then. All *.data files have to parsed again adn > again? > > I wonder how many disk access this solution introduces, especially for > the current day information. I assume the smallest unit is day. Maybe > this information could just be hold in memory so that there aren't to > many read operation from the disk (yeah, I know, flash nowadays :)). Actually the idea is to get 90% or more guarantee that these information are persistent. So crashes or unexpected battery removal doesn't loose data for a whole day. So as a drawback we will introduce some IO activity for storing these. This is in relation to the battery life and here we have to do some work in figuring out what is the best ratio for battery life vs. persistent accuracy. Also with the new kernel APIs Samuel is working on we can get notified when x period of time has passed by with x number of packets. That way we might be able to reduce this properly down to the bare minium of IO activity that we need. There is still some guess work on my side that this will work out. I hope it does, but until we try, we won't know. > > When we have that, then we need to think about how we can present this > > to an end user. And my idea here is that we just present it via some > > sort of timeline. Simple example would be monthly or daily etc. > > Okay. Maybe the *.info should already be in the right form so connman > doesn't have to parse/format a lot information if a client requests > them. > > Sorry that I have more question then answers. Maybe tomorrow I have > more great(*) ideas. Your point of view is as good as mine right now. There are lot of details we have to figure out. But in general, I want a consistent, simple and block based approach for the *.data file. That works nicely with Linux and it VFS. And then *.info contains all meta data. I was also thinking that we just store things in *.data and then every day process that file and write a summary in *.info for later use. So some post-processing might be our best way to tackle this. Regards Marcel _______________________________________________ connman mailing list [email protected] http://lists.connman.net/listinfo/connman
