[tor-relays] hardware

[Mike Perry]

Andy Isaacson:
> On Thu, Jul 11, 2013 at 08:46:20PM +0200, Andreas Fink wrote:
> > can someone give me hints on what hardware would be best suited to run
> > big fat tor exit nodes connected with multiple 1gbps or 10gps links?
> > We are considering putting some fat boxes near major internet
> > exchanges of the world.
> 
> Modern Xeon, AES-NI is helpful, HT is not very helpful (but not hurtful
> either), higher clock rate is more helpful than more cores.  4GB of RAM
> per core, you can probably get away with 2GB/core but why skimp.
> Noisetor uses most of a 4-core X3350 2.6 GHz to push ~500 Mbps
> symmetric.  That's without AES-NI, so I'd expect a quadcore 2.5 GHz
> AES-NI to be able to fill a 1Gbps pipe.

This sounds right (~100Mbit per CPU core without AES-NI), but it would
be good to hear Moritz weigh in here with some additional datapoints for
AES-NI. Last I heard, AES-NI gets you ~300Mbit per core, but I have no
direct experience myself.

The key thing to know is that Tor is still not great at multithreading.
In fact, the torrc option 'NumCPUs' is mostly useless for relays at
this scale.

For this reason, you want to run one tor daemon per CPU core, with a max
of two per IP, and something like 2-4GB of RAM per daemon like Andy
said. That's why we have noiseexit01a-d, Amunet1-8, manning1-2, etc. 

You probably also shouldn't run too many of these sized relays by
yourself, either. It is generally considered poor form to run too much
of the Tor network by yourself until other people can catch up and
balance your efforts. I would look for ways to decentralize/delegate
once you got beyond a couple gbits or so for this reason. Please feel
free to ask the list for suggestions on legal and admin structure for
accomplishing this.


-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20130711/8cb1ab9a/attachment.sig>