Proper bandwidth units [was: Exit nodes on Gandi]
On Fri, Nov 15, 2013 at 3:47 PM, Eric van der Vlist <vdv@dyomedea.com> wrote:
Without bandwidth limitation that's true. OTH, I currently consume only ~ 50 Gbits/month and the limit is 500 Gbits. Would a relay limited to let's say 200 or 300 Gbits/month still be useful for the community?
People, can we please mind using the proper units. I know Tor doesn't make it easy because Tor itself incorrectly uses Bytes. But Tor is a network application, and real network apps are measured in 'bits per second', not 'bytes transferred off disk', even if the latter is what silly hosters sell by... mostly due to their presumed need to tie in with their typical customers supposed Apache access_logs. But believe me, what hosters really care about is their upstream bill in bps rate, they're just converting that for access_log presentation to you. Your further mixing of 'giga bits per month' doesn't help *at all*. Please try to use 'bits per second' as the common denominator on this (network application) list. BTW, Gandi is historically a fairly progressive company. The right approach could have some good wins there.
On Mon, Nov 18, 2013 at 12:14:15AM -0500, grarpamp wrote:
People, can we please mind using the proper units. I know Tor doesn't make it easy because Tor itself incorrectly uses Bytes. But Tor is a network application, and real network apps are measured in 'bits per second'
I understand your perspective, but Tor is an overlay application just like bittorrent. Tor moves bytes around. It happens that it moves the bytes over the network, so I can see why you would call it a network application. But by your definition I claim it is not. :) That said, yes, always say the whole unit. Do not assume that anybody knows what you mean when you say 'b'. No matter what you mean, there will always be somebody who is certain of what you mean yet is wrong. --Roger
On Mon, 18 Nov 2013 00:26:32 +0000, Roger Dingledine wrote: ...
I understand your perspective, but Tor is an overlay application just like bittorrent. Tor moves bytes around. It happens that it moves the bytes over the network,
Is there anything nowadays that does move data on networks in finer grain than bytes? Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds <torvalds@*.org> Date: Fri, 22 Jan 2010 07:29:21 -0800
On Mon, 18 Nov 2013 00:14:15 +0000, grarpamp wrote: ...
People, can we please mind using the proper units.
How is 'bytes' improper when that is the basic transfer unit of TCP/IP, and half of the underlying protocols? The only ones who really don't care about bytes are the layer 1 guys.
I know Tor doesn't make it easy because Tor itself incorrectly uses Bytes. But Tor is a network application, and real network apps are measured in 'bits per second',
So, neither scp nor wget are real network applications? Nor ftp, nor firefox? Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds <torvalds@*.org> Date: Fri, 22 Jan 2010 07:29:21 -0800
People, can we please mind using the proper units.
How is 'bytes' improper when that is the basic transfer unit of TCP/IP, and half of the underlying protocols? The only ones who really don't care about bytes are the layer 1 guys.
No, routing the global internet occurs at layer 3. Bandwidth is a commodity, bought and sold on the open market in units of 'bits per second', from the Tier-1's all the way down to your ISP/hoster. All of them use routing and switching hardware from Juniper, Huawei, etc that is configured in 'bits per second'. When you go to provision a continuous big bandwidth service such as Tor, bittorrent, streaming, etc, you ultimately do that in 'bits per second'. Especially for large bitrates, multiple megabits and up. Any 'Bytes' shown to you by the provider are simply an abstraction from the real 'bits' they use internally (and of particular importance at their billing points with peers [1]). Bytes are a translated kludge meant to match the 'Bytes' seen in end user incidental application logs, which traditionally moved data you owned and managed off disk. People who sell bandwidth in quantity will look at you like you're speaking some foreign language when you come to them wanting to push '30TiB/mo' instead of 100Mbps. They want to know (how much CAR on) what port you're going to fill up 24x7x365 so they can buy and bill appropriately. That's done in DS-x, T-x, OC-x, 10/100/1000/10000... all bits, not Bytes. Your dialup, cable, dsl, and fiber lines are all in bits/sec too [2]. Why in the world should you have to sit there with a calculator to figure out how you want to fit Tor within that. [1] You know, the series of tubes. [2] Excepting any silly transfer caps, that you then have to decide to eat up all at once at a high (or maximum) line rate or slowly over time. Which, with constant applications you don't care about, becomes... guess what... a simple bps number all over again! You should have used bps from the start in that case.
I know Tor doesn't make it easy because Tor itself incorrectly uses Bytes. But Tor is a network application, and real network apps are measured in 'bits per second',
So, neither scp nor wget are real network applications? Nor ftp, nor firefox?
Correct, in the sense, unless aggregated across many users, they are non-constant incidental end user applications, not a part of the real network itself.
Tor is an overlay application just like bittorrent
Yes. Tor, I2P, torrent/sharing, vpn, overlay nets, software routers, etc are all network bandwidth services, usually provisioned in the sense/mindset that they will fill their entire provisioned/intended bitrate and that one best make plans/headroom/commitment/tolerance for just that case. When you go to drop relays on the net, or even get a job on the net, in reality you're going to be speaking in 'bits per second'. Everything else 'Bytes' is just a hack made for the traditional web/ftp people and their logs. Bandwidth providers and what amount to transit services are not really in a position to optimize and thus don't care about that sort of logs, they just tack up a bitrate, pay the same bill every month and forget about it.
Is there anything nowadays that does move data on networks in finer grain than bytes?
It's not about 'fineness', it's about interop at levels at which counting and optimizing Bytes is irrelevant. Yes, thankfully some things like Vuze, Tor head, some OS packet filters, software routers, and such can be configured in bits/sec. And as the internet continues growing to support constant HD video streams down to every curb and datacenter port, those old style Bytes/caps become doubly irrelevant. It's bits per second now, just like hardware routers do it.
On Mon, 18 Nov 2013 13:33:05 +0000, grarpamp wrote:
People, can we please mind using the proper units.
How is 'bytes' improper when that is the basic transfer unit of TCP/IP, and half of the underlying protocols? The only ones who really don't care about bytes are the layer 1 guys.
No, routing the global internet occurs at layer 3.
Yes, and the global internet uses IP packets whose length is measured in bytes, not bits. ...
Correct, in the sense, unless aggregated across many users, they are non-constant incidental end user applications, not a part of the real network itself.
This is the only actual argument why we should adopt bits/s instead of byte/s, yet... ...
And as the internet continues growing to support constant HD video streams down to every curb and datacenter port, those old style Bytes/caps become doubly irrelevant. It's bits per second now, just like hardware routers do it.
No, that's still bogus. The only reason the hardware guys talked about bits/s was that that was the physical line limit, and that there was no consensus about protocols, or how many bits shall constitute a byte, or how many extra bits shall accompagny(sp?) the actual data. Nowadays bytes always have eight bits, it's always IP, and the transport is (almost) always fully efficient so that a byte/s always translates into eight bits/s. There is simply no more reason to talk in bits/s at all, except that everyone is doing it. (The fractional reason that you can deduce the needed physical bandwith from the bitrate is also long gone.) And for me it's pretty irrelevant whether I need to break down the TB/month my VPS provider gives me into bits/s or bytes/s. Neither is as straightforward as a decimal shift. Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds <torvalds@*.org> Date: Fri, 22 Jan 2010 07:29:21 -0800
Yes, and the global internet uses IP packets whose length is measured in bytes, not bits.
On paper in an RFC, yes, displayed on the actual routing hardware as what you're pushing, no.
No, that's still bogus. The only reason the hardware guys talked about bits/s was that that was the physical line limit, and that there was no consensus about protocols, or how many bits shall constitute a byte, or how many extra bits shall accompagny(sp?) the actual data.
Nowadays bytes always have eight bits, it's always IP, and the transport is (almost) always fully efficient so that a byte/s always translates into eight bits/s.
This isn't a question of line/protocol encoding. Network hardware ships databits around agnostic of that.
There is simply no more reason to talk in bits/s at all, except that everyone is doing it.
Obviously, because backbone people buy and sell to lower ISP's/hosters in bits/sec and your home line does too. That's from the birth of the net and trickles down, the actual choice and original rationale is moot, bits is what the upstream measures things in today. When you go to quote and plug in a large and 24x7 constant bandwidth service like Tor, I2P, torrent, VPN aggregator, etc the common language is often, and more easily to them, bits/sec.
break down the TB/month my VPS provider gives me into bits/s or bytes/s. Neither is as straightforward as a decimal shift.
That's why real networks use bits/sec: it is precisely an SI prefix shift, with no 8 divisor/multiplier or 2^n involved anywhere. There's no ambiguity and no math, just simple clarity. VPS are by definition small, oversubscribed platforms, not generally suited to large dedicated services. VPS providers generally cater to the smaller apache style bytelog counting type customer. Not the larger full on network (vpn, tor, router) customer. And when we have people saying stuff like 'giga bits per month', it's clear that confusion is perpuating in the field quite well to the point you have no idea if they even know what their own datapoint is. Then you have to ask them to clarify their meaning, check their math, etc. We've got 100Mbit or more nodes out there and dinky 512kbit ones or less. For easy network reference, yes, people should use bits/sec across the board here. If they insist on using Byte/sec, at least use it right with SI 10^n prefix, not IEC 2^n prefix. And don't come up with some unusual combination of prefix/time as in the OP either. For example... A proper IEC gibibyte = GiB = 2^30 = 1024^3 = 1073741824 for data storage, ram (binary bit handling) A proper SI gigabyte = GB = 1E9 = 1000^3 = 1000000000 for data transmission (packet counting, rocketships) https://en.wikipedia.org/wiki/Binary_prefix https://en.wikipedia.org/wiki/ISO/IEC_80000 http://www.swedeteam.com/kibi/ Thugh they may break your broken tradition, there are current standards now, please use them.
On 13-11-18 07:28 PM, grarpamp wrote:
A proper IEC gibibyte = GiB = 2^30 = 1024^3 = 1073741824 for data storage, ram (binary bit handling) A proper SI gigabyte = GB = 1E9 = 1000^3 = 1000000000 for data transmission (packet counting, rocketships)
https://en.wikipedia.org/wiki/Binary_prefix https://en.wikipedia.org/wiki/ISO/IEC_80000 http://www.swedeteam.com/kibi/
Thugh they may break your broken tradition, there are current standards now, please use them.
The tradition may be broken but it has roots, just as feet and inches and acres came from real human practices. Some of us "grew up with" that stuff and it is going to be a pain to unlearn, for example, that a KB is 1024 bytes. Indeed this is the first i heard that anyone changed the definitions. Anyway, as long as Tor docs are clear what definitions are being used i think we can all get along fine. Suggest we add reference URLs to Tor docs.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 krishna e bera:
On 13-11-18 07:28 PM, grarpamp wrote:
A proper IEC gibibyte = GiB = 2^30 = 1024^3 = 1073741824 for data storage, ram (binary bit handling) A proper SI gigabyte = GB = 1E9 = 1000^3 = 1000000000 for data transmission (packet counting, rocketships)
https://en.wikipedia.org/wiki/Binary_prefix https://en.wikipedia.org/wiki/ISO/IEC_80000 http://www.swedeteam.com/kibi/
Thugh they may break your broken tradition, there are current standards now, please use them.
The tradition may be broken but it has roots, just as feet and inches and acres came from real human practices. Some of us "grew up with" that stuff and it is going to be a pain to unlearn, for example, that a KB is 1024 bytes. Indeed this is the first i heard that anyone changed the definitions.
Anyway, as long as Tor docs are clear what definitions are being used i think we can all get along fine. Suggest we add reference URLs to Tor docs.
Why not just accept KB/sec, KiB/sec, GB/mo, GiB/mo in the config file? Best, - -Gordon M. -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJSj5FKAAoJED/jpRoe7/ujtaIIAJwXML8D3JVW9t3+dHkjWZaY +KL1sPAsJqcurlISkm2W0Mlw1wrmMAiwoK5ZfJ9kyfxBD4pA/8AOocDpLgqUCzwi IREGIkzMLLOgJYBizPb5g5I9KWuC7gpWg5EXUuOpuHAfBvuLD6faMQ+G+l4D0yRk Ik7D/Hw5K4aOm2/U8j1n/3FASkKLJa9k+5Y1rsLM4UaRkLoQunRURnWy31Ui4mab bUXIQi+OWkhCRUOeX004BRVRxj5/cBQDvaM1qcpvH6R0Kj9YI2Tjp8XumrQgdzCY k+aM8Av+agvSzQVQCn67lFbD8u4qnzDqDsru+0FUMdQlS/UQQo4emWAVtT8vGUQ= =+lx/ -----END PGP SIGNATURE-----
On Sat, 23 Nov 2013 02:50:03 +0000, grarpamp wrote:
Why not just accept KB/sec, KiB/sec, GB/mo, GiB/mo in the config file?
Because KB/sec would be rejected as not conforming to either SI or IEC prefix specs.
Why so? The SI prefix spec only specifies that K means 1000, it does not limit the base units. (And neither bytes not bits are SI units.) Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds <torvalds@*.org> Date: Fri, 22 Jan 2010 07:29:21 -0800
Gordon Morehouse:
Why not just accept KB/sec, KiB/sec, GB/mo, GiB/mo in the config file?
That would be #9214 [1], implemented by CharlieB, shipped since tor 0.2.5.1-alpha. [1] https://bugs.torproject.org/9214 -- Lunar <lunar@torproject.org>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Lunar:
Gordon Morehouse:
Why not just accept KB/sec, KiB/sec, GB/mo, GiB/mo in the config file?
That would be #9214 [1], implemented by CharlieB, shipped since tor 0.2.5.1-alpha.
Good, this is the most sensical behavior to the widest array of people who type things into config files, and the ability to type GiB/mo and have it mean a line rate will be nice for those of us who, thank you very much, do make up an important part of the peanut gallery on VPS providers. Centralization is death. I'm glad we're here. Best, - -Gordon M. -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJSkSwvAAoJED/jpRoe7/ujxvYIALDaDKZKA8vWXh9aJZycZjNc 3qHQVMwn96Nocl6vmFqhbB2VvpgfAkRb5+MPpZjX5UeXZ4kLcoQh14SsXXvcC2xc HUi8/IF5a1eYUtsOGAz/+Rde0Xdhvkbf3LG7iJGoY0kX94GI4LG04uVN3j8NsKQv 2XUy3z7ifkSj+AAHwdDtVDP3eX7XZ0Nogo+x0q18Y+ZhW6JAtTncPQvojalGpNYw qbgVLOKvzJPX8LSokfE6NNR/asjioz5K27ueodrjnlps9s3VrEDc5Xo+tush1nqm zEd0TVZlS20xIqFTFiqqOoucM8jH35XfSv4EUSoLm5yUPwadMJND/Xm+L5wl62U= =q9T8 -----END PGP SIGNATURE-----
On Sat, Nov 23, 2013 at 02:29:04PM -0800, Gordon Morehouse wrote:
Lunar:
Gordon Morehouse:
Why not just accept KB/sec, KiB/sec, GB/mo, GiB/mo in the config file?
That would be #9214 [1], implemented by CharlieB, shipped since tor 0.2.5.1-alpha.
Good, this is the most sensical behavior to the widest array of people who type things into config files
Actually, this is alas not the case. We now support gbits (1<<27) and gbytes (1<<30) in the torrc file, but we do not support "gib". Or I think more correctly, we say gbytes for what you want us to call gibs, and if you want to say a billion bytes, you need to type all the zeros. --Roger
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Roger Dingledine:
On Sat, Nov 23, 2013 at 02:29:04PM -0800, Gordon Morehouse wrote:
Lunar:
Gordon Morehouse:
Why not just accept KB/sec, KiB/sec, GB/mo, GiB/mo in the config file?
That would be #9214 [1], implemented by CharlieB, shipped since tor 0.2.5.1-alpha.
Good, this is the most sensical behavior to the widest array of people who type things into config files
Actually, this is alas not the case.
We now support gbits (1<<27) and gbytes (1<<30) in the torrc file, but we do not support "gib". Or I think more correctly, we say gbytes for what you want us to call gibs, and if you want to say a billion bytes, you need to type all the zeros.
I learned about the 'gib, kib' etc in wikipedia a while back - it'd be best if the config file were extremely liberal in accepting what people type, IMO. Best, - -Gordon M. -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJSk5cgAAoJED/jpRoe7/ujt8IH/2ipNB52tIcxQtF9U7bw+ThN aYim2upAF4bluDcsgYia29FgtwKW8LkFwlBH06qG0DVcifprlkfzR3iZGIfTOGE2 m1cfLkEqRvF7nF5H9ajfIwBnvgrf3stmIBMsjMhFwo1iaRWoD/qPtd14wKVWk+xH skK48fNcCI0nCep0rBHKwC593QUVv++soNi+aLhuOOGXR0raA/hVt/nms0D4v/pZ FEdsJfK8BOxrS43JpuQVR8AbUdbnJGs1HQ35T3HmyRoMdDj2ulQ8G9fYIG0w7u2P cXM9+5BhfMx5M2y1YI+3t9WFBJhZO3Kwzz2X/OSOwt1vfWHcwQ1KVBrRRgGg79A= =j66M -----END PGP SIGNATURE-----
On Mon, Nov 25, 2013 at 1:29 PM, Gordon Morehouse <gordon@morehouse.me> wrote:
Why not just accept KB/sec, KiB/sec, GB/mo, GiB/mo in the [1] https://bugs.torproject.org/9214 We now support gbits (1<<27) and gbytes (1<<30) in the torrc file, but we do not support "gib". Or I think more correctly, we say gbytes for what you want us to call gibs, and if you want to say a billion bytes, you need to type all the zeros.
I learned about the 'gib, kib' etc in wikipedia a while back - it'd be best if the config file were extremely liberal in accepting what people type, IMO.
No. This kind of lazy acceptance is exactly why rockets crash, and rockets crashing are why one must use proper terms. 'gib, kib' are not cased correctly, thus people have no idea what you explicitly mean. They might presume your lazy casing means 'Gib, KiB' but then your rocket might crash. Reference and enforcement is the proper cure. https://en.wikipedia.org/wiki/Binary_prefix The little table in the upper right covers the decimal and binary prefixes and their long names. It should be documented as such and nothing else should be accepted. As far as units of bit and byte... https://en.wikipedia.org/wiki/IEEE_1541-2002 https://en.wikipedia.org/wiki/IEC_80000-13 With the more international community seemingly lately moving the abbreviation for a bit from 'b' to 'bit'. And defining octet 'o' as the grouping of eight bits (perhaps still leaving the byte somewhat undecided as to its width in bits, and conflicting in abbreviation 'B' with the older and more cross-disciplined Bel.). https://en.wikipedia.org/wiki/Bit https://en.wikipedia.org/wiki/Byte https://en.wikipedia.org/wiki/International_System_of_Units
On Mon, 25 Nov 2013 15:46:02 -0500 grarpamp <grarpamp@gmail.com> allegedly wrote:
No. This kind of lazy acceptance is exactly why rockets crash, and rockets crashing are why one must use proper terms. 'gib, kib' are not cased correctly, thus people have no idea what you explicitly mean. They might presume your lazy casing means 'Gib, KiB' but then your rocket might crash. Reference and enforcement is the proper cure.
This argument (Mbit/s versus GiB/month) reminds me of the old saw about the most useless unit of velocity (furlongs/fortnight instead of m/sec). Mick --------------------------------------------------------------------- Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 http://baldric.net ---------------------------------------------------------------------
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In the process of shopping round for some fast exit hosting and realized I had some unanswered questions. What's the minimum system requirements people would consider for hosting a fast exit relay? Does doing it on a KVM host alter these answers at all? How linked our system resources and bandwidth capacity? - -Jason -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSk9PmAAoJEJJlIjlYdaGY5AsIAIDnJZl1IvUOR5Eo62iYyXjM IPVF8gzwYCnxG6EGsGQflyyhfuy6S+yR3cDrw/0pftnZEWgukkt6Ma3r2ZrEK00r dhajLhmeuLoBhJ8LS8mjCCnmS7YRa7M3zKVAjalFs+ngZraugyc7rvIj2hKee76o 2f4fxKsDXBN6v6oKGqCjqTA4My2bF2ogUZr/yLzGqX5M40srM2ugA5UX33hpNbKd p7l3GNXy7vDems+JCpMZad+ux0EtcDv9/GTKreNkAC4gzPlJXPGnEy5JDxgIPHyJ WXS6NJizrTCFCUobvKvd7tiePsn1q12MBe/3WE3zMnzLah/g12CmFW1Vl6vbnow= =EyAa -----END PGP SIGNATURE-----
On 11/25/2013 11:49 PM, jason wrote:
In the process of shopping round for some fast exit hosting and realized I had some unanswered questions. What's the minimum system requirements people would consider for hosting a fast exit relay? Does doing it on a KVM host alter these answers at all? How linked our system resources and bandwidth capacity?
Define "fast". For a Gbit/s relay: At the moment 8GB or RAM are enough, better go with 16. And any modern CPU with AES-NI crypto acceleration. You can check out our munin graphs at https://www.torservers.net/munin/ -- Moritz Bartl https://www.torservers.net/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
This argument (Mbit/s versus GiB/month) reminds me of the old saw about the most useless unit of velocity (furlongs/fortnight instead of m/sec).
Mick
I know exactly what you mean. Personally, I consider any change to be a convenience modification only. In reality the only current differences are in defining storage rate and traffic rate (1024/1000 respectively) and its defined in bits. From there all conversions are simple math that should be operator responsibility. Regards, Travis -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSk/AmAAoJECJSqAwXZ/cnZBcH/2RbiydXZwTk5vwhOSfdG9wB nqvExUaqTUIsrfgc406TxoU01gZNTCc5Qo6aKeNCHthM/z8yQDW8mSG6Cxu1LuPL vULJ8U44quVy0i0K9hYoD5C6H1oHl7HqiqH0iAffAiCIEbPAVyycDm2+vHLFv0o2 a9MWd4a68ACA5Z5kRXlpfpxp0OUitgx9XvaT3C+bKWex5xSnHJabl/C9MFSSJXEj 6zKWEMh9QtK/BbYBMEb2Je/JzNtURFcqhWxGIqS326zBkrWEJ/dydcjOU5Chk/lD 9jPUHMwO7WvwtYA8vqPraCMX+aHXLkPvvfDmc8Ng66p08swznj8YKNfC5G+OB7I= =ay2f -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Travis Northrup:
This argument (Mbit/s versus GiB/month) reminds me of the old saw about the most useless unit of velocity (furlongs/fortnight instead of m/sec).
Mick
I know exactly what you mean. Personally, I consider any change to be a convenience modification only. In reality the only current differences are in defining storage rate and traffic rate (1024/1000 respectively) and its defined in bits. From there all conversions are simple math that should be operator responsibility.
Why, when the config file can be liberal in what it accepts in the numerator, and in the denominator (seconds, days, weeks, mean months)? Calculating numbers is a job for a computer. Best, - -Gordon M. -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJSlRhVAAoJED/jpRoe7/ujzC0IANGMKvdbnvOO9lebNa81ETo9 6st2Dyt8Cy3qVmWevVT3JP6GZIpLVAk4M5SeFUm3abY2kbphIJfnnKVGYR/B3ggI 5uVTUN5uFIZmePAoMxHh53Y9ss5IYizvFFli3jaeg7iJnYjQl6zeogBCp275YCR0 tbNeZ4BisXzXUDavTm5c23x0d9fo7z7b7i+SMhPs3DanZG3JLPHtTX+aYiBRjRlY hZJE9K6i+cvYEEId24tqo/uymEw8BFeCj5Ws32Gj9fHXSn64JDUaEawmmTXXsfvA DTUGLbRAVfdRDWrQl9JXTZLswMkis5SrrTeoehwo93cjgvl5z7uBa6/rK9WxwzY= =MdoA -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yes, it can. The program can spend the processor time to run that extra instruction set. Do we actually need or want that? Would it be worth spending the cpu time in exchange for just a miniscule effort to do it ourselves? On Tuesday, November 26, 2013 3:53:25 PM, Gordon Morehouse wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Travis Northrup:
This argument (Mbit/s versus GiB/month) reminds me of the old saw about the most useless unit of velocity (furlongs/fortnight instead of m/sec).
Mick
I know exactly what you mean. Personally, I consider any change to be a convenience modification only. In reality the only current differences are in defining storage rate and traffic rate (1024/1000 respectively) and its defined in bits. From there all conversions are simple math that should be operator responsibility.
Why, when the config file can be liberal in what it accepts in the numerator, and in the denominator (seconds, days, weeks, mean months)?
Calculating numbers is a job for a computer.
Best, - -Gordon M. -----BEGIN PGP SIGNATURE-----
iQEcBAEBCgAGBQJSlRhVAAoJED/jpRoe7/ujzC0IANGMKvdbnvOO9lebNa81ETo9 6st2Dyt8Cy3qVmWevVT3JP6GZIpLVAk4M5SeFUm3abY2kbphIJfnnKVGYR/B3ggI 5uVTUN5uFIZmePAoMxHh53Y9ss5IYizvFFli3jaeg7iJnYjQl6zeogBCp275YCR0 tbNeZ4BisXzXUDavTm5c23x0d9fo7z7b7i+SMhPs3DanZG3JLPHtTX+aYiBRjRlY hZJE9K6i+cvYEEId24tqo/uymEw8BFeCj5Ws32Gj9fHXSn64JDUaEawmmTXXsfvA DTUGLbRAVfdRDWrQl9JXTZLswMkis5SrrTeoehwo93cjgvl5z7uBa6/rK9WxwzY= =MdoA -----END PGP SIGNATURE----- _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSlTG/AAoJECJSqAwXZ/cnKcIIALVECDceF/aKsJV+D7nxVaJ8 H6tjAwj3nKqY1/LR8uPg7Z3E4mfuIRi6df/WUMxH1NP0sbFpWz1NY30iOEt9lAb1 fLY+exqmCYBifoNB7e5Gcss2QcqGhoCl6T9HYVoT9QmFZrlZvjr0goBCPQEdYwqC p2wW0zZftzCFKl3jCTtAiYslDvCLbujyYtlVWFqjlQjAuWNMJ0z/7Ntx4kquSzCc vKioMv95oQVT2MZywh5amNYNr/qYiKWYbAzL8FwZm9PMG2MQjZGiLxRpmwzmUrp6 HwSGjATO4dOSrRfPWsAW/XwJuioJbILdJUIrs9bXYubN9cX8BSp4PgtMziFDfAw= =BeA7 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Travis Northrup:
Yes, it can. The program can spend the processor time to run that extra instruction set. Do we actually need or want that? Would it be worth spending the cpu time in exchange for just a miniscule effort to do it ourselves?
Are you really arguing something like 1000 cycles on a modern processor (so, what, a microsecond, tops) vs 5 minutes of human effort? Is this maybe an example of why crypto software UX is almost universally god-awful? Best, - -Gordon M.
On Tuesday, November 26, 2013 3:53:25 PM, Gordon Morehouse wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Travis Northrup:
This argument (Mbit/s versus GiB/month) reminds me of the old saw about the most useless unit of velocity (furlongs/fortnight instead of m/sec).
Mick
I know exactly what you mean. Personally, I consider any change to be a convenience modification only. In reality the only current differences are in defining storage rate and traffic rate (1024/1000 respectively) and its defined in bits. From there all conversions are simple math that should be operator responsibility.
Why, when the config file can be liberal in what it accepts in the numerator, and in the denominator (seconds, days, weeks, mean months)?
Calculating numbers is a job for a computer.
Best, - -Gordon M.
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
- -- Sent from my thing that sends email. -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJSm+Y+AAoJED/jpRoe7/ujPRYH/1agvqhrhhk7/uqNr9oEW+Wi A7fJ2Z6Dt/j+b1A9ty05regLN5q+4t9JE5A492j146v8aJEcZoAWU6718ug8n1Kq wzX0t5oWl36UivFr99pVvKTf1YHEQ9BCx4S88bbkUn6IvYFv/z8n4o+Kw2dutYDO Zgl0NGaPrc5IgAglGv6p2Kjc9TON8bkIYJENkbaW58kVEeCad9Sel3i2ZDrC7E2R WJw8E51n472HpbYbCu5L/zuijzjxpYdjI0Nu3KI3Qci9Uozkpgq2N7bo3n2rzYMI ufwSnyqAwQLH1ZCkYhYVbR4uEuNRGP2/sAUXrKdhYVNE6c3MsCY/Zm51nnDzHX4= =GzbJ -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Actually, lets take a look at it from the other perspective then mine. Considering that the instruction would only be need to be computed once (during application re/start) that isn't much of a task. So with that in mind...human computational error is a significant factor. If the operator didn't do his math correctly, that would have a considerable effect on advertised transfer rate. However, what we're actually arguing here is convention and not computation. THAT is where the problem lies. One person's convention isn't another persons. What is more important is that all configuration follow algorithm rfc. Forget convention because we have to go with the established methods of operation that gets hashed out through the rfc. That is the best way. I operate in bits and don't mind calculating to a convention understood by users and that removes the possibility of error in convention but enables the possibility of human computational error (69 it) which could drastically change how the transfer rate is established on the relay. There is an argument for both, but you guys are arguing about conventions that shouldn't even be considered without a request for comment to the developers. On 11/26/2013 3:53 PM, Gordon Morehouse wrote:
Travis Northrup:
This argument (Mbit/s versus GiB/month) reminds me of the old saw about the most useless unit of velocity (furlongs/fortnight instead of m/sec).
Mick
I know exactly what you mean. Personally, I consider any change to be a convenience modification only. In reality the only current differences are in defining storage rate and traffic rate (1024/1000 respectively) and its defined in bits. From there all conversions are simple math that should be operator responsibility.
Why, when the config file can be liberal in what it accepts in the numerator, and in the denominator (seconds, days, weeks, mean months)?
Calculating numbers is a job for a computer.
Best, -Gordon M. _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSlU/DAAoJECJSqAwXZ/cnBHoH/iCTd1T4OaLLpin7X+aEZgVB GqvdA6CDAqvTm+LX3hT8pOb/CvbyGBoHvjhJHiGY52u6ChaM+EXNAwqo+XNQJ8NB AfRk5r0WtS7XqWlXLer0EiQICSDfRk3Z6mjxHpvChODARk/wXnJlx3ZisY5H33+U NVEBuXYFqQz4GFFHHXU+Q+DqCHVaz84R5E0ZejZeLkBWLjEQdtVwkuAdQS71Dbda 8Qc4T8/z4/fXivC8dT7r4trPVYcv35dKniZaEf48xuZCmHexEvPPIOIPKCBcIF0F 4BB6hYPmLWUjGJE2lwbsIXxJ+nPCYBg4n/xqxuKlP7oZ7dlNf+lfiYxxeP9CeDc= =4+zj -----END PGP SIGNATURE-----
participants (10)
-
Andreas Krey -
Gordon Morehouse -
grarpamp -
jason -
krishna e bera -
Lunar -
mick -
Moritz Bartl -
Roger Dingledine -
Travis Northrup