Re: Tor BSD underperformance (was [Tor-BSD] Recognizing Randomness Exhaustion)

2015-01-03 Thread Greg Troxel
teor teor2...@gmail.com writes:

 Tor 0.2.6.2-alpha (just in the process of being released) has some
 changes to queuing behaviour using the KIST algorithm.

 The KIST algorithm keeps the queues inside tor, and makes
 prioritisation decisions from there, rather than writing as much as
 possible to the OS TCP queues. I'm not sure how functional it is on
 *BSDs, but Nick Mathewson should be able to comment on that. (I've
 cc'd tor-dev and Nick.)

From skimming the KIST paper (I will read in detail when I find time),
it seems they are claiming increase in throughput of around 10%, with
the main benefit being lower latency.  So while that sounds great, it
doesn't seem like lack of KIST is the reason for the apparent 3x
slowdown observed in OpenBSD.

Does anyone have experience to report on any platform other than Linux
or OSX?

[demime 1.01d removed an attachment of type application/pgp-signature]



Re: Tor BSD underperformance (was [Tor-BSD] Recognizing Randomness Exhaustion)

2014-12-31 Thread teor
On 1 Jan 2015, at 07:39 , Greg Troxel g...@lexort.com wrote:

 Libertas liber...@mykolab.com writes:

 Some of the people at tor-...@lists.nycbug.org and I are trying to
 figure out why Tor relays under-perform when running on OpenBSD. Many
 such relays aren't even close to being network-bound,
 file-descriptor-bound, memory-bound, or CPU-bound, but relay at least
 33-50% less traffic than would be expected of a Linux machine in the
 same situation.

 I'm more familiar with NetBSD, but hopefully my comments are helpful.

 For those not familiar, a Tor relay will eventually have an open TCP
 connection for each of the other 6,000 active relays, and (if it allows
 exit traffic) must make outside TCP connections for the user's requests,
 so it's pretty file-hungry and crypto-intensive.

 It may also have something to do with TCP.  A few thoughts:

 * run netstat -f inet and look and the send queues.  That's not really
  cleanly diagnostic, but if they are all huge, it's a clue

 * run netstat -m and vmstat -m (not sure those map from NetBSD).  Look
  for runnig out of mbufs and mbuf clusters.   Perhaps bump up
  NMBCLUSTERS in the kernel if it's not dynamic.

Tor 0.2.6.2-alpha (just in the process of being released) has some changes to
queuing behaviour using the KIST algorithm.

The KIST algorithm keeps the queues inside tor, and makes prioritisation
decisions from there, rather than writing as much as possible to the OS TCP
queues. I'm not sure how functional it is on *BSDs, but Nick Mathewson should
be able to comment on that. (I've cc'd tor-dev and Nick.)


teor
pgp 0xABFED1AC
hkp://pgp.mit.edu/
https://gist.github.com/teor2345/d033b8ce0a99adbc89c5
http://0bin.net/paste/Mu92kPyphK0bqmbA#Zvt3gzMrSCAwDN6GKsUk7Q8G-eG+Y+BLpe7wtm
U66Mx

[demime 1.01d removed an attachment of type application/pgp-signature which had 
a name of signature.asc]