times are rounded too coarsely in results pages #1750

Open
opened 2012-05-26 15:23:06 +00:00 by davidsarah · 2 comments
davidsarah commented 2012-05-26 15:23:06 +00:00
Owner

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 source:src/allmydata/util/abbreviate.py.

(Mentioned in /tahoe-lafs/trac-2024-07-25/issues/8467#comment:12, and also an issue for me recently when testing performance of the cloud backend.)

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 source:src/allmydata/util/abbreviate.py. (Mentioned in [/tahoe-lafs/trac-2024-07-25/issues/8467](/tahoe-lafs/trac-2024-07-25/issues/8467)#comment:12, and also an issue for me recently when testing performance of the cloud backend.)
tahoe-lafs added the
code
normal
defect
1.9.1
labels 2012-05-26 15:23:06 +00:00
tahoe-lafs added this to the undecided milestone 2012-05-26 15:23:06 +00:00
warner commented 2012-05-29 16:52:08 +00:00
Author
Owner

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)

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)
davidsarah commented 2012-06-05 03:12:42 +00:00
Author
Owner

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

Replying to [warner](/tahoe-lafs/trac-2024-07-25/issues/1750#issuecomment-130264): > 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).
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: tahoe-lafs/trac-2024-07-25#1750
No description provided.