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