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

Issue 739925 link

Starred by 3 users
Status: Duplicate
Merged: issue 774680
Owner:
rajendrant@chromium.org
Closed: Oct 2017
Cc:
gayane@chromium.org
asvitk...@chromium.org
skare@chromium.org
isherman@chromium.org
█ rkaplow@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment

DataUse.MessageSize Histograms Are Inaccurate

Project Member Reported by bcwh...@chromium.org, Jul 6 2017 
Chrome Version: HEAD
OS: ALL

https://codereview.chromium.org/1818613002/

https://cs.chromium.org/chromium/src/components/data_use_measurement/core/data_use_measurement.cc?rcl=4e92a9428c27532b6d8a8d10a5d554aea795483a&l=391

The DataUse.MessageSize.* histograms are incrementing by byte-count and are overflowing the 32-bit signed accumulators in the histogram.  This causes negative values to be reported to the back-ends and generally disrupts the accuracy of the metric.

The most accurate way would be to have a histogram per type with buckets of message-size because the accumulated sum is 64-bit.  Even a few buckets like 1B, 10B, 100B, 1000B, ..., 1GB would be sufficient.

Or a simpler solution would be to change the units from B to nearest KiB making it much less likely to overflow... at the expense of some accuracy.

If accuracy is important, perhaps we should investigate a "ScaledHistogram" object that reduces the input but keeps a "remainder" accumulator that bumps the recorded value when it overflows.

Comment 1 by asvitk...@chromium.org, Jul 12 2017

Owner: bengr@chromium.org
Status: Assigned (was: Untriaged)
Routing to bengr@ - since these were originally added by an intern project.

Ben, can you take a look and see if someone from your team could do this?

(I like the idea of logging KiBs and keeping intermediate byte counts.)

Comment 2 by bcwh...@chromium.org, Jul 12 2017 

I don't mind looking into support for this, basically "ScaledLinearHistogram" or something.  There just need to be a parallel "remainder" vector or something.

Might be easiest to stop move these particular ones away from "sparse" if feasible.  It would also be a performance win, something that might be important given that it's counting every network transfer.

Comment 3 by bengr@chromium.org, Jul 13 2017

Components: Internals>Network>DataUse
Labels: -Pri-3 M-62 Pri-2
Owner: rajendrant@chromium.org
Yeah, we definitely should fix this.
Project Member

Comment 4 by bugdroid1@chromium.org, Jul 13 2017 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/18723f5dbb8ba5a8197f4c4e07a776b1e0b2d178

commit 18723f5dbb8ba5a8197f4c4e07a776b1e0b2d178
Author: Brian White <bcwhite@chromium.org>
Date: Thu Jul 13 22:25:08 2017

Define DataUse/AllServices histogram hashes.

These are known offenders of the UMA.NegativeSamples.Histogram
metric.

https://bugs.chromium.org/p/chromium/issues/detail?id=739925

Bug: 682680, 739925 
Change-Id: Ie3e394baf5e1dfb2cf8f1028c5273c0a3d19ab4a
Reviewed-on: https://chromium-review.googlesource.com/570262
Reviewed-by: Alexei Svitkine (slow) <asvitkine@chromium.org>
Commit-Queue: Brian White <bcwhite@chromium.org>
Cr-Commit-Position: refs/heads/master@{#486490}
[modify] https://crrev.com/18723f5dbb8ba5a8197f4c4e07a776b1e0b2d178/tools/metrics/histograms/enums.xml

Comment 5 by rajendrant@chromium.org, Oct 30 2017

Status: Started (was: Assigned)
Need to check if other histograms exhibit this overflow behavior.

Comment 6 by bcwh...@chromium.org, Oct 31 2017

Mergedinto: 774680
Status: Duplicate (was: Started)
This specific issue was fixed under  Issue 774680 .
General tracking of this problem his here:
https://bugs.chromium.org/p/chromium/issues/detail?id=682680
►

Sign in to add a comment