Change kMaxLowEntropySize to have 8000 values instead of 8192.

Change kMaxLowEntropySize to have 8000 values instead of 8192.

This maps much better to percentages people actually use for
experiments (e.g. 1%) without causing an uneven distribution
and thus a source of non-uniformity.

Re-generates the low entropy source values for users who have
it outside the new range.

BUG=252283
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=207865

[Ilya Sherman, 2013-06-21 01:12:53]

https://codereview.chromium.org/17499002/diff/43001/chrome/browser/metrics/me...
File chrome/browser/metrics/metrics_service.cc (right):

https://codereview.chromium.org/17499002/diff/43001/chrome/browser/metrics/me...
chrome/browser/metrics/metrics_service.cc:1048: // before the range was switched
to [0, 8191] and then [0, 7999]. Map 8192
nit: "and then [0, 7999]" -> "and then to [0, 7999]"

https://codereview.chromium.org/17499002/diff/43001/chrome/browser/metrics/me...
chrome/browser/metrics/metrics_service.cc:1050: // low entropy source for old
values in the [8000, 8191] range.
I wonder whether it's really worth keeping this extra bit of logic around just
to support users who might have not been migrated yet.  That's probably not very
many users, and they'd simply be re-shuffled -- is that so bad / worth keeping
this tweak around for?

[Alexei Svitkine (slow), 2013-06-21 04:41:30]

I'd like to land this tomorrow if possible.

Given my reply to your comment below, are you okay with the change otherwise
assuming I address your comment nit tomorrow? (If so, would appreciate a lgtm so
that I can cq it tomorrow when you're not around yet.)

https://codereview.chromium.org/17499002/diff/43001/chrome/browser/metrics/me...
File chrome/browser/metrics/metrics_service.cc (right):

https://codereview.chromium.org/17499002/diff/43001/chrome/browser/metrics/me...
chrome/browser/metrics/metrics_service.cc:1050: // low entropy source for old
values in the [8000, 8191] range.
On 2013/06/21 01:12:53, Ilya Sherman wrote:
> I wonder whether it's really worth keeping this extra bit of logic around just
> to support users who might have not been migrated yet.  That's probably not
very
> many users, and they'd simply be re-shuffled -- is that so bad / worth keeping
> this tweak around for?

It is. We never migrated those users to have the new pref value, we just used %
to map them, but never re-saved the pref.

It's important to do this so that the 0th bucket remains uniform with respect to
the other buckets, else it would have fewer users.

[Ilya Sherman, 2013-06-21 04:48:34]

Ok, fair enough.  LGTM.

[Alexei Svitkine (slow), 2013-06-21 14:29:09]

https://codereview.chromium.org/17499002/diff/43001/chrome/browser/metrics/me...
File chrome/browser/metrics/metrics_service.cc (right):

https://codereview.chromium.org/17499002/diff/43001/chrome/browser/metrics/me...
chrome/browser/metrics/metrics_service.cc:1048: // before the range was switched
to [0, 8191] and then [0, 7999]. Map 8192
On 2013/06/21 01:12:53, Ilya Sherman wrote:
> nit: "and then [0, 7999]" -> "and then to [0, 7999]"

Done.

[commit-bot: I haz the power, 2013-06-21 14:29:21]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/asvitkine@chromium.org/17499002/54001

[commit-bot: I haz the power, 2013-06-21 16:53:24]

Change committed as 207865