[Tor-BSD] OpenBSD Bandwidth Issues

[teor]

> On 7 May 2015, at 05:30 , George Rosamond <george at ceetonetechnology.com> wrote:
> 
> teor:
>> 
>>> On 29 Apr 2015, at 08:35 , Richard Johnson <rdump at river.com>
>>> wrote:
>>> 
>>> On 2015-04-07 15:43, Seth wrote:
>>>> On Sun, 14 Dec 2014 11:17:54 -0800, Libertas
>>>> <libertas at mykolab.com> wrote:
>>>> 
>>>>> It turns out my new exit node is an even better example than
>>>>> it was when I posted it two days ago. Compare its measured
>>>>> and consensus bandwidths with its actual bandwidth:
>>>>> 
>>>>> https://atlas.torproject.org/#details/CDAB3AE06A8C9C6BF817B3B0F1877A4B91465699
>>>>> 
>>>>> 
>>>>> 
> It's running on a pretty fast 100 Mbps uplink on a dedicated server with
>>>>> hardware that should be serious overkill.
>>>> 
>>>> ...so three months later and my OpenBSD Tor exit node
>>>> Advertised Bandwidth seems to have plateaued at approx 2.27
>>>> MB/s:
>>>> https://atlas.torproject.org/#details/E1E1059D8C41FC48B823C6F09348EA89C4D4C9D4
>>>> 
>>>> 
>>>> 
> Curious what other people are seeing for speeds on their *BSD nodes.
>>>> 
>>>> According to VULTR Server Monitors, resource usage over 1 month
>>>> period is nowhere near the limit.
>>> 
>>> 
>>> I currently use a non-AES-NI 2-CPU 12-total-cores system running
>>> OpenBSD 5.6-stable.  For 6 relays on the box (3 IP addresses) I
>>> see combined throughput averaging 3.7 to 4.5 MB/s over multiple
>>> days according to arm.
>>> 
>>> The fastest of the family:
>>> https://atlas.torproject.org/#details/41FFC361F0D51F3752E9481B075D5508D21C8D12
>>> 
>>> 
> This particular relay topped out on file descriptors (limit was 8192),
> so now the limit has been increased.
>>> 
>>> The second fastest of the family:
>>> https://atlas.torproject.org/#details/1CC39E06101B0DBFA103A18A2032C4A0FE0503C8
>>> 
>>> 
>>> 
>>> 
> Richard
>>> 
>>> (GEOa is running on Mac OS X, and is anemic for reasons I don't
>>> yet understand)
>> 
>> I found that my throughput increased dramatically on OS X when I: *
>> increased kern.maxfiles to 30K in sysctl * increased
>> kern.maxfilesperproc to 10K in sysctl * increased
>> kern.ipc.somaxconn to 4K in sysctl * set HardResourceLimits /
>> NumberOfFiles to 10K in launchd (I think launchd adjusts sysctl
>> here as well) * compiled an optimised version of the latest OpenSSL
>> with aes-ni support and linked tor against it
> 
> I've mentioned before, but I think it would be useful to standardize,
> at least on this list, *how* throughput changes are judged.  It feels
> like an exercise in comparing apples to aardvarks :)
> 
> I need to jump into the optimizing tweaks nevertheless.  I'm just not
> positive there are not other bottlenecks, such as the available bandwidth.
> 
> I don't have the link accessible ATM, but it's well worth looking at
> GNN's stuff on testing.  As I've said before, node bandwidth on the
> Tor network seem difficult to assess, just by the nature of how
> traffic flows on it. IOW, a (more or less) randomized network
> shouldn't be easy to replicate... unless there's something very wrong
> with the network!

I've seen similar requests on tor-relays -  people want to load-test their tor server, as the increases in relay bandwidth are incremental over time. (Which is why the relay lifecycle document exists.)

I'm working on some performance testing changes to the Chutney tool at the moment.
See: https://trac.torproject.org/projects/tor/ticket/14175

(Chutney configures, launches, and verifies local testing Tor networks using a templating system.)

My assumption is that most high-performance tor instances are CPU-bound.

A chutney network can test capacity of the local machine by transmitting large amounts of random data, and timing the transmission. If the speed is multiplied by the number of nodes in the path, that's the estimated tor bandwidth for the machine. Of course, this deliberately excludes the outside network link, as all the tor instances are on localhost. There is more parallelism with more nodes (4 rather than 1 or 2), and fewer network connections.

I don't know how useful it will be, but we've already discovered one or two hidden service load bugs using it.

teor

teor2345 at gmail dot com
pgp 0xABFED1AC
https://gist.github.com/teor2345/d033b8ce0a99adbc89c5

teor at blah dot im
OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.nycbug.org/pipermail/tor-bsd/attachments/20150507/ff43050e/attachment.bin>