[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-relays] 0.2.5.10 / 0.2.6.x and ticket 9682
On Sat, Mar 07, 2015 at 12:53:39PM +0100, Sebastian Urbach wrote:
> Hard to tell pretty much says it all :-( Not much of a change. Now
> the multithread feature becomes the last hope :-)
>
> Thanks gor your reply, domehow i expected it zo be more of a boost
> after reading Nick's text:
>
> https://blog.torproject.org/blog/coming-tor-026
The main reason I'm excited about
https://trac.torproject.org/projects/tor/ticket/9682
is because it should handle high circuit creation loads better.
When the botnet hit a few years ago, there were suddenly five million
new Tor clients all sending create cells pretty often:
https://trac.torproject.org/projects/tor/ticket/9657
It got to the point where many relays were at 100% cpu and still rejecting
many of the create cells they received. And they were waiting in the
queue and timing out, rather than being rejected preemptively. We added
some logic to count (for that particular relay) how long it takes us to
handle a create cell, and then when we had so many queued already that
we know we won't get to the new one in time, we rejected it early.
But that logic never actually worked -- cpuworkers spent a lot of time
idle, because we only measured "time to process the create cell", not
"time for the main thread to notice that the cpuworker can handle another
one, and then time to give it to the cpuworker, and then time to process
the create cell":
https://trac.torproject.org/projects/tor/ticket/9574#comment:29
This new patch in 0.2.6.3 greatly reduces the first two of these three
items.
So in summary, in times when create cell load becomes huge again, we
should be able to handle many more of them than before.
--Roger
_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays