[tor-relays] MiB/s / metrics

[usprey]

+1 grarpamp

bits with decimal prefixes is the only thing that makes sense in the
networking world.
On 20 Jan 2015 00:09, "grarpamp" <grarpamp at gmail.com> wrote:

> On Mon, Jan 19, 2015 at 5:55 AM, Sebastian Urbach <sebastian at urbach.org>
> wrote:
> > I opened a ticket recently with the intention to use a more common unit
> than
> > MiB/s for metrics. Karsten basically agrees but is waiting for more
> input.
> >
> > https://trac.torproject.org/projects/tor/ticket/14257
>
> Tor is at its core a network application, an interface to the
> network, a router. In the real ISP world therein everyone speaks
> in "mega bits per second" "10^n" (and now with 100Gbps
> links, in Gbps).
>
> Only the downstream hosting world speaks in "mega bytes"
> "2^n", "per" "whatever time unit they dream up". This comes
> from attempts by hosters to appease people pushing their
> disk files MiB's over the net at link rate, not spread over bandwidth
> rate. In fact, the hosters have to convert that appeasement on their
> backend to aggregated Mbps so they can talk to their real ISP's.
>
> I've suggested before that Tor project should use Mbit/s (or Mbps
> or Mbit[s] where the slash presents a problem) as its primary default
> representation for Tor client and all related projects that refer to
> bandwidth.
> Tor is a bandwidth app, especially at the relay level. There is no disk or
> instantaneous link rate transfer need applying to Tor relay. (As opposed
> to user level which is more of a mashup of rate usage contexts and
> interests similar to bittorrent/webserving.)
>
> Then if people want MiB's or MB's so they can continue perpetuating
> and interfacing with hosters who do the same, you could add a
> few global prefix, unit and time options to switch all representations
> over at once. (Tor client has recently added per stanza Mbps
> configs which is a fine alternative to global. Yet again, the manpage
> and even maybe the code still uses nonsense in regards to capitalization,
> base 2 vs 10, crossed contexts, etc...)
>
> Start here, use the table in the upper right, ignore jedec,
> and pick and apply 10^n or 2^n representations consistantly.
> https://en.wikipedia.org/wiki/Binary_prefix
>
> "
> BandwidthRate N bytes|KBytes|MBytes|GBytes|KBits|MBits|GBits
>            A token bucket limits the average incoming bandwidth usage on
> this
>            node to the specified number of bytes per second, and the
> average
>            outgoing bandwidth usage to that same value. If you want to run
> a
>            relay in the public network, this needs to be at the very least
> 30
>            KBytes (that is, 30720 bytes). (Default: 1 GByte)
> Notably, "KBytes" can also be written as "kilobytes" or "kb";
> "
>
> No, "KBytes" is invalid, there is no capital "K", only "k (SI)" and
> "Ki (binary)".
> Nor is "b" ever a byte, nor is "Bit[s]" ever capitalized.
> True network applications should also not be crossing network-like prefixes
> with disk-like objects or vice versa, ie: "Gibit[s] (non-network
> binary and single bit)",
> or the "GBytes (network SI and binary multiples of bit)" above.
> If you cross it up or make errors in context in one place that throws all
> your
> docs and configs into question. Even I still mess it up sometimes.
>
> "
> it's easy to forget that "B" means bytes, not bits.
> "
>
> Nope :) Abbr "B" means "byte" (now formally of width eight bits as in
> "octet/o",
> and still unfortunately caveat "bel/B" as in "dB"), and abbr "bit" means
> "bit",
> (and "b" is now just nothing but informal efficient shorthand for
> "bit" if I recall).
>
> https://en.wikipedia.org/wiki/IEC_80000-13
> https://en.wikipedia.org/wiki/Byte
> https://en.wikipedia.org/wiki/Octet_(computing)
> https://en.wikipedia.org/wiki/Bit
>
> Anyway, tor relay is network not disk, so I'd suggest megabits,
> or kilo/giga as scale appropriate.
> _______________________________________________
> tor-relays mailing list
> tor-relays at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20150120/0cfa69dc/attachment.html>