[Tor-BSD] Fwd: Another Possible OpenBSD Speed Culprit

[teor]

And here is Libertas' reply (forwarded with permission):

Begin forwarded message:

> From: Libertas <libertas at mykolab.com>
> Subject: Re: [Tor-BSD] Another Possible OpenBSD Speed Culprit
> Date: 26 December 2014 15:43:02 AEDT
> To: teor <teor2345 at gmail.com>
> 
> Let me know if you're okay with me later forwarding some of this to the
> mailing list if it seems generally useful.
> 
>> Is tor compute-bound on your relay?
> 
> No, not even close. top currently reports ~12% CPU usage across four
> cores, so about 3% per core. It's an acceptably powerful dedicated server.
> 
> Its total memory footprint is currently 129 MB out of 2 GB.
> 
>> Is your relay a guard or an exit?
> 
> An exit.
> 
>> (Currently, non-exit relays can expect a utilisation around 35% of their
>> consensus weight, as there is an oversupply of non-exit relays in the
>> network. You're getting 15%, which is quite low. )
> 
> Indeed.
> 
> My past OpenBSD exit, which was in a completely different situation:
> VMWare or VirtualBox (I forget which) with bsdvm.com. It had similarly
> unimpressive throughput.
> 
> It seems like most people have the same experience with OpenBSD - the
> current highest-bandwidth OpenBSD relay moves <2.2 MB/s, and the next
> one down moves 848 KB/s. I'm third.
> 
>> I get the same warning on OS X when I build against the system OpenSSL,
>> but when I compiled my own with enable-ec_nistp_64_gcc_128 the warning
>> went away.
> 
> I figured there was a reason these were disabled, though. Also, I'm not
> sure if they're even optional on LibreSSL, which is the SSL library for
> OpenBSD 5.6+. I'd have to check with the OpenBSD mailing lists on both
> accounts.
> 
>> Your consensus weight looks about right for your bandwidth, but it could
>> theoretically be 10MB/s. How well-connected are you with the bandwidth
>> authorities, and the rest of the world?
> 
> Not sure, I have little experience testing this kind of thing. I
> remember doing a file copy test with scp and being pretty pleased with
> the results.
> 
> Let me know if you have a way of doing this that you find informative.
> 
>> Is your tor able to connect out on all ports?
>> (Or at least 9001 and 443.)
>> Are others able to connect to your IP from most IPs?
>> Are you using port 9001 or 443 for your relay?
>> (Other ports can be blocked by firewalls at either end.)
> 
> My pf configuration is as follows:
> 
>> # increase default state limit from 10'000 states on busy systems
>> #set limit states 100000
>> 
>> # give a response TCP packet with the RST flag instead of ignoring
>> set block-policy return
>> 
>> set skip on lo
>> 
>> # should maybe include random-id as per:
>> #   http://serverfault.com/questions/412083/openbsd-pf-match-in-all-scrub-no-df-causes-https-to-be-unreachable-on-mobile
>> match in all scrub (no-df)
>> 
>> block in all
>> 
>> pass out quick on egress inet keep state
>> 
>> # add ORPort when necessary
>> pass in on egress inet proto tcp from any to any port { 22 80 443 }
> 
> That is, I allow all outgoing traffic and only allow incoming
> connections that are TCP and on 22, 80, or 443.
> 
> I got this cleared by some people on Freenode's #openbsd that are pretty
> knowledgeable, so I'm reasonably confident in it.
> 
>> Have you tried running a second tor instance on 443 or 9001 (whichever
>> you're not using)?
>> This may double your utilisation, as both relays could theoretically
>> achieve 4.8MB/s at the same time. Of course, this will only help if tor
>> is maxed out on one CPU, but can't fully utilise the others. (It's not
>> particularly multithreaded, and the cpuworker processes only do so
>> much.) This slightly decreases anonymity, as it decreases the mixing of
>> packets received by your box. But it's better than not using the
>> bandwidth at all.
> 
> No. Because the system usage is negligible, I figured this wasn't the issue.
> 
>> Are you using any of the *Bandwidth* or Accounting* options?
> 
> Nope.
> 
>> NumCPUs is generally automatically configured, but may not detect
>> virtual CPUs (i.e. hyperthreading). Try checking that the number of tor
>> processes is one more than the number of virtual CPUs (master +  1
>> cpuworker for each CPU thread).
> 
> It's currently at 4 because I'm on a four-core machine. I could change
> it, but again, it certainly doesn't seem CPU-bound.
> 
>> HardwareAccel should be set to 1.
> 
> Hmm, I hadn't heard of this before. I actually remember once getting a
> warning message in my tor logs about not having enough available
> randomness, so this could be it. However, I know OpenBSD recently came
> out saying that they no longer trust Intel RNGs, so I'm not sure if its
> even supported on my machine.
> 
> I'll look into it.
> 
>> Do you have a DirPort? If you serve directory requests, this will
>> increase your bandwidth usage :-)
> 
> I do, and I'm currently listed as a V2Dir:
> 
> https://atlas.torproject.org/#details/CDAB3AE06A8C9C6BF817B3B0F1877A4B91465699
> 
> Let me know if any of this is enlightening, and thanks so much for the
> thorough help!



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nycbug.org/pipermail/tor-bsd/attachments/20150101/f2b0e9e7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.nycbug.org/pipermail/tor-bsd/attachments/20150101/f2b0e9e7/attachment.bin>