[tor-relays] Rampup speed of Exit relay

teor teor2345 at gmail.com
Tue Oct 25 11:52:46 UTC 2016

> On 25 Oct. 2016, at 22:26, D.S. Ljungmark <ljungmark at modio.se> wrote:
> So, Now I've taken some steps to adjust the state of the relay, and
> try to balance this.
> To reiterate a point previously,  before I start adding more tor
> daemons or servers to this, I want to know how to scale and optimise
> what is already there.
> - Set up unbound in cache mode rather than use our local network unbound
> - Disabled on machine firewall (stateful)
> - Ensured AES acceleration worked
> - Boosted amount of open files allowed even more
> - Stopped doing regular reboots and only reboot on kernel change
> - Bound Tor to a single core

Tor is multi-process, so I wouldn't recommend binding it and its cpuworkers
to the same core. That could degrade performance.

> The exit is till this one:
> https://atlas.torproject.org/#details/5989521A85C94EE101E88B8DB2E68321673F9405
> CPU utilization of a single core on  the machine never goes > 22%
> Thus while it may be CPU bound, it's never maximising the CPU usage.
> CPU and network are still scaling together with each other.
> Load ( not cpu usage)  is fairly stable and load1 hasn't gone > 0.2
> It's holding between 5k and 16k sockets in use,

Having connections to 6000 relays is normal, and then there are more sockets
for Exit traffic.

> and ~3.5k sockets in
> TIME_WAIT state.   (Fairly high amount?)

Quite normal for an Exit.

> So far, I'm not sure _why_  it's capping itself on bandwidth, and
> that's the one thing that I want to figure out before I start scaling
> out horizontally.

If you hover over the Advertised Bandwidth in atlas, your relay's
advertised bandwidth is equal to its observed bandwidth.

Your relay's observed bandwidth is listed as 19.98 MByte / second in its

The bandwidth authorities seem to think your relay can handle twice
that, nominally 38100 KByte / second:
(This is a large page)

Last time we emailed, your relay's observed bandwidth was 19.83
MByte / second. This is suspiciously stable. Your observed bandwidth
should vary a lot more. But it seems capped at 20 MByte / second.

Perhaps your network link throttles traffic.

Or, the throttling is happening via CPU limiting.

Or, you have an option set that is limiting Tor's bandwidth usage directly.

Did you ever try using chutney to measure your local bandwidth?
That will tell you what your CPU is capable of.
(Leaving you to distinguish between config and network.)

Alternately, set up a relay with the same config at another provider.

Or, set up a relay with the same config on the same machine.

Or, set up a relay with a minimal config on the same machine.
(Try commenting-out lines in the config one at a time.
Start with RelayBandwidthRate and RelayBandwidthBurst.)

But other relays achieve much faster speeds, so it's likely something
unique to your situation.


> On Fri, Sep 23, 2016 at 11:28 AM, nusenu <nusenu at openmailbox.org> wrote:
>>>>>>>>>>> So, how do we get tor to move past 100-200Mbit? Is it just a
>>>>>>>>>>> waiting game?
>>>>> I'd say just run more instances if you still have resources left and
>>>>> want to contribute more bw.
>>>>> (obviously also your exit policy influences on how much your instance
>>>>> is
>>>>> used)
>>> Mainly, I want to scale up a single exit first, before I start adding
>>> more resources.
>> As Aeris, teor and me tried to explain, this is _not_ about "adding more
>> resources", but since you keep ignoring that it is a bit pointless to
>> state that over and over again.
>> teor gave some rather comprehensive answers and has said pretty much
>> anything relevant I guess.
>> In the end it should be about optimizing exit bandwidth cost (many
>> MBit/s for fewer $) no matter how many tor processes it requires to get
>> the most out of your hardware, number of available IPs and uplink
>> connectivity.
>>> It might well be that I've missed something, some tuning I should have
>>> remembered ( Like increasing the conntrack hash table size )
>> I'm not sure I would run a stateful firewall on an dedicated exit server
>> at all.
>> https://www.torservers.net/wiki/setup/server
>> _______________________________________________
>> tor-relays mailing list
>> tor-relays at lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> _______________________________________________
> tor-relays mailing list
> tor-relays at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
xmpp: teor at torproject dot org

More information about the tor-relays mailing list