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

Issue 758398 link

Starred by 1 user
Status: Untriaged
Owner: ----
Cc:
skare@chromium.org
isherman@chromium.org
asvitk...@chromium.org
█ rkaplow@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

More appropriate time unit for *TIMES* histogram macros

Project Member Reported by carlosk@chromium.org, Aug 23 2017 
I want to track time periods for a new feature my team is working on but I will not use the existing TIMES-labeled histogram macros because they can only present data using milliseconds. I want to track times from 1 second to 1 month and using such a small unit would make them less readable.

It would be nice if at least one of those macros could allow the specification the time unit to be used. Or, as the units are also specified in the histograms.xml file, maybe it could be extracted from there?

I know I have only partial understanding of this issue and so it would be completely fine by me to just close this as won't fix with a little explanation.

Comment 1 by mpear...@chromium.org, Aug 23 2017 

This is more like a dashboard request.  The macros work fine; the millisecond is the smallest granularity of that can be recorded with them by default.

In particular, you're asking that the dashboard display large numbers that have units in milliseconds to, instead of displaying the raw number, display some more-interpretable number such as 17 minutes or 7 hours or 23 days.

Can you please file this internally, then close this bug?

thanks!

Comment 2 by rkaplow@chromium.org, Sep 5 2017 

As Mark says, you can use UMA_HISTOGRAM_CUSTOM_TIMES to create a histogram that has a very long range. Even though the underlying unit will still be ms, you can still set the max to be a  long time (ex. a week), so it will be able to handle longer times (second/minute ranges). So you should still be fine from a data collection perspective. One downside of this is that the absolute values uploaded will be bigger, which is slightly less efficient as these are proto int64s. Not sure if we care enough to make that better, considering we are probably talking about a relatively small amount of metrics.


Making it more readable from the dashboard side would make this better - if we made the dashboard give a better unit by default would that solve your issue?
►

Sign in to add a comment