[tor-relays] Rampup speed of Exit relay

[D. S. Ljungmark]

On tor, 2016-09-22 at 06:29 +1000, teor wrote:
> > 
> > On 22 Sep 2016, at 05:41, 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)
> 
> In my experience, a single Tor instance can use between 100Mbps and
> 500Mbps.
> It's highly dependent on the processor, OpenSSL version, and various
> network factors.

Acknowledged, the question is, how do you measure that.

> 
> There are also some random factors in the bandwidth measurement
> process, including the pair selection for bandwidth measurement. And
> clients also choose paths randomly. This means some relays get more
> bandwidth than others by chance.

That's interesting, how does the bandwidth scaling / metering work?
 Where/how does it decide how much bandwidth is available vs. what it
announces to the world?

Right now I can comfortable pull/push 700Mbit in either direction on
this node, so that's where I left the setting, if there is a penalty
for stating more bandwidth avialable than the network can measure, then
I have a problem.


> If you want to use the full capacity of your Exit, run multiple Tor
> instances.

> You can run 2 instances per IPv4 address, using different ports.
> Many people choose ORPort 443 and DirPort 80 as their secondary
> instance ports (this can help clients on networks that only allow 
> those ports), but you can choose any ports you want.

True, but there's a limit to how many nodes you can have in a /24, and
I really want scaling up on a single node before adding more resources.

Throw more resources at it cause we don't know why it sucks seems like
such a devops thing to do.

> 
> Have you considered configuring an IPv6 ORPort as well?
> (It's unlikely to affect traffic, but it will help clients that
> prefer IPv6.)

Not sure right now, I've had _horrid_ experiences with running Tor on
ipv6,  ranging from the absurd ( Needing ipv4 configured to set up
ipv6)  to the inane ( Config keys named "Port" not valid for both ipv6
and ipv4, horrid documentation)

I've got quite a few ipv6 -only- networks, and I'd gladly put up a
number of relays/Exits there ( using ephemeral addressing) however
that's impossible last I tried it.

My general consensus from last I looked in depth at this is that "Tor
doesn't support ipv6. It claims to, but it doesn't." 


> 
> > 
> > > 
> > > > 
> > > > 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).
> > 
> > Why do you reboot weekly? Memory leak workaround?
> 
> If you reboot weekly, you will take time each week to re-gain
> consensus weight and various other flags. For example, you will only
> have the HSDir flag for ~50% of the time. (The Guard flag is also
> affected, but it's somewhat irrelevant for Exits.)

Fancy that. "Don't upgrade your software because our software can't
handle it" is one of those things that really bug me. 

How much downtime can the node have before losing consensus
weight/flags? Is it just for restarting the tor process as well?

> I'd avoid the reboots if you can, there's a known bug affecting at
> least the Guard flag and restarts, where a long-lived stable relays
> are disproportionately impacted compared with new relays. I haven't
> seen any evidence that it affects other flags or consensus weight,
> but you could try not restarting and see if that helps.

Right, I can tune that for a week and see.

> 
> > 
> > ...
> > 
> > > 
> > > > 
> > > > 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?
> 
> Tor is not entirely multi-threaded yet. We still recommend running
> multiple instances on connections faster than 100 - 300Mbps.
> (And the Tor network currently only uses about 40% of capacity
> anyway, slightly more on Exits - this utilisation level helps keep
> latency low.)
> Later versions have better multithreading and crypto optimisations -
> thanks for keeping your relay up-to-date.
> 
> Tim
> 
> Tim Wilson-Brown (teor)
> 
> teor2345 at gmail dot com
> PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
> ricochet:ekmygaiu4rzgsk6n
> xmpp: teor at torproject dot org
> 
> 
> 
> 
> 
> 
> _______________________________________________
> tor-relays mailing list
> tor-relays at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-------------- 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/6cb1b52d/attachment.sig>