844774 - NetworkStatistics API needs a consistent way to manage data after a clock change

Status: RESOLVED FIXED

(Firefox OS Graveyard :: General, defect)

Description

[Salvador de la Puente González [:salva]]

We need a well defined behaviour when updating network statistics database after a clock change. After a clock change, no data should be lost but database must keep itself consistent. The sequence of samples timestamps must keep growing despite clocks changes to past.

Comment 1

[Gene Lian (I already quit Mozilla)]

Adding an observer for "system-clock-change" might help.

Comment 2

[Salvador de la Puente González [:salva]]

Undoubtedly, can you paste a URL with the documentation or details, please?

Comment 3

[Gene Lian (I already quit Mozilla)]

Please trace the |kSysClockChangeObserverTopic| in dom/system/gonk/RadioInterfaceLayer.js, which can help you know the dynamic change of system clock time. Adding an observer for it and then you can update your DB records whenever a time change is encountered.

Comment 4

[Salvador de la Puente González [:salva]]

After thinking about this and having an offline discussion beetwen Albert and me, we can adress the problem in two ways:

One is as follows: if new data have happened before the last recorded sample (i.e. the user changed the clock back so the new information is in the past) then store it in the **last sample**.

The other one is to listen for `kSysClockChangeObserverTopic` in order to know when the clock has changed and rebuild the timeline storing the values with an accurate timestamp independent on user changes.

Although we need a more formal defintion about databse consistency we can say one the requirement is the all data should be indexed as a monotonic growing serie. Both solutions meet this requirement but the second one keeps more information as it is able to store new usage in the moment it really happened while the first one is not able to exactly determine when new usage happened so it uses always the last sample instead.

Having in mind the current implementation of the gaia client we will have the following problems with the second approach:

- Client must track stats for different SIMs because it is not yet implemented in Gecko, and without the knowledge of the stored timestamp it won't be able to do it properly.

- Suppose you set the billing period (this is a front-end only concept) from day 1 to day 7, At the day 3, you change the clock 24 hours before (from day 3 to day 2).  When asking from period 1 - 7. What should it be returned? Data for days 1 to 7?  For days 2 to 8? Queries can only refer user / system clock as the client is not aware about changes in the system clock.

To summarize, for simplicity we prefer to implement the first option despite we know it loose some information (about when the data usage exactly happened). And also a better solution will imply big changes for Gecko and Gaia parts that we supose will not be accepted now.

Comment 5

[Albert [:albert]]

Attachment: Merge new sample with last one when clock has changed back

Comment 6

[Andrea Marchesini [:baku]]

Comment on attachment 721114 [details] [diff] [review]
Merge new sample with last one when clock has changed back

Review of attachment 721114 [details] [diff] [review]:
-----------------------------------------------------------------

It looks good. But I'm not a reviewer for this component. Kyle, can you take a look?

Comment 7

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/3b1334f16328

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/3b1334f16328

Comment 9

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g18/rev/2944420ff12b

Comment 10

[Salvador de la Puente González [:salva]]

This patch is no in v1.0.1 as you can see in the flags but it is causing bug 846402 which in nominated tef+, so renominating.

Comment 11

[Daniel Coloma:dcoloma]

Marking v1.0.1 as affected and tef+ as this is required to fix bug 846402

Comment 13

[Francisco Jordano [:arcturus] [:francisco]]

mmm

should we live this bug as resolved fixed, ask for a tef? (cause is blocking an already tef+) and mark status-b2g18-v1.0.1 as affected, for better understanding?

:)

Comment 14

[Francisco Jordano [:arcturus] [:francisco]]

(In reply to Francisco Jordano [:arcturus] from comment #13)
> mmm
> 
> should we live this bug as resolved fixed, ask for a tef? (cause is blocking
> an already tef+) and mark status-b2g18-v1.0.1 as affected, for better
> understanding?
> 
> :)

Sorry, forget my previous comment, Daniel already did this 24 seconds ago.
Thanks!

Comment 15

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/cea4b761bbc3