On Wed, Nov 30, 2011 at 05:51:13PM -0600, Scott Bennett wrote:
Something new appears to be happening in the authorities' assignmentsof "Bandwidth=" values in the consensus documents over the past few days. Here are some statistics from the recent consensus with the following valid times:
[snip]
The top ten in the above list account for 814 relays or 32.73% of all relays in the consensus, yet they will get little or no traffic because of the assigned "Bandwidth=" values. My relay's traffic went from around 55% - 60% of what I had hoped to contribute down to almost nothing in the course of about three days, and the "Bandwidth=" value assigned to it in the consensus is 1. For a long time, it had typically been in the high 20s to high 30s with occasional excursions from slightly lower to somewhere in the 50s. So is this sudden, massive reassignment of loads due to a bug in the newest tor version(s)? Or is it an intended change by the developers?
Mike Perry is trying out more network rebalancing ideas. See
https://gitweb.torproject.org/torflow.git/blob/HEAD:/NetworkScanners/BwAutho... https://trac.torproject.org/projects/tor/ticket/1976 https://trac.torproject.org/projects/tor/ticket/4425
The "bandwidth authority" scripts do active bandwidth measurements, and adjust the bandwidth weights they vote about based on how a relay performs compared to its peers. Last week "peers" were characterized based on the self-advertised bandwidth, that is, the bandwidth in the relay descriptor. With the new PID design, "peers" are now a function of the weight in the consensus.
In theory this feedback loop should drive even more traffic toward relays that can handle it, and even less traffic toward relays that can't, until we reach an equilibrium.
In practice, it drives super-fast relays to a weight of infinity, and all the rest to a weight of zero.
Mike thought he'd gotten things (more) right this time, but it would appear that has hasn't: https://metrics.torproject.org/performance.html#torperf
Sorry for the disturbance. I think we should probably turn the experiment off soon. But the little dip you see in the torperf graph before the spike makes me think there *is* a point here that is better, even if we haven't found it yet. :)
Thanks, --Roger