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

teor teor2345 at gmail.com
Thu Jan 1 02:05:34 EST 2015

I meant to send this to the list, but I hit the wrong reply button:

From: teor <teor2345 at gmail.com>
Subject: Re: [Tor-BSD] Another Possible OpenBSD Speed Culprit
Date: 26 December 2014 14:55:01 AEDT
To: Libertas <libertas at mykolab.com>

On 26 Dec 2014, at 13:53, Libertas <libertas at mykolab.com> wrote:

> I just remembered that this shows up in my logs whenever I restart tor:
>> We were built to run on a 64-bit CPU, with OpenSSL 1.0.1 or later,
>> but with a version of OpenSSL that apparently lacks accelerated
>> support for the NIST P-224 and P-256 groups. Building openssl with
>> such support (using the enable-ec_nistp_64_gcc_128 option when
>> configuring it) would make ECDH much faster.
> My relay is still underperforming, moving ~ 750 KB/s when its consensus
> weight was up to 4.8 MB/s and its uplink is 100 Mbps. I know it isn't
> the file descriptors, as it has at least 8192 available.
> Does anyone know about SSL ciphers? Might this reasonably be the cause
> of OpenBSD not attaining what would be expected of the hardware and network?

Is tor compute-bound on your relay?
Is your relay a guard or 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. )

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 can't comment on any speed increase, because my tor is network-bound.

I'm not sure if any of this has already been mentioned, but:

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?

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.)

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.

(At the moment, the tor network limits the number of routers per public IP to 2.
So you'll need another IP to go beyond two instances on the same box.)

There are also various torrc options you can try:

Are you using any of the *Bandwidth* or Accounting* options? Disable them.

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).

HardwareAccel should be set to 1.

Do you have a DirPort? If you serve directory requests, this will increase your bandwidth usage :-)

Hope something here helps.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nycbug.org/pipermail/tor-bsd/attachments/20150101/e4a81591/attachment-0001.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/e4a81591/attachment-0001.bin>

More information about the Tor-BSD mailing list