#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: Changed at 2012-05-29T16:52:08Z by 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").

(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)

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).

Note: See TracTickets for help on using tickets.