Thus spake Sebastian Urbach (sebastian@xxxxxxxxxx): > Around the 24 of November the performance graph reported a value below > 4 sec. per 50kb, and right now including the last few days we can > barely reach 6 sec. per 50kb. > > Or in other words, we lost way more than 50 % peformance since that > day. Unless you guys are about to really step up the game i strongly > suggest to shred the chances made in the last weeks. > > The original plan was to speed up things with the modified bandwidth > scanners. Its probably safe to say that this experiment is a > complete bust. Yeah, I agree. I think that it's now clear that both the variance and the mean of the torperf graphs are way above norm, and we don't have much other explaination for it other than the feedback experiment not working. The question is why? Intuitively, feedback makes a lot of sense. If there is a ton of spare capacity on fast nodes, why shouldn't we try to use it? Similarly, if slow nodes can't keep up with the network throughput average, clearly they are a bottleneck and should have reduced traffic directed at them until they have more spare capacity. What is causing it to break so badly on the torperf graphs, then? Is it bugs? Is it bad choice of setpoints? Is it that we are using the wrong metric? Until we have answers for at least some of these questions, I am inclined to keep playing with it. I've made the following changes this afternoon: 1. 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. 2. I have changed the circ failure target from the network average to 0.0% failure. 3. I have changed the Guard feedback interval from 2 weeks to 1 week. My plan is to let these changes run for another couple days, and if they don't seem to change anything, I plan to try 1 week on, 1 week off cycles of the experiment, to see if we can detect any patterns in exactly when and why torperf starts to go south. -- Mike Perry
Attachment:
pgptWP2nIlYNA.pgp
Description: PGP signature
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays