Also keep in mind that what the bandwidth authorities actually measure is not total capacity but spare stream capacity (by downloading large files through at least 5 different two hop circuits times for each relay). They then use this stream throughput measurement to create a multiplier to multiply your descriptor bandwidth by. The multiplier is the ratio of your average measured spare stream capacity to the network average stream spare capacity.
The reasoning behind this is that the bandwidth authorites are a load balancing mechanism that is meant to reallocate consensus weight to relays that are underutilized from relays that are overutilized. If your relay experiences bursts of traffic, the authorities may measure you as having low stream capacity. However, there are 5 of them, and we take the median measurement of all 5. Again, each bandwidth authority also performs 5 measurements of each relay in two hop circuits, pairing it with relays of similarly observed spare stream capacity.
But yes, it is possible that something has broken in the years since they have had serious attention. Currently Aaron Gibson devotes some cycles to fixing issues among his other responsibilities, but we could use a dedicated pair of eyes keeping track of their behavior, especially as new Tor versions are released.
Karsten Loesing:
Hi starlight, hi Julien,
the bandwidth scanner system is quite complex, so it might be the case that part of it is broken. But from this thread that's hard to say, and it's impossible to know what part needs fixing.
Want to help us debug the problem(s) you observed?
Here are a few possible starting points:
- Search your relays in Atlas at https://atlas.torproject.org/, look at
the graphs at the bottom, and tell us at what times you think the "consensus weight fraction" plot is totally off.
- Read Roger's blog post
https://blog.torproject.org/blog/lifecycle-of-a-new-relay and tell us how much your findings overlap or do not overlap with the expectations stated in that blog post.
- More ambitiously, download the vote documents from the metrics
website at https://metrics.torproject.org/data.html, find your relay in the votes produced by bandwidth authorities, and tell us what unexpected things you found while doing so.
- Even more ambitiously, read the bandwidth scanner spec at
https://gitweb.torproject.org/torflow.git/blob/HEAD:/NetworkScanners/BwAutho... and tell us what data we could obtain from the bandwidth scanners to further debug this problem.
Thanks!
All the best, Karsten
On 1/10/14 9:37 AM, julien.robin28@free.fr wrote:
I had the same problem since begining of december on my ArachnideFR94 server (88.191.192.25, service provider : Iliad - Online.net) : Consensus weight from more than 100,000 to brutally 6,000 and 20,000, after a few time rise up to 50,000, and brutally fall down back 3,000 and 10,000 the following day, 30,000, 12,000, 8,000... after an entire month of bandwith never rising back and falling down even lower, after i tryed everything (create a new server identity, but after some weeks, same problem), seeing worst and worst, end of november my bandwith was about 20MB/s (sometimes into the top 5 of the world biggest servers !), it was about 0,9MB/s when I decided to close it.
No problem of bandwith with the service provider, the bandwith graph were just starting to brutally go down a couple of minutes after the consensus weight brutally fall back. I was thinking it was because too many tor relays are running on this service provider (since end of July, 2013, Tor relays are accepted by this service provider and the service provider also opened to internationnal with interesting prices).
And I have no problem with my 2 others servers at "Digicube" service provider.
If it can help !
Best regards Julien ROBIN
----- Mail original ----- De: "starlight 2014q1" starlight.2014q1@binnacle.cx À: tor-relays@lists.torproject.org Envoyé: Vendredi 10 Janvier 2014 05:49:20 Objet: [tor-relays] bandwidth authority algorithm is cracked
The bandwidth authorities assign all kinds of wildly incorrect capacities to the Tor node here.
The Tor relay software has been up for 45 days and has not been down for more than five minutes for three or four months.
Occasional outages from the ISP mucking with their network, but nothing more than ten or fifteen minutes in any week.
The local node bandwidth calculation is consistently 490-495 Kbytes/sec. Very stable. Very consistent.
The Tor bandwidth authorities assign values anywhere from 100 Kbytes/sec to almost 700 Kbytes/sec in an oscillating pattern with a period of about one week.
Something is seriously wrong with that.
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays