New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 887183 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

can the choice of accumulation intervals in cumulative metrics bias stats?

Project Member Reported by semenzato@chromium.org, Sep 20

Issue description

I suspect that the current implementation of cumulative metrics can produce incorrect results.

Users of the cumulative metrics library select an update interval (for instance: 5 minutes) and an accumulation interval (for instance: 24 hours).  At the end of each update interval, a user-provided callback accumulates some quantity (for instance: time spent on WiFi during that interval).  At the end of each accumulation interval, a user-provided callback sends the accumulated quantity as a UMA sample.

So far so good.  The problem is that when the accumulation interval ends, the device may be suspended or off.  (It's exactly the same whether it's suspended or off, because all accumulated values persist across reboots.)  Eventually the device is woken up or restarted (or neither, but then we don't really care). At that point it notices that time has passed and invokes the accumulation callback.

So far, still so good.  However, at this time the library resets the start time of the following accumulation period to the current time.  This seems incorrect, as shown in the following example.

Alice is cramming for an exam.  She works on her Chromebook 20 hours a day, always on wifi, and sleeps 4 hours.  In 10 days her laptop sends 10 samples of 20 hours each.

Bob is also cramming. He works 22 hours per day, but he's a slob (no gender stereotyping is meant here) and then sleeps 8 hours (I know---he is mostly out of sync with day/night, but people like that do exist).  In 10 days (240 hours) his laptop sends 8 samples of 22 hours each.

However, if his laptop was always on, but with wifi disconnected for those 8 hours every 30, we'd see a different result:

Assume he starts at 00:00 on the first day, and ends at 22:00.  That produces a sample of 22 hours on the first day.

On the second day he starts at 06:00 and is still working at 24:00, so a sample of 18 hours is sent.

On the third day, a sample of 16 hours is sent, etc.  In the end 10 samples are sent, averaging 17.6 hours/day.

This seems more "correct".  However I have to admit that I am a bit confused about how these results will be used and interpreted.


 
Cc: tbroch@chromium.org
Probably best to ask some people who look at these metrics (if anyone does). What are some of the metrics that are affected?
Status: Assigned (was: Untriaged)
This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this.

Sign in to add a comment