-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/15/2011 3:43 PM, Mike Perry wrote:
I've made the following changes this afternoon:
- On the assumption that we're seeing the huge increase in
variance on torperf because faster nodes are only *sometimes* at max capacity, but most of the time have enough spare capacity to get good measurements, I have stopped "filtering" measurements for them (ie I have stopped selecting only the fast measurements). I am still applying filtering to overly punished nodes, so that they don't get punished too much by being paired with slow peers.
- I have changed the circ failure target from the network average
to 0.0% failure.
- I have changed the Guard feedback interval from 2 weeks to 1
week.
Mike,
Some more data points for you...
* We relieved the interrupt pressure on our big node by splitting across two interfaces, and as a result BigBoy has stabilized pretty well at Bandwidth=1900000 in the consensus, which seems to be right around the point at which it is consuming CPU in such a way that I would expect circuit creation errors if it went much higher (so that seems good).
* However, {Red,Green,Gold,White}Dragon all still seem to be stalled as far as their actual bandwidth usage, though I do see that their bandwidth measurements in the consensus have been changing somewhat (though some have gone down as others have gone up). I don't see any indications of failures in their logs (other than the write failures to the directory authorities periodically).
* Finally, I fired up a new relay on this box yesterday, Ramsgate, which has not gone above Bandwidth=82 yet. Pre-experiment (and even earlier in the experiment) this node would have been able to attract traffic by now (>12 hours after it was started).
Thanks, Tim
- -- Tim Wilde, Senior Software Engineer, Team Cymru, Inc. twilde@cymru.com | +1-847-378-3333 | http://www.team-cymru.org/