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

Re: [tor-bugs] #12891 [Tor]: Simulate KIST - global scheduling (#9262) and socket write limits (#12890)

#12891: Simulate KIST - global scheduling (#9262) and socket write limits (#12890)
----------------------------+--------------------------------
     Reporter:  robgjansen  |      Owner:  robgjansen
         Type:  task        |     Status:  new
     Priority:  normal      |  Milestone:  Tor: 0.2.7.x-final
    Component:  Tor         |    Version:
   Resolution:              |   Keywords:  tor-relay
Actual Points:              |  Parent ID:  #12541
       Points:              |
----------------------------+--------------------------------

Comment (by robgjansen):

 Update time.

 I went back to the stable Tor network topology model that we used in the
 KIST paper in order to verify the performance issues I alluded to in my
 last post. The topology contained 3600 relays and 12000 clients. I ran
 nickm's kist branch merged with tor-0.2.6.2-alpha, in order to take
 advantage of the new `TestingDirAuthVoteGuard` and
 `TestingDirAuthVoteExit` options. I ran one experiment with `UseKIST 1`
 and another with `UseKIST 0`.

 The results are very similar to those obtained from my old topology and
 last set of experiments. The
 [https://trac.torproject.org/projects/tor/attachment/ticket/12891/shadow.perf.results.pdf
 performance] and
 [https://trac.torproject.org/projects/tor/attachment/ticket/12891/shadow.goodput.results.pdf
 throughput] results are attached. As you can see, performance is worse
 when using the current KIST implementation than without it, and aggregate
 network throughput drops by almost half.

 My current thinking is that we are starving the kernel and therefore not
 utilizing all available bandwidth of the relays, but more logging in the
 KIST branch would help give us some hard data about this potential
 problem.

 Next I want to play around with `KISTSockBufSizeFactor`, so that we always
 write much more to the buffer than we think we need to. For example, I
 could set it extremely high to approximate the old behavior and make sure
 we avoid kernel starvation. I think that will give us a useful data point.

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