Add UMA to measure request latency time.

Add UMA to measure request latency time.

Now that we are actually using the scheduler and GCM Network Manager,
add the UMA to measure how long the user's request took from request
until the network came back.

BUG=597364
Committed: https://crrev.com/1ea1c6e4c0b98c497cb518a4454ddf3bb6fb76b2
Cr-Commit-Position: refs/heads/master@{#397730}

[Pete Williamson, 2016-06-02 00:27:28]

The CQ bit was checked by petewil@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-06-02 00:28:31]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2032833002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/2032833002/1

[commit-bot: I haz the power, 2016-06-02 01:48:33]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-06-02 01:48:34]

Dry run: Try jobs failed on following builders:
  linux_chromium_chromeos_ozone_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Pete Williamson, 2016-06-02 20:49:51]

The CQ bit was checked by petewil@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-06-02 20:51:19]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2032833002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/2032833002/1

[Pete Williamson, 2016-06-02 20:53:38]

petewil@chromium.org changed reviewers:
+ dougarnett@chromium.org

[Pete Williamson, 2016-06-02 20:53:38]

petewil@chromium.org changed required reviewers:
+ dougarnett@chromium.org

[dougarnett, 2016-06-02 22:32:54]

lgtm

Would like to touch base about why elapsed time since boot is preferred over
System.currentTimeMillis().

https://codereview.chromium.org/2032833002/diff/1/chrome/android/java/src/org...
File
chrome/android/java/src/org/chromium/chrome/browser/offlinepages/OfflinePageUtils.java
(right):

https://codereview.chromium.org/2032833002/diff/1/chrome/android/java/src/org...
chrome/android/java/src/org/chromium/chrome/browser/offlinepages/OfflinePageUtils.java:209:
public static void recordWakeupUMA(Context context, long millisSinceBootTask) {
wonder if ms since boot is right approach after all if/when we persist
scheduling across reboots. Trade off bad samples when clock is updated vs. bad
samples across reboots?

[Pete Williamson, 2016-06-02 22:39:05]

petewil@chromium.org changed reviewers:
+ holte@chromium.org

[Pete Williamson, 2016-06-02 22:39:06]

Holte: Please review changes to Histograms.xml

This is for a feature where we will save web pages for use while the phone has
no connectivity.  The user can request a page while offline, and we are
measuring the time until it can be made avaialble (goverened largely by how long
the phone stays offline).  We're adding this UMA to see the distribution of how
long it is until the user gets access to the page.  This is intended for
emerging markets such as India and Indonesia.   Details are at:
go/chrome-background-offlining

[Steven Holte, 2016-06-02 23:22:12]

lgtm

[Pete Williamson, 2016-06-02 23:24:19]

On 2016/06/02 22:32:54, dougarnett wrote:
> lgtm
> 
> Would like to touch base about why elapsed time since boot is preferred over
> System.currentTimeMillis().
> 
>
https://codereview.chromium.org/2032833002/diff/1/chrome/android/java/src/org...
> File
>
chrome/android/java/src/org/chromium/chrome/browser/offlinepages/OfflinePageUtils.java
> (right):
> 
>
https://codereview.chromium.org/2032833002/diff/1/chrome/android/java/src/org...
>
chrome/android/java/src/org/chromium/chrome/browser/offlinepages/OfflinePageUtils.java:209:
> public static void recordWakeupUMA(Context context, long millisSinceBootTask)
{
> wonder if ms since boot is right approach after all if/when we persist
> scheduling across reboots. Trade off bad samples when clock is updated vs. bad
> samples across reboots?

I don't have any particular preference, BauerB expressed a preference for
SystemClock.elapsedTime during code reveiw, so I just changed it instead of
arguing.  To me it seems like the error due to the user adjusting the wall clock
will happen less often than the error due to the user rebooting, so I have a
mild preference for adjusting the wall clock.  If you have a strong preference,
I'll be happy to change it back in a future changelist.

[dougarnett, 2016-06-02 23:38:54]

On 2016/06/02 23:24:19, Pete Williamson wrote:
> On 2016/06/02 22:32:54, dougarnett wrote:
> > lgtm
> > 
> > Would like to touch base about why elapsed time since boot is preferred over
> > System.currentTimeMillis().
> > 
> >
>
https://codereview.chromium.org/2032833002/diff/1/chrome/android/java/src/org...
> > File
> >
>
chrome/android/java/src/org/chromium/chrome/browser/offlinepages/OfflinePageUtils.java
> > (right):
> > 
> >
>
https://codereview.chromium.org/2032833002/diff/1/chrome/android/java/src/org...
> >
>
chrome/android/java/src/org/chromium/chrome/browser/offlinepages/OfflinePageUtils.java:209:
> > public static void recordWakeupUMA(Context context, long
millisSinceBootTask)
> {
> > wonder if ms since boot is right approach after all if/when we persist
> > scheduling across reboots. Trade off bad samples when clock is updated vs.
bad
> > samples across reboots?
> 
> I don't have any particular preference, BauerB expressed a preference for
> SystemClock.elapsedTime during code reveiw, so I just changed it instead of
> arguing.  To me it seems like the error due to the user adjusting the wall
clock
> will happen less often than the error due to the user rebooting, so I have a
> mild preference for adjusting the wall clock.  If you have a strong
preference,
> I'll be happy to change it back in a future changelist.

My intuition is that reboots due to battery losing charge or freeing up stuck
phone or other
are more likely than meaningful clock updates so currentTimeMillis() seems
preferable to me.
It shouldn't matter though until we support persisted schedule tasks.

[commit-bot: I haz the power, 2016-06-03 03:09:25]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-06-03 03:09:26]

Dry run: This issue passed the CQ dry run.

[Pete Williamson, 2016-06-03 16:44:35]

The CQ bit was checked by petewil@chromium.org

[commit-bot: I haz the power, 2016-06-03 16:45:08]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2032833002/1

[commit-bot: I haz the power, 2016-06-03 16:49:46]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-06-03 16:51:35]

Description was changed from

==========
Add UMA to measure request latency time.

Now that we are actually using the scheduler and GCM Network Manager,
add the UMA to measure how long the user's request took from request
until the network came back.

BUG=597364
==========

to

==========
Add UMA to measure request latency time.

Now that we are actually using the scheduler and GCM Network Manager,
add the UMA to measure how long the user's request took from request
until the network came back.

BUG=597364

Committed: https://crrev.com/1ea1c6e4c0b98c497cb518a4454ddf3bb6fb76b2
Cr-Commit-Position: refs/heads/master@{#397730}
==========

[commit-bot: I haz the power, 2016-06-03 16:51:36]

Patchset 1 (id:??) landed as
https://crrev.com/1ea1c6e4c0b98c497cb518a4454ddf3bb6fb76b2
Cr-Commit-Position: refs/heads/master@{#397730}