Re: [tor-relays] bandwidth authority algorithm is cracked
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). Wait... So if I understand this correctly the bandwidth number is the difference between the actual bandwidth of the node and the actively utilized bandwidth? I looked high-and-low for a proper definition of the value, short of spending a day reading the source code, and did not find this. The way that the bandwidth status pages are ranked leads one to believe that the consensus bandwidth is effectively the size of the relays when in fact the ranking shows them in the order of unused bandwidth. If my understanding is now correct, then at least for the smaller node I administer, the numbers I see are perfectly sensible. Provided that the node is functioning, a lower number is a better number because that means the node is seeing significant use. However I must complain that the consensus bandwidth does not say much about the relative health of a relay. Does a good (ungamable) way exist to show the bandwidth capacity of relays along with the available capacity? Some information on the proper interpretation of bandwidth values ought to be placed somewhere prominent on the TorProject wiki. One paragraph would have preempted my posting this thread. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] bandwidth authority algorithm is cracked
On Wed, Jan 22, 2014 at 02:33:21PM -0500, Roger Dingledine wrote: The consensus weight is computed using a) the relay's self-advertised bandwidth in its descriptor: https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt#l389 b) the ratios of bandwidth weights for various types of relays: https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt#l2137 and c) the result of the active measurements from the bandwidth authorities: https://gitweb.torproject.org/torflow.git/blob/HEAD:/NetworkScanners/BwAuthority/README.BwAuthorities https://gitweb.torproject.org/torflow.git/blob/HEAD:/NetworkScanners/BwAuthority/README.spec.txt I take it back -- the consensus weight is computed using 'a' and 'c' above, and then clients consider 'b' and the weights when selecting relays. --Roger ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] bandwidth authority algorithm is cracked
On Wed, Jan 22, 2014 at 01:02:29PM -0500, starlight.201...@binnacle.cx wrote: 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). Wait... So if I understand this correctly the bandwidth number is the difference between the actual bandwidth of the node and the actively utilized bandwidth? No. The bandwidth number is how much attention clients should give the relay. That is, it's a weighting that clients use when selecting relays, and they select a given relay proportional to its bandwidth weight. I looked high-and-low for a proper definition of the value This is where the consensus weight is described: https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt#l1634 The consensus weight is computed using a) the relay's self-advertised bandwidth in its descriptor: https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt#l389 b) the ratios of bandwidth weights for various types of relays: https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt#l2137 and c) the result of the active measurements from the bandwidth authorities: https://gitweb.torproject.org/torflow.git/blob/HEAD:/NetworkScanners/BwAuthority/README.BwAuthorities https://gitweb.torproject.org/torflow.git/blob/HEAD:/NetworkScanners/BwAuthority/README.spec.txt However I must complain that the consensus bandwidth does not say much about the relative health of a relay. Does a good (ungamable) way exist to show the bandwidth capacity of relays along with the available capacity? Ungameable is a much harder requirement. See e.g. http://freehaven.net/anonbib/#eigenspeed but Eigenspeed does not do well at assessing the speed of fast relays, since it's hard to design a system where relays can accurately assess the speed of faster relays. --Roger ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] bandwidth authority algorithm is cracked
This helps tremendously--thank you. For the most part then it appears the consensus bandwidth values assigned to the relay here are within reasonable expectation allowing for the methodology. Lately have been seeing fairly stable and moderate number of 225k vs the local 495k calculation. Next time I see a wild swing I'll pull the raw data and try to make sense of it. Will post if it's seems inexplicable or as though a problem exists. At 14:37 1/22/2014 -0500, Roger Dingledine wrote: On Wed, Jan 22, 2014 at 02:33:21PM -0500, Roger Dingledine wrote: The consensus weight is computed using a) the relay's self-advertised bandwidth in its descriptor: https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt#l389 b) the ratios of bandwidth weights for various types of relays: https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt#l2137 and c) the result of the active measurements from the bandwidth authorities: https://gitweb.torproject.org/torflow.git/blob/HEAD:/NetworkScanners/BwAuthority/README.BwAuthorities https://gitweb.torproject.org/torflow.git/blob/HEAD:/NetworkScanners/BwAuthority/README.spec.txt I take it back -- the consensus weight is computed using 'a' and 'c' above, and then clients consider 'b' and the weights when selecting relays. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] bandwidth authority algorithm is cracked
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/BwAuthority/README.spec.txt 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.robi...@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.201...@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
Re: [tor-relays] bandwidth authority algorithm is cracked
Hi Karsten, and thank you very much for your answer. Few days ago I have re-started my 2 tor daemons (same identity, ArachnideFR94 and ArachnideFR94v2) on same the server on which I had these huge falling down/rising up/fall down again consensus weight problems. They started back from nearly 0 and there are currently gaining bandwith/consensus weight. I will try to analyse more precisely what will happen on the following days and weeks and keep you informed. I hope the problem will be back so I will try to understand the cause of this problem, watching everything you described to me. I think everybody agree to say that the title of the mail has great chances to be wrong (at least, it's fr far far too soon to make such an affirmation !) but I anwsered to this subject since I encountered exactly the same problem described by starlight, and this problem have completely destroyed the bandwith/consensus weight of a 20MB/s server - and avoided new ones to gain more than 1 or 2 MB/s bandwith on the same machine. Everything I have seen on Tor Atlas during the problem is a consensus weight shaking like an earthquake during an entire month (december, 2013), and the real bandwith of the server followed the consensus weight with few hours late, so today I cannot explain what happened. I will watch carefully what will happen now, and keep you informed of what I can understand if the problem is still existing (I hope so, nothing have changed into the server apart from few upgrades with apt-get). Maybe I will use a new Topic description for my next emails about this. Best regards ! Julien ROBIN - Mail original - De: Karsten Loesing kars...@torproject.org À: tor-relays@lists.torproject.org Envoyé: Mardi 21 Janvier 2014 10:59:22 Objet: Re: [tor-relays] bandwidth authority algorithm is cracked 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/BwAuthority/README.spec.txt 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.robi...@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.201...@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
Re: [tor-relays] bandwidth authority algorithm is cracked
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/BwAuthority/README.spec.txt 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.robi...@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.201...@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
Re: [tor-relays] bandwidth authority algorithm is cracked
This could be a test of whether anyone enforces a moderation policy here. On 14-01-21 05:59 PM, julien.robi...@free.fr wrote: Hi Mike, What you said is very interesting, it was the missing part for me to understand why the weight of the relay in the consensus can drop (or rise again) so quickly (sometimes 3 times per day) without being caused by any change of used bandwith on the network cable of the dedicated machine : the only visible changes in the server bandwith were visible a couple of minutes/hours after changes in consensus weight, and it was proportionnal. The cause of the problem I encountered will be found here : when the authority servers were doing bandwith measurement on it. May be an anormally great amount of circuits (depends on the origins and networks of these circuits) were almost unusable : for example if there is 50 percent chance to be measured with very very low bandwith when the authority server did the job. In this case, no error from the algorithm : he did his job - bad bandwith, bad ratio. With these informations, I would think that my server encounter(ed) some difficulty somewhere in these 2 possible locations : 1-Into the machine itself, causing aleatory bad bandwith on some circuits or circuits cannot establish*, ever with few people connected (quarter of the machine capacity the problem was still present, ever with new identities running alone with pretty slow bandwith, so we can exclude normal TCP/IP socket congestion between my relay and others ones). Also, I had no Your computer is too slow to handle this many creation requests while the problem was still present. 2-Difficulty to communicate with a particular point of the Internet network, point that is involved during bandwith measurements by authorities. If the problem is still present I got to verify by observing, on Tor Atlas, other relays that are on the same network service provider - if possible into the same datacenter (Iliad DC3, France, adresses like 88.191.xxx.xxx but may be not only). Another 2- May be great scale geographic networks problems on my ISP made circuits to have 50 percent chance to work fast and fine (and using all the available bandwith) and 50 percent chance to be slow and unusable, but it looks like a too big affair, I'm not sure it's really possible (and 50 percent is an example value). Is the measurement method the same for Exit Nodes and Middle/Entry Nodes ? *What is the decision of the authority algorithm when the relay to measure cannot be established into one or more circuits ? Thank you in advance ! I will wait and see for the following days or week and keep you informed. Julien ROBIN PS : while I am there, first fall down (consensus weight fraction divided by 2, 0.137% to 0.067%, now 12100, 0.77%) on ArachnideFR94v2 few minutes ago, (but with such low values, variation are may be normal, we got to wait and see, I will mark the consensus weight values into an excel tab to be sure of what I will see on following days and weeks). Exit probablity from 0.400 to 0.200 :( ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
