Add xml entries for Networks.* UMA histograms

Add xml entries for Networks.* UMA histograms

BUG=419867
R=jar@chromium.org

Committed: https://crrev.com/20e0c25693e5c1896b24eb902af058eb0691c9cd
Cr-Commit-Position: refs/heads/master@{#300689}

[stevenjb, 2014-10-20 20:26:42]

stevenjb@chromium.org changed reviewers:
+ jar@chromium.org, quiche@chromium.org

[jar (doing other things), 2014-10-20 21:14:29]

jar@chromium.org changed reviewers:
+ asvitkine@chromium.org
- jar@chromium.org

[jar (doing other things), 2014-10-20 21:14:29]

Asvitkine@ is a better (faster?) reviewer in general... added him.

https://codereview.chromium.org/663223003/diff/1/tools/metrics/histograms/his...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/663223003/diff/1/tools/metrics/histograms/his...
tools/metrics/histograms/histograms.xml:20766: +    Number of private remembered
(preferred) networks on Chrome OS.
I assume "remembered" means the count that are persisted at machine shutdown. 
Is that correct? IF not, please indicate when this tally is recorded (same thing
for histogram above).

In fact.. it would be good no matter what to be completely clear about when this
sample is recorded (same for histogram above).

https://codereview.chromium.org/663223003/diff/1/tools/metrics/histograms/his...
tools/metrics/histograms/histograms.xml:20772: +  <summary>Number of visible
(in-range) networks on Chrome OS.</summary>
Can you indicate when this stat is calculated? At startup? Sum across a process
run, recorded just before shutdown? Every N minutes?

[stevenjb, 2014-10-20 21:30:04]

https://codereview.chromium.org/663223003/diff/1/tools/metrics/histograms/his...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/663223003/diff/1/tools/metrics/histograms/his...
tools/metrics/histograms/histograms.xml:20766: +    Number of private remembered
(preferred) networks on Chrome OS.
On 2014/10/20 21:14:29, jar wrote:
> I assume "remembered" means the count that are persisted at machine shutdown. 
> Is that correct? IF not, please indicate when this tally is recorded (same
thing
> for histogram above).
> 
> In fact.. it would be good no matter what to be completely clear about when
this
> sample is recorded (same for histogram above).

Included when the stat is updated for all three stats.

https://codereview.chromium.org/663223003/diff/1/tools/metrics/histograms/his...
tools/metrics/histograms/histograms.xml:20772: +  <summary>Number of visible
(in-range) networks on Chrome OS.</summary>
On 2014/10/20 21:14:29, jar wrote:
> Can you indicate when this stat is calculated? At startup? Sum across a
process
> run, recorded just before shutdown? Every N minutes?

Acknowledged.

[jar (doing other things), 2014-10-20 22:08:43]

https://codereview.chromium.org/663223003/diff/20001/tools/metrics/histograms...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/663223003/diff/20001/tools/metrics/histograms...
tools/metrics/histograms/histograms.xml:20760: +    time the network list
changes.
Thanks... that makes it clearer... but does leave me wondering what this stat
will mean?

I suspect that if a ton of users have a dozen networks listed, but never change
them, then you'll get no samples from them.

Similarly, a "silly" user that wanted to "keep the list short and clean" and
constantly deletes unused access points, will provide <sadly> the bulk of the
samples!?!

How do you plan to use this stat? What do you expect it to show, given the
biases? how do you plan on distinguishing the sources of bias?

Have you considered alternatively, or additional doing something like:

a) A histogram that samples this no more than once per day?  This would get
"more" samples from folks that use the browser "every day."

b) A histogram that samples this after N hours of running the browser? This gets
extra samples from heavy users (or at least users that leave their CrOS or
browser "on").

c) A histogram that samples this after P pages have been loaded (use page load
metrics to drive).  This biases samples towards "heavy users" or "proportional
to usage."

[stevenjb, 2014-10-20 22:18:11]

On 2014/10/20 22:08:43, jar wrote:
>
https://codereview.chromium.org/663223003/diff/20001/tools/metrics/histograms...
> File tools/metrics/histograms/histograms.xml (right):
> 
>
https://codereview.chromium.org/663223003/diff/20001/tools/metrics/histograms...
> tools/metrics/histograms/histograms.xml:20760: +    time the network list
> changes.
> Thanks... that makes it clearer... but does leave me wondering what this stat
> will mean?
> 
> I suspect that if a ton of users have a dozen networks listed, but never
change
> them, then you'll get no samples from them.
> 
> Similarly, a "silly" user that wanted to "keep the list short and clean" and
> constantly deletes unused access points, will provide <sadly> the bulk of the
> samples!?!
> 
> How do you plan to use this stat? What do you expect it to show, given the
> biases? how do you plan on distinguishing the sources of bias?
> 
> Have you considered alternatively, or additional doing something like:
> 
> a) A histogram that samples this no more than once per day?  This would get
> "more" samples from folks that use the browser "every day."
> 
> b) A histogram that samples this after N hours of running the browser? This
gets
> extra samples from heavy users (or at least users that leave their CrOS or
> browser "on").
> 
> c) A histogram that samples this after P pages have been loaded (use page load
> metrics to drive).  This biases samples towards "heavy users" or "proportional
> to usage."

This was implemented some time ago but was not documented. The intention here is
simply to rectify that.

The intention of the stats were to get a general idea of how many visible /
remembered networks users have. Sampling any time the list changes (which will
be a minimum of once per session) seemed to be as accurate a method as any and
is by far the simplest to implement and maintain.

[jar (doing other things), 2014-10-21 02:15:32]

On 2014/10/20 22:18:11, stevenjb wrote:
> On 2014/10/20 22:08:43, jar wrote:
> >
>
https://codereview.chromium.org/663223003/diff/20001/tools/metrics/histograms...
> > File tools/metrics/histograms/histograms.xml (right):
> > 
> >
>
https://codereview.chromium.org/663223003/diff/20001/tools/metrics/histograms...
> > tools/metrics/histograms/histograms.xml:20760: +    time the network list
> > changes.
> > Thanks... that makes it clearer... but does leave me wondering what this
stat
> > will mean?
> > 
> > I suspect that if a ton of users have a dozen networks listed, but never
> change
> > them, then you'll get no samples from them.
> > 
> > Similarly, a "silly" user that wanted to "keep the list short and clean" and
> > constantly deletes unused access points, will provide <sadly> the bulk of
the
> > samples!?!
> > 
> > How do you plan to use this stat? What do you expect it to show, given the
> > biases? how do you plan on distinguishing the sources of bias?
> > 
> > Have you considered alternatively, or additional doing something like:
> > 
> > a) A histogram that samples this no more than once per day?  This would get
> > "more" samples from folks that use the browser "every day."
> > 
> > b) A histogram that samples this after N hours of running the browser? This
> gets
> > extra samples from heavy users (or at least users that leave their CrOS or
> > browser "on").
> > 
> > c) A histogram that samples this after P pages have been loaded (use page
load
> > metrics to drive).  This biases samples towards "heavy users" or
"proportional
> > to usage."
> 
> This was implemented some time ago but was not documented. The intention here
is
> simply to rectify that.
> 
> The intention of the stats were to get a general idea of how many visible /
> remembered networks users have. Sampling any time the list changes (which will
> be a minimum of once per session) seemed to be as accurate a method as any and
> is by far the simplest to implement and maintain.

OK... so you're not adding a new stat... but trying to document a long(?)
forgotten existing stat.

LGTM.

...but I'll add one more question:
Why is this "sampled once per session" when you said it is "sampled when it
changes?"

Does it really change during each session?... or should you adjust the prose?

[jar (doing other things), 2014-10-21 02:17:04]

jar@chromium.org changed reviewers:
+ jar@chromium.org

[jar (doing other things), 2014-10-21 02:17:05]

OK... so you're not adding a new stat... but trying to document a long(?)
forgotten existing stat.

LGTM.

...but I'll add one more question:
Why is this "sampled once per session" when you said it is "sampled when it
changes?"

Does it really change during each session?... or should you adjust the prose?

[stevenjb, 2014-10-21 15:33:50]

On 2014/10/21 02:17:05, jar wrote:
> OK... so you're not adding a new stat... but trying to document a long(?)
> forgotten existing stat.
> 
> LGTM.
> 
> ...but I'll add one more question:
> Why is this "sampled once per session" when you said it is "sampled when it
> changes?"
> 
> Does it really change during each session?... or should you adjust the prose?

The network list changes any time new wifi networks come in range (e.g. a laptop
is moved to a new location), or when a network is configured or forgotten
(statistically infrequent). This will happen at -least- once per session (the
initial list), but generally more often than that. Again, the intention was to
collect a) an idea of the "typical" number of visible/remembered networks, and
b) an approximate frequency if edge cases (e.g. 50+ visible networks).

[stevenjb, 2014-10-21 15:33:56]

The CQ bit was checked by stevenjb@chromium.org

[commit-bot: I haz the power, 2014-10-21 15:35:03]

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

[jar (doing other things), 2014-10-21 16:15:33]

On 2014/10/21 15:33:50, stevenjb wrote:
> On 2014/10/21 02:17:05, jar wrote:
> > OK... so you're not adding a new stat... but trying to document a long(?)
> > forgotten existing stat.
> > 
> > LGTM.
> > 
> > ...but I'll add one more question:
> > Why is this "sampled once per session" when you said it is "sampled when it
> > changes?"
> > 
> > Does it really change during each session?... or should you adjust the
prose?
> 
> The network list changes any time new wifi networks come in range (e.g. a
laptop
> is moved to a new location), or when a network is configured or forgotten
> (statistically infrequent). This will happen at -least- once per session (the
> initial list), but generally more often than that. Again, the intention was to
> collect a) an idea of the "typical" number of visible/remembered networks, and
> b) an approximate frequency if edge cases (e.g. 50+ visible networks).

OK... so "coming and going" from reachable-range of an AP can trigger a sample. 
That will bias the heck out of this metric.  For instance, if you are "in
range," in a dense environment, of say 50 APs, I *BET* that some are coming and
going, even if you don't move! That would mean those folks would give a TON of
samples.  In contrast, if you live in the country, out of range of your
neighbor, you'd tend to rarely give a sample (you'd just have your home's AP in
range... with no noise or competition).

You might get a tiny bit of normalization by looking at how many users (re:
check the "user count" button) provided a sample in each bucket.  It is
plausible that you could also assume that the sample rate for a user that "see"
N APs is roughly N times higher than a user that sees 1 AP (this is sort of like
doing repair for "random incidence" bias).   .... but I suspect the stat will be
very confused.

Good luck!  YMMV (a lot!)

[commit-bot: I haz the power, 2014-10-21 16:56:44]

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

[commit-bot: I haz the power, 2014-10-21 16:56:45]

Try jobs failed on following builders:
  linux_chromium_rel_swarming on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[stevenjb, 2014-10-22 16:49:02]

Committed patchset #2 (id:20001) manually as
20e0c25693e5c1896b24eb902af058eb0691c9cd (presubmit successful).

[commit-bot: I haz the power, 2014-10-22 16:49:02]

Patchset 2 (id:??) landed as
https://crrev.com/20e0c25693e5c1896b24eb902af058eb0691c9cd
Cr-Commit-Position: refs/heads/master@{#300689}