On tor, 2016-09-22 at 06:29 +1000, teor wrote:
On 22 Sep 2016, at 05:41, nusenu nusenu@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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays