[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #7291 [Tor]: Investigate making MaxOnionsPending time-based
#7291: Investigate making MaxOnionsPending time-based
-------------------------+--------------------------------------------------
Reporter: mikeperry | Owner:
Type: enhancement | Status: needs_review
Priority: major | Milestone: Tor: 0.2.4.x-final
Component: Tor | Version:
Keywords: tor-relay | Parent:
Points: | Actualpoints:
-------------------------+--------------------------------------------------
Comment(by mikeperry):
Replying to [comment:4 nickm]:
> If we start to recommend high values for MaxOnionsPending, we should
look closely at the code for onion_pending_remove: It does a linear search
over the queue, which is probably not so good if we're looking forward to
a time of super-fast servers with leneant timeouts and a large volume of
ntor traffic. (T_max = 2 s, NumCPUS == 16, T_o == 150 usec => Wow, would
we even ever want to allow that?)
FWIW, on a good day, the circuit build timeout can get as low as 2-3
seconds. I don't think I've ever had a client get above 10 seconds. This
makes me think a queue of 2 seconds is probably too long, especially if it
means a ton more additional onionskins queued anyway.
Another way to approach this might be to work backwards and determine how
long 100 onionskins would take on various NumCPU=1 servers today (or just
estimate). Then you can set the limits for T_max to one of these values,
which would leave things unchanged for today's handshake on single core
servers but improve things for ntor and multicore servers?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7291#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs