On 27/10/16 00:15, teor wrote:
>
>> On 27 Oct. 2016, at 00:32, D. S. Ljungmark <spider@xxxxxxxxx> wrote:
>>
>> On tis, 2016-10-25 at 22:52 +1100, teor wrote:
>>>>
>>>> On 25 Oct. 2016, at 22:26, D.S. Ljungmark <ljungmark@xxxxxxxx>
>>>> 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@xxxxxxxxx> 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
Attachment:
Screen Shot 2016-10-27 at 13.13.11.png
Description: PNG image
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
