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
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
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
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.
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
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
-----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.
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.
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
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
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/
-----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 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 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 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 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
tor-relays@lists.torproject.org
-
Andreas Krey -
Gordon Morehouse -
grarpamp -
jason -
krishna e bera -
Lunar -
mick -
Moritz Bartl -
Roger Dingledine -
Travis Northrup