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.
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.
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.
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.
Have you tried monitoring the reliability of connections through your Exit?
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.
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.
(Normally, the tor network has daily and weekly peaks.)
T