[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-relays] Bandwidth Authority PID Feedback Experiment #2 Starting



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