[Tor-BSD] high-bandwidth relays

[teor]

> On 30 Jun 2015, at 03:33 , Christian Sturm <reezer at reezer.org> wrote:
> 
> Signed PGP part
> On 06/29/2015 07:26 PM, George Rosamond wrote:
> > The question I have is running multiple Tor instances.  At what
> > point is it necessary?
> 
> I'd do that incrementally. Just set up your Tor relay and wait for one
> CPU to be exhausted.
> 

Tor's crypto is mostly multithreaded. But some other operations are single-threaded. So it's possible for Tor to exhaust one CPU, but only partially use other CPUs. Another Tor instance can fully utilise another CPU, and the crypto threads can use the remaining CPUs.

So if you have 4 or more cores, I'd start with 2 Tor instances.

The current Tor network limits you to 2 instances per public IPv4 address. This is a feature that mitigates sybil attacks, by tying the number of instances to the scarcity of IPv4 addresses. If 2 instances don't utilise all your cores after several months, then you may want to consider another IPv4 address and another instance or two.

> When your CPU on Tor averages to close to 100% (will take a while) you
> can set up a new instance.

Please see
https://blog.torproject.org/blog/lifecycle-of-a-new-relay
to understand the growth rate that you should expect, based on how the network uses new relays over time.

> You will then see how much throughput a single instance can handle.

I'm working on a way of load testing a tor relay's CPU, by running a local Tor test network. Because all the network communication is on localhost, this helps you work out the maximum CPU-bound throughput of your relay. There's a draft implementation, but it's not quite ready for release yet. So waiting a few months for the network ramp-up is your best option.

It should be ready some time in the next few months, watch this Trac ticket for details:
https://trac.torproject.org/projects/tor/ticket/14175

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
pgp 0xABFED1AC
https://gist.github.com/teor2345/d033b8ce0a99adbc89c5

teor at blah dot im
OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.nycbug.org/pipermail/tor-bsd/attachments/20150630/47a7a082/attachment.bin>