[tor-relays] Rampup speed of Exit relay

[D.S. Ljungmark]

On 27/10/16 00:15, teor wrote:
> 
>> On 27 Oct. 2016, at 00:32, D. S. Ljungmark <spider at 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 at 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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2016-10-27 at 13.13.11.png
Type: image/png
Size: 98908 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20161027/2baca6cc/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 843 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20161027/2baca6cc/attachment-0001.sig>