Hi,
Thanks for writing to us. This is a question that gets asked a lot:
"Many people set up new fast relays and then wonder why their bandwidth is not fully loaded instantly…"
https://blog.torproject.org/blog/lifecycle-of-a-new-relay
I'll give short answers below, see the link for details.
On 11 Jun 2017, at 15:33, Vort vvort@yandex.ru wrote:
Hello.
Recently I have decided to create a new relay. After several days of waiting, I have realized that decision of Bandwidth Authorities, that my bandwidth is 1000 times lower than it should be, is pretty stable.
It can take a week or two for the bandwidth authorities to measure a relay.
That is bad on its own, but I was wandering - how many other relays suffers from the same problem? Since all network data is open to analysis, I have decided to calculate some statistics. As "Consensus Weight", theoretically, should correspond to relay's bandwidth, first thought was to compare it with "Advertised Bandwidth" value (assuming there not too many liars on the network).
The advertised bandwidth is the maximum a relay has seen itself use for 10 seconds in the past day or so.
The consensus weight is the median measured bandwidth over weeks for the relay from 3-5 different bandwidth authorities.
The result has revealed some anomalies: https://s8.hostingkartinok.com/uploads/images/2017/06/fed1cf8b57fc027223c8ea... First, and most important, - a lot of relays have bandwidth estimate in range 0-50: 1082 of them.
I don't know what each axis is on this graph.
20 is the default, 50 is the maximum for a relay's self-test.
If a relay isn't measured, or measures very low, it usually gets a figure in this range.
Second - there are incorrect estimates for popular bandwidths of 5, 10 and 20 MBits.
I don't understand what you mean here. The advertised bandwidth is in kilobytes per second, and the consensus weight is dimensionless (but scaled from kilobytes per second).
Can you point out the lines you mean?
Next question was: what estimates was actually assigned to that bandwidth spikes? Maybe all zeroes? This led me to another charts: https://s8.hostingkartinok.com/uploads/images/2017/06/8cefb70fce667a1b89c783... https://s8.hostingkartinok.com/uploads/images/2017/06/2e42634ea3f9b71df8a7fd... x here is "Advertised Bandwidth", y is "Consensus Weight". I was expected to see something close to x = y line.
Thanks for doing these graphs! They look as close to the x = y line as I would expect. It doesn't surprise me that there is bias at the lower end. This is less important than bias or variance at the high end.
But result was much worse. First problem (not too important) is a lot of randomness. 5 MiB relay can be easily detected as 1 MiB or 10 MiB.
This is normal: what a relay sees as its own maximum bandwidth is often different from the sustained bandwidth the tor network can get out of it.
Second one is a thing, which, probably, steals a lot of available network bandwidth: relays with low "Advertised Bandwidth" gets much less traffic than they can handle. Almost no relay with speed < 500 KiB is rated correctly. Similarly, high-speed relays have higher weight than needed.
This is good for clients: high speed relays give low latencies.
If all 0-50KiB-estimated relays are capable of serving at least 100 KiB, fixing this problem will lead to ~ (100-25)*1082 = 82 MiB/s increase of network bandwidth. But they have even more potential, I think.
Bandwidth does not add in a simple way: we are trying to minimise the bandwidth-delay product for clients, not maximise the bandwidth used.
Overloaded relays are slow, and under-used fast, nearby relays are a waste. But this is hard to detect.
Do anyone have ideas how to solve this problem?
I'm not sure if this is a problem. And I'm not sure how many relays it impacts.
But we know there is a bias in Tor's measurements towards North America and Europe, because that's where most of the measurements are made from:
https://trac.torproject.org/projects/tor/wiki/doc/BandwidthAuthorityMeasurem...
We are working on fixing this by measuring from different places. It will also help if we get more bandwidth authorities.
T
-- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------