On 27/10/16 00:15, teor wrote:
On 27 Oct. 2016, at 00:32, D. S. Ljungmark spider@takeit.se wrote:
On tis, 2016-10-25 at 22:52 +1100, teor wrote:
On 25 Oct. 2016, at 22:26, D.S. Ljungmark ljungmark@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.
... 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.
Is 6k normal/high/low for an exit? I'm trying to find the cause of the low performance here.
6K - 7K is expected for any relay, as there are that many relays in the network.
And then an Exit has a socket for every outgoing Internet connection as well.
Okay, then I'm not being constrained by amount of open/allowed sockets/files or similar, that's good.
and ~3.5k sockets in TIME_WAIT state. (Fairly high amount?)
Quite normal for an Exit.
check.
These are likely from short-lived outgoing Exit connections.
True.
Or, the throttling is happening via CPU limiting.
Or, you have an option set that is limiting Tor's bandwidth usage directly.
Not as far as I'm aware, the only one I've set on purpouse are BandwidthBurst / BandwidthRate, both to 92MB.
Clearly you're not hitting these, so you could turn them off.
I could, but I don't want the relay to accidentally get fast and burst too high.
On 27 Oct. 2016, at 01:31, D. S. Ljungmark spider@takeit.se wrote:
On ons, 2016-10-26 at 15:32 +0200, D. S. Ljungmark wrote:
On tis, 2016-10-25 at 22:52 +1100, teor wrote:
... 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.)
No, will do that now to see.
Chutney in networks/basic-min mode gives me the following on a 500MB transfer
Single Stream Bandwidth: 42.09 MBytes/s Overall tor Bandwidth: 168.38 MBytes/s
Which seems to be in line with where I'd expect things to be CPU wise. Not optimum, but at least twice higher than what I see in reality.
You probably want the "Overall tor Bandwidth", which is the bandwidth of the stream multiplied by the number of tor instances that it goes through (4: client, guard, middle, exit).
It doesn't account for CPU usage by the python test harness, or the latency in connection establishment, or any other processes on the machine. So it will always read lower.
Understood, but the numbers at least seem to indicate something that's closer to what I was expecting, in bandwidth and CPU usage both.
Have you tried monitoring the reliability of connections through your Exit?
No, that should be next on my list, but it'll have to wait until non-office hours.
You can run a Tor client with "ExitNodes {fingerprint}", then use Tor Browser through it. This would help you find out the error messages clients are getting (if any).
You can also use this to do a bulk transfer test through your exit, to see if it has any spare bandwidth.
Okay, thanks, that'll be on the list.
It might also be worth checking what happens to the bandwidth usage on your Exit over the day and week. A tool like vnstat or munin could help here.
Attached is a graph of network usage from Oct 1 and for 14 days from that, the The peaks/dips are visible. Note that the measures are in Mbps, not MB/s
(Normally, the tor network has daily and weekly peaks.)
Yes, those are quite visible, and would be fairly normal.
Thanks for the help in this, I'm quite a bit miffed that I can't seem to get the bandwidth go up, while the machine appears to not be doing very much.
//D.S
