[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-bugs] #12909 [Stem]: stem.util.str_tools.get_size_label() insufficiently precise
#12909: stem.util.str_tools.get_size_label() insufficiently precise
--------------------+------------------------
Reporter: mmcc | Owner: atagar
Type: defect | Status: new
Priority: normal | Milestone:
Component: Stem | Version:
Keywords: | Actual Points:
Parent ID: | Points:
--------------------+------------------------
There is a known issue in Arm that causes AccountingMax sizes to be
displayed with insufficient precision. For example, a real AccountingMax
of 1850 GB will be displayed as 1 TB.
https://trac.torproject.org/projects/tor/ticket/12452
This is confusing and perplexing, especially for those worried about big
bandwidth overage charges.
It seems that this is an issue with
`stem.util.str_tools.get_size_label()`, which is itself mostly a wrapper
for `stem.util.str_tools._get_label()`. These functions format and return
the string that is then displayed:
(the call in arm)
https://gitweb.torproject.org/arm.git/blob/ac7923e31f52d3cf51b538ddf799162d67c04ecc:/arm/graphing/bandwidth_stats.py#l504
(the called Stem function)
https://gitweb.torproject.org/stem.git/blob/6c78d9acf9606eb6a93712cfe115a40c45504c70:/stem/util/str_tools.py#l134
Here's the above example problem returned from the master branch of Stem
(version 0.1.2.3, I believe), cloned on 20-08-2014. 1850000000000 is 1850
GB converted to bytes:
{{{
>>> from stem.util.str_tools import get_size_label
>>> get_size_label(1850000000000)
'1 TB'
}}}
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/12909>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs