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

Re: [tor-bugs] #29427 [Core Tor/Tor]: kist: Poor performance with a small amount of sockets



#29427: kist: Poor performance with a small amount of sockets
-----------------------------+------------------------------------
 Reporter:  dgoulet          |          Owner:  (none)
     Type:  defect           |         Status:  new
 Priority:  Medium           |      Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor     |        Version:  Tor: 0.3.2.1-alpha
 Severity:  Major            |     Resolution:
 Keywords:  tor-sched, kist  |  Actual Points:
Parent ID:                   |         Points:
 Reviewer:                   |        Sponsor:
-----------------------------+------------------------------------

Comment (by dgoulet):

 Replying to [comment:2 robgjansen]:
 > KIST was designed for relays. Clients don't need to prioritize traffic
 the same way relays do, so they don't really need KIST. Clients can simply
 run the vanilla scheduler so that they read/write ASAP (rather than
 deferring I/O like KIST does). Or clients can run KIST with a 1 msec
 scheduling frequency.

 Fortunately, right now, it is easy for Tor to know if it is running has a
 relay or not. Easy solution is to adjust the `KISTSchedRunInterval` to
 2msec (initial testing at 1msec is locking tor apparently, need to be
 investigated) for clients *only*.

 What I worry here is for onion service. They can have a *lot* of circuits
 to many rendezvous points so there is a clear requirement for circuit
 priority and not loading the Guard link which KIST would basically help.
 But then, we don't have a way to measure the NIC used throughput for
 clients/HS :S ...

 > I don't know how each relay can reliably compute the value of b. Maybe
 we start with the "observed bandwidth" as an estimate? But then we need to
 allow b to grow in case the relay suddenly got faster, or for new relays?

 For relays, I think the observed bandwidth from the consensus could be a
 good start until we have a reliable way for Tor to measure its throughput
 regularly.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/29427#comment:3>
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