On ons, 2016-09-21 at 17:29 +0200, Aeris wrote:
17 MBytes/s in each direction.
From Atlas graph, your node is currently growing up, so wait few weeks more to have the real bandwidth consumption, but don’t expect huge change.
It looks as if it stabilized a while ago, and I see more fluctuations in between hours of the day, than I see between days.
17M*B*ps is 140M*b*ps and you already have a good relay :) This is around the speed expected for standard CPU (150 to 300Mbps per Tor instance, best CPU available can "only" drain around 500Mbps).
For a relay, yes. However, on an Exit node, the traffic patterns are quite different than a pure relay, that's why I'm asking here for that.
Exit traffic uses a metric ton more, short-lived connections to different parts of the world, and there's a lot of things there that I could probably tune better. ( Normal relays seldom have a trouble filling the conntrac tables, while exits do. )
And your CPU have all chance to be the bottleneck at this speed. Tor is not multi-core at the moment and so you can’t be able to fully use your CPU capacity. For example, if you have a 4-core CPU, don’t expect to have more than 0.25-0.3 load with only Tor (1 core fully used).
Load is only about IO, processes waiting for something. That's why I quoted CPU usage, and the cpu usage per cpu isn't quite getting there for me. :-(
You have to start another Tor instance to use a little more your CPU (1 other core) and so to drain additionnal 150-300Mbps.
Scaling up on more hardware is always an option, but I really want to push the limit of the exit node, as the others won't be exits (Local network design, really) , and exit traffic is always more interesting.
//D.S.
D. S. Ljungmark:
You have to start another Tor instance to use a little more your CPU
(1 other core) and so to drain additionnal 150-300Mbps.
Scaling up on more hardware is always an option, but I really want to push the limit of the exit node, as the others won't be exits (Local network design, really) , and exit traffic is always more interesting.
Aeris (and others) were not referring to run more instances on other hardware but to run more instances on the same hardware/machine. (multiple tor instances on one machine has become easy to setup nowadays)
Scaling up on more hardware is always an option, but I really want to push the limit of the exit node, as the others won't be exits (Local network design, really) , and exit traffic is always more interesting.
When I say another instance, it’s on the same hardware. Because Tor is not fully multi-thread/multi-core, you have to run another Tor daemon on the same host to use 1 more CPU core and so drain another 150-300Mbps. Currenly, you can start up to 2 Tor daemons per IP, there is a limitation to avoid Sybil attack.
Regards,
On tor, 2016-09-22 at 12:08 +0200, Aeris wrote:
Scaling up on more hardware is always an option, but I really want to push the limit of the exit node, as the others won't be exits (Local network design, really) , and exit traffic is always more interesting.
When I say another instance, it’s on the same hardware. Because Tor is not fully multi-thread/multi-core, you have to run another Tor daemon on the same host to use 1 more CPU core and so drain another 150-300Mbps. Currenly, you can start up to 2 Tor daemons per IP, there is a limitation to avoid Sybil attack.
Regards,
Yes, I'm aware of this, but if I can't get Tor to scale up to even 300Mbps on a single instance, adding another instance on the same hardware isn't going to magically make it reach saturation. It might improve things, seen from the network scaling it from 120Mbps to 250Mbps, but it's certainly not going to push it to 700Mbps.
First, I want to find _why_ I'm not peaking either CPU usage, or bandwidth usage. That the network is a stochastic and semi-random limiter, I'm quite aware of, and adding more resources to pool that up is doable.
( Though I can't add more ipv4 addresses right now, ipv6 is plentiful, sadly, tor doesn't do very well on ipv6. )
//D.S.
On 22 Sep 2016, at 04:40, D. S. Ljungmark spider@takeit.se wrote:
On tor, 2016-09-22 at 12:08 +0200, Aeris wrote:
Scaling up on more hardware is always an option, but I really want to push the limit of the exit node, as the others won't be exits (Local network design, really) , and exit traffic is always more interesting.
When I say another instance, it’s on the same hardware. Because Tor is not fully multi-thread/multi-core, you have to run another Tor daemon on the same host to use 1 more CPU core and so drain another 150-300Mbps. Currenly, you can start up to 2 Tor daemons per IP, there is a limitation to avoid Sybil attack.
Regards,
Yes, I'm aware of this, but if I can't get Tor to scale up to even 300Mbps on a single instance, adding another instance on the same hardware isn't going to magically make it reach saturation. It might improve things, seen from the network scaling it from 120Mbps to 250Mbps, but it's certainly not going to push it to 700Mbps.
It could - I started the exits radia0 and radia1 about a month ago, at almost the same time, with the same config (different IPs and ports), on the same gigabit link, with plenty of processor. radia0 (350 Mbps) is pushing almost double that of radia1 (200 Mbps):
https://atlas.torproject.org/#search/radia
First, I want to find _why_ I'm not peaking either CPU usage, or bandwidth usage. That the network is a stochastic and semi-random limiter, I'm quite aware of, and adding more resources to pool that up is doable.
Please see my other email for details of how to measure your capacity locally.
That said, these random factors are genuinely random, and have quite a wide range of results. We're working on measuring relay capacity better.
( Though I can't add more ipv4 addresses right now, ipv6 is plentiful, sadly, tor doesn't do very well on ipv6. )
You can run two tor instances per IPv4 address.
Alternately, if your relay fingerprint has had a particularly bad set of random selections, you could try deleting the RSA and Ed25519 identity keys, and starting again. This will reset your reputation on the network.
But that's effectively like starting another Tor instance, which you can already do without destroying your existing one.
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@lists.torproject.org
-
Aeris -
D. S. Ljungmark -
nusenu -
teor