<div dir="ltr"><div>Pardon the thread necromancy, but I'm wondering if this document ever made its way off this mailing list and onto a blog? Or perhaps there is some other modern doc covering this topic?</div><div><br></div><div>I've recently setup a relay on a Gb/s fiber connection, and am struggling to understand how to optimize performance. It's not clear 5 years later which if any of the tweaks listed below are still relevant. I'm running a modern debian-based system.</div><div><br></div><div>Thanks in advance.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">After talking to Moritz and Olaf privately and asking them about their<br>nodes, and after running some experiments with some high capacity<br>relays, I've begun to realize that running a fast Tor relay is a<br>pretty black art, with a lot of ad-hoc practice. Only a few people<br>know how to do it, and if you just use Linux and Tor out of the box,<br>your relay will likely underperform on 100Mbit links and above.<br>In the interest of trying to help grow and distribute the network, my<br>ultimate plan is to try to collect all of this lore, use Science to<br>divine out what actually matters, and then write a more succinct blog<br>post about it.<br>However, that is a lot of work. It's also not totally necessary to do<br>all this work, when you can get a pretty good setup with a rough<br>superset of all of the ad-hoc voodoo. This post is thus about that<br>voodoo.<br>Hopefully others will spring forth from the darkness to dump their own<br>voodoo in this thread, as I suspect there is one hell of a lot of it<br>out there, some (much?) of which I don't yet know. Likewise, if any<br>blasphemous heretic wishes to apply Science to this voodoo, they<br>should yell out, "Stand Back, I'm Doing Science!" (at home please, not<br>on this list) and run some experiments to try to eliminate options<br>that are useless to Tor performance. Or cite academic research papers.<br>(But that's not Science, that's computerscience - which is a religion<br>like voodoo, but with cathedrals).<br>Anyway, on with the draft:<br><br>== Machine Specs ==<br>First, you want to run your OS in x64 mode because openssl should do<br>crypto faster in 64bit.  <br>Tor is currently not fully multithreaded, and tends not to benefit<br>beyond 2 cores per process. Even then, the benefit is still marginal<br>beyond just 1 core. 64bit Tor nodes require about one 2Ghz Xeon/Core2<br>core per 100Mbit of capacity.<br>Thus, to fill an 800Mbit link, you need at least a dual socket, quad<br>core cpu config.  You may be able to squeeze a full gigabit out of one<br>of these machines. As far as I know, no one has ever done this with<br>Tor, on any one machine.<br>The i7's also just came out in this form factor, and can do<br>hyperthreading (previous models may list 'ht' in cpuinfo, but actually<br>don't support it). This should give you a decent bonus if you set<br>NumCPUs to 2, since ht tends to work better with pure integer math<br>(like crypto). We have not benchmarked this config yet though, but I<br>suspect it should fill a gigabit link fairly easily, possibly<br>approaching 2Gbit.<br>At full capacity, exit node Tor processes running at this rate consume<br>about 500M of ram. You want to ensure your ram speed is sufficient,<br>but most newish hardware is good. Using on this chart:<br><a href="https://secure.wikimedia.org/wikipedia/en/wiki/List_of_device_bandwidths#Memory_Interconnect.2FRAM_buses">https://secure.wikimedia.org/wikipedia/en/wiki/List_of_device_bandwidths#Memory_Interconnect.2FRAM_buses</a><br>you can do the math and see that with a dozen memcpys in each<br>direction, you come out needing DDR2 to be able to push 1Gbit full<br>duplex.<br>As far as ethernet cards, the Intel e1000e *should* be theoretically<br>good, but they seem to fail at properly irq balancing across multiple<br>CPUs on recent kernels, which can cause you to bottleneck at 100% CPU<br>on one core. At least that has been Moritz's experience. In our<br>experiments, the RTL-8169 works fine (once tweaked, see below).<br><br>== System Tweakscript Wibbles and Config Splatters ==<br>First, you want to ensure that you run no more than 2 Tor instances<br>per IP. Any more than this and clients will ignore them.<br>Next, paste the following smattering into the shell (or just read it<br>and make your own script):<br># Set the hard limit of open file descriptors really high.<br># Tor will also potentially run out of ports.<br>ulimit -SHn 65000<br># Set the txqueuelen high, to prevent premature drops<br>ifconfig eth0 txqueuelen 20000<br># Tell our ethernet card (interrupt found from /proc/interrupts)<br># to balance its IRQs across one whole CPU socket (4 cpus, mask 0f).<br># You only want one socket for optimal ISR and buffer caching.<br>#<br># Note that e1000e does NOT seem to obey this, but RTL-8169 will.<br>echo 0f > /proc/irq/17/smp_affinity<br># Make sure you have auxiliary nameservers. I've seen many ISP<br># nameservers fall over under load from fast tor nodes, both on our<br># nodes and from scans. Or run caching named and closely monitor it.<br>echo "nameserver 8.8.8.8" >> /etc/resolv.conf<br>echo "nameserver 4.2.2.2" >> /etc/resolv.conf<br># Load an amalgam of gigabit-tuning sysctls from:<br># <a href="http://datatag.web.cern.ch/datatag/howto/tcp.html">http://datatag.web.cern.ch/datatag/howto/tcp.html</a><br># <a href="http://fasterdata.es.net/TCP-tuning/linux.html">http://fasterdata.es.net/TCP-tuning/linux.html</a><br># <a href="http://www.acc.umu.se/~maswan/linux-netperf.txt">http://www.acc.umu.se/~maswan/linux-netperf.txt</a><br># <a href="http://www.psc.edu/networking/projects/tcptune/#Linux">http://www.psc.edu/networking/projects/tcptune/#Linux</a><br># and elsewhere...<br># We have no idea which of these are needed yet for our actual use<br># case, but they do help (especially the nf-contrack ones):<br>sysctl -p << EOF<br>net.ipv4.tcp_rmem = 4096 87380 16777216<br>net.ipv4.tcp_wmem = 4096 65536 16777216<br>net.core.netdev_max_backlog = 2500<br>net.ipv4.tcp_no_metrics_save = 1<br>net.ipv4.tcp_moderate_rcvbuf = 1<br>net.core.rmem_max = 1048575<br>net.core.wmem_max = 1048575<br>net.ipv4.ip_local_port_range = 1025 61000<br>net.ipv4.tcp_synack_retries = 3<br>net.ipv4.tcp_tw_recycle = 1<br>net.ipv4.tcp_max_syn_backlog = 10240<br>net.ipv4.tcp_fin_timeout = 30<br>net.ipv4.tcp_keepalive_time = 1200<br>net.netfilter.nf_conntrack_tcp_timeout_established=7200<br>net.netfilter.nf_conntrack_checksum=0<br>net.netfilter.nf_conntrack_max=131072<br>net.netfilter.nf_conntrack_tcp_timeout_syn_sent=15<br>net.ipv4.tcp_keepalive_time=60<br>net.ipv4.tcp_keepalive_time = 60<br>net.ipv4.tcp_keepalive_intvl = 10<br>net.ipv4.tcp_keepalive_probes = 3<br>net.ipv4.ip_local_port_range = 1025 65530<br>net.core.netdev_max_backlog=300000<br>net.core.somaxconn=20480<br>net.ipv4.tcp_max_tw_buckets=2000000<br>net.ipv4.tcp_timestamps=0<br>vm.min_free_kbytes = 65536<br>net.ipv4.ip_forward=1<br>net.ipv4.tcp_syncookies = 1<br>net.ipv4.tcp_synack_retries = 2<br>net.ipv4.conf.default.forwarding=1<br>net.ipv4.conf.default.proxy_arp = 1<br>net.ipv4.conf.all.rp_filter = 1<br>net.ipv4.conf.default.send_redirects = 1<br>net.ipv4.conf.all.send_redirects = 0<br>EOF<br># XXX: ethtool wibbles <br># You may also have to tweak some parameters with ethtool, possibly<br># also enabling some checksum offloading or irq coalescing options to<br># spare CPU, but for us this hasn't been needed yet.<br><br>== Setting up the Torrc ==<br>Basically you can just read through the stock example torrc, but there<br>are some as-yet undocumented magic options, and options that need new<br>defaults.<br># NumCPUs doesn't provide any benefit beyond 2, and setting it higher<br># may cause cache misses.<br>NumCPUs 2<br># These options have archaic maximums of 2-5Mbyte<br>BandwidthRate 100 MB<br>BandwidthBurst 200 MB<br><br>== Waiting for the Bootstrap and Measurement Process ==<br>Perhaps the most frustrating part of this setup is how long it takes<br>for you to acquire traffic. If you are starting new at an ISP, I would<br>consider only 200-400Mbit for your first month. Hitting that by the<br>end of the month may be a challenge, mostly because their may be dips<br>and total setbacks along the way.<br>The slow rampup is primarily due to limitations in Tor's ability to<br>rapidly publish descriptor updates, and to measure relays.<br>It ends up taking about 2-3 days to hit an observed bandwidth of<br>2Mbyte/sec per relay, but it can take well over a week or more (Moritz, do<br>you have a better number?) to reach 8-9Mbyte/relay. This is for an<br>Exit node. A middle node will likely gather traffic slower. Also once<br>you crash, you lose it. This bug is about that issue:<br><a href="https://trac.torproject.org/projects/tor/ticket/1863">https://trac.torproject.org/projects/tor/ticket/1863</a><br>There is also a potential dip when you get the Guard flag, as our load<br>balancing formulas try to avoid you, but no clients have chosen you<br>yet. Changes to the authority voting on Guards in Tor 0.2.2.15 should<br>make this less drastic. It is also possible that your observed<br>bandwidth will be greater than without it. However, it will still take<br>up to 2 months for clients to choose you as their new Guard. <br><br>== Running temporary auxiliary nodes ==<br>One way to shortcut this process and avoid paying for bandwidth you<br>don't use is to spin up a bunch of temporary nodes to utilize the CPU<br>and quickly gather that easy first 2MB/sec of observed bandwidth.<br>But you need the spare IPs to do this.<br><br>== Monitoring ==<br>Personally, I prefer console-based options like nload, top, and<br>Damian's arm (<a href="http://www.atagar.com/arm/">http://www.atagar.com/arm/</a>) because I don't like the<br>idea of running extra services to publish my monitoring data to the<br>world.<br>Other people have web-based monitoring using things like munin and<br>mrtg. It would be nice to get a script/howto for that too.<br><br>== Current 1-Box Capacity Record == <br>Our setup has topped at 450Mbit, but averages between 300-400Mbit. We<br>are currently having uptime issues due to heat (melting, poorly<br>ventilated harddrives). It is likely that once we resolve this, we<br>will continually increase to our CPU ceiling.<br>I believe Moritz and Olaf also push this much capacity, possibly a bit<br>more, but with less nodes (4 as opposed to our 8). I hear Jake is also<br>ramping up some Guard nodes (or maybe I didn't? Did I just betray you<br>again Jake?)<br><br>== Did I leave anything out? ==<br>Well, did I?<br><br>-- <br>Mike Perry<br>Mad Computer Scientist<br><a href="http://fscked.org">fscked.org</a> evil labs</blockquote></div>