[tor-relays] Rampup speed of Exit relay

Thu Sep 22 10:47:33 UTC 2016

On ons, 2016-09-21 at 19:41 +0000, nusenu 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. 

I've ran some high speed _relays_ in the past, and those are fairly
easy, however Exits seem to have a bit of a different behaviour, and
exits are what the network really needs more of.

> > 
> > > 
> > > How long has the relay been up?
> > 
> > 4 years or so. ( current uptime: 11 hours since reboot, it reboots
> > weekly )
> 
> This relay (5989521A) has been first seen on 2014-04-10 according to
> https://onionoo.torproject.org (still long enough).

Might be it, I recently ( see downtime ) had to migrate both to a new
provider, and new hardware, and I probably didn't pay attention enough
on which of the old relays I brought back.

I got the keys for the others set up, but before I relaunch them, I
want a stable performance for the current one.

> Why do you reboot weekly? Memory leak workaround?

Upgrade / kernel upgrades. I'd rather see systems interrupted regularly
and coming back, than having a headache when they don't come back. 

> 
> Aeris wrote:
> > 
> > From Atlas graph, your node is currently growing up, so wait few
> > weeks more to 
> > have the real bandwidth consumption
> 
> Wondering what caused that improvement? (significantly doing better
> since the last longer downtime on 2016-09-04?)

Me increasing the bandwidth, really. I had a base profile for what the
customer network was doing, and decided that we could offer up 600Mbit
of traffic for Tor.

> 
> > 
> > > 
> > > Where is it located?
> > 
> > Sweden, Tele2 AS
> 
> http://bgp.he.net/AS1257
> 
> You are apparently the only exit relay in your AS, thanks for running
> it
> there!
> 
> 
> > 
> > > 
> > > Have you tried running 2 Tor instances per IPv4 address?
> > 
> > Previously, currently only one to see what throughput we could get
> > a
> > single Tor exit at.
> 
> OK, so this email is about speed optimizations of a single tor
> instance
> and not about increasing usage a tor exit server?

This is about the single instance, and about _exit_ tunings past the
basic 100Mbit traffic ( which we regularly hit )

Before I re-launch the other relays, I want to be sure that all the
settings are tuned on a single one, so they don't end up
competing/starving each other for resources.

And while the day-to-day graph of bandwidth/Resources used by the exit
are interesting, I'm not seeing any _obvious_ bottlenecks here.

Here's a graph,

As you can see, incoming and outgoing bandwidth match eachother very
neatly ( could almost be a single graph,)  CPU utilization in user time
matches reasonably with this, and the system time is a steady buzz.

What's to notice is the scale on the left side (% cpu usage) , where
system load stays below 5%, and user load stays under 15%.

15% user load on a 2-core system to shovel ~ 2*15 Mbyte/s ( Not Mbit,
Mbyte). 

So, that's why I'm posting here, to figure out _where_ the bottleneck
is. Many people have mentioned CPU as an obvious reason, however, I
don't see CPU usage actually spiking much on this system.

So, right now I don't really know _why_ I'm not seeing more bandwidth
utilization. If CPU, on single core, would be the limiting factor, I'd
expect bandwidth to go up to at least 40MByte/s  ( scaling linear on
CPU usage, at around 70% then ).

So, Those are the raw numbers, and why I'm looking to the list for
scaling tips for exits.

It might well be that I've missed something, some tuning I should have
remembered ( Like increasing the conntrack hash table size ) but I
think I've covered the basics.

//D.S.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2016-09-22 at 12.28.54.png
Type: image/png
Size: 85529 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20160922/31be4302/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2016-09-22 at 12.35.49.png
Type: image/png
Size: 41107 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20160922/31be4302/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20160922/31be4302/attachment-0001.sig>