Opened at 2012-05-26T15:23:06Z
Last modified at 2012-06-05T03:12:42Z
#1750 new defect
times are rounded too coarsely in results pages
Reported by: | davidsarah | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | undecided |
Component: | code | Version: | 1.9.1 |
Keywords: | usability performance stats | Cc: | |
Launchpad Bug: |
Description
The time for each operation seems to be rounded to a multiple of some major unit (e.g. seconds, minutes or hours), which is far too coarse to be useful. The rounding is done in the abbreviate_time function of src/allmydata/util/abbreviate.py.
(Mentioned in ticket:962#comment:12, and also an issue for me recently when testing performance of the cloud backend.)
Change History (2)
comment:1 follow-up: ↓ 2 Changed at 2012-05-29T16:52:08Z by warner
comment:2 in reply to: ↑ 1 Changed at 2012-06-05T03:12:42Z by davidsarah
Replying to warner:
What would work better.. maybe a 2-decimal abbreviation (like the one used in abbreviate_space)? It might read a bit oddly to see "3.54 minutes", but the alternatives are equally odd ("212 seconds" or "3 minutes 32 seconds" or "3m32s").
I don't find "212 seconds" odd.
(note that the transition thresholds in abbreviate_time are not at the unit boundaries: it reports seconds for anything below *2* minutes, and minutes for anything below 3 hours. But I still see your point about it being too coarse)
Right; it allows up to a 20% proportional error (2.5 minutes rounded to 2 minutes is the worst case).
What would work better.. maybe a 2-decimal abbreviation (like the one used in abbreviate_space)? It might read a bit oddly to see "3.54 minutes", but the alternatives are equally odd ("212 seconds" or "3 minutes 32 seconds" or "3m32s").
(note that the transition thresholds in abbreviate_time are not at the unit boundaries: it reports seconds for anything below *2* minutes, and minutes for anything below 3 hours. But I still see your point about it being too coarse)