[tor-relays] Bandwidth not being used by Tor on Gigabit dedicated server

Wed Oct 1 14:30:37 UTC 2014

Thank you for the reply.  I have already (months ago) configured the max
file limit to be 795552.

Perhaps I'll try running more instances...

On Tue, Sep 30, 2014 at 11:46 AM, Tom van der Woerdt <info at tvdw.eu> wrote:

> I've often found my servers accidentally bottlenecked by the default open
> file limit on some Linuxes. For example, on CentOS 6 this is 4096, which
> for an exit node tends to mean ~50Mbit/s per process.
>
> A single process will not saturate 1Gbit/s. Judging by the hardware
> (AES-NI support) you will need 3 or 4 instances running simultaneously to
> max the link.
>
> Tom
>
>
>
> s7r schreef op 30/09/14 20:31:
>
>  -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> It has nothing to do with the location (US). There are fewer US exit
>> relays than other countries in Europe.
>>
>> Check the CPU usage too, usually CPU is the bottleneck on high port
>> speed servers. Tor does not know yet how to do multithreading.
>>
>> Do you have AES-NI hardware acceleration at your CPU? This is very
>> helpful too.
>>
>> Install htop (yum -y install htop) and it will tell you exactly how
>> much each core is used. Let us know. I see that you confirm CPU load
>> is not the fault, but probably you are checking it via a tool which is
>> reporting the usage for ALL CPU (all cores) - try with htop and see if
>> there is just one core @ 98% usage and others at less than 10%.
>>
>> If the CPU is not the bottleneck, there is something at your provider
>> (probably throttling Tor traffic to balance the other non-tor users in
>> the same datacenter). If you built the network infrastructure there
>> and know for sure such thing is not implemented there, don't really
>> know what to say.  CPU / RAM and Network interface is all you can test
>> to see if it is the bottleneck for Tor. If all these are off the list,
>> there is something upstream you.
>>
>> I repeat, the location is not the fault here, and I encourage adding
>> more exits in the US.
>>
>> On 9/30/2014 8:52 PM, Jon Daniels wrote:
>>
>>> Hi,
>>>
>>> My Tor node is not utilizing the bandwidth available to it. I have
>>> tried setting RelayBandwidthRate to various values with no change
>>> whatsoever in bandwidth usage.
>>>
>>> Running for 5 months with 99.77% uptime:
>>> https://globe.torproject.org/#/relay/1F6598EA09A82E7A5D3131E71A97C8
>>> 06E6FDA4A1
>>>
>>>   My node has used a maximum of about 4MB/s or about 40Mbps. I've
>>> been expecting it to use 10MB/sec to 30 MB/sec. It dropped from
>>> 4MB/sec to around 1MB/sec now.
>>>
>>> OS: CentOS 6.x 64bit latest CPU: Xeon E3 1230 MB: Supermicro X9SCL
>>> RAM: 8GB Network connection: 1000Mbps
>>>
>>> Bandwidth tests show the server can easily send or receive hundreds
>>> of Mbps. I have tweaked server settings trying to get the speed up
>>> to no avail.
>>>
>>>
>>> Tor v0.2.4.24 (git-549ec02c188842f6) running on Linux with
>>> Libevent 1.4.13-stable and OpenSSL 1.0.1e-fips.
>>>
>>> Relevant config:
>>>
>>> DirPort 9030 # what port to advertise for directory connections
>>>
>>> RelayBandwidthRate 30 MB # Throttle traffic to 100KB/s (800Kbps)
>>> RelayBandwidthBurst 30 MB # But allow bursts up to 200KB/s
>>> (1600Kbps)
>>>
>>> DisableDebuggerAttachment 0
>>>
>>> ORPort 443
>>>
>>> ExitPolicy accept *:20-23 # FTP, SSH, telnet ExitPolicy accept *:43
>>> # WHOIS ExitPolicy accept *:53 # DNS ExitPolicy accept *:79-81 #
>>> finger, HTTP ExitPolicy accept *:88 # kerberos ExitPolicy accept
>>> *:110 # POP3 ExitPolicy accept *:143 # IMAP ExitPolicy accept *:194
>>> # IRC ExitPolicy accept *:220 # IMAP3 ExitPolicy accept *:389 #
>>> LDAP ExitPolicy accept *:443 # HTTPS ExitPolicy accept *:464 #
>>> kpasswd ExitPolicy accept *:531 # IRC/AIM ExitPolicy accept
>>> *:543-544 # Kerberos ExitPolicy accept *:554 # RTSP ExitPolicy
>>> accept *:563 # NNTP over SSL ExitPolicy accept *:636 # LDAP over
>>> SSL ExitPolicy accept *:706 # SILC ExitPolicy accept *:749 #
>>> kerberos ExitPolicy accept *:873 # rsync ExitPolicy accept
>>> *:902-904 # VMware ExitPolicy accept *:981 # Remote HTTPS
>>> management for firewall ExitPolicy accept *:989-995 # FTP over SSL,
>>> Netnews Administration System, telnets, IMAP over SSL, ircs, POP3
>>> over SSL ExitPolicy accept *:1194 # OpenVPN ExitPolicy accept
>>> *:1220 # QT Server Admin ExitPolicy accept *:1293 # PKT-KRB-IPSec
>>> ExitPolicy accept *:1500 # VLSI License Manager ExitPolicy accept
>>> *:1533 # Sametime ExitPolicy accept *:1677 # GroupWise ExitPolicy
>>> accept *:1723 # PPTP ExitPolicy accept *:1755 # RTSP ExitPolicy
>>> accept *:1863 # MSNP ExitPolicy accept *:2082 # Infowave Mobility
>>> Server ExitPolicy accept *:2083 # Secure Radius Service (radsec)
>>> ExitPolicy accept *:2086-2087 # GNUnet, ELI ExitPolicy accept
>>> *:2095-2096 # NBX ExitPolicy accept *:2102-2104 # Zephyr ExitPolicy
>>> accept *:3128 # SQUID ExitPolicy accept *:3389 # MS WBT ExitPolicy
>>> accept *:3690 # SVN ExitPolicy accept *:4321 # RWHOIS ExitPolicy
>>> accept *:4643 # Virtuozzo ExitPolicy accept *:5050 # MMCC
>>> ExitPolicy accept *:5190 # ICQ ExitPolicy accept *:5222-5223 #
>>> XMPP, XMPP over SSL ExitPolicy accept *:5228 # Android Market
>>> ExitPolicy accept *:5900 # VNC ExitPolicy accept *:6660-6669 # IRC
>>> ExitPolicy accept *:6679 # IRC SSL ExitPolicy accept *:6697 # IRC
>>> SSL ExitPolicy accept *:8000 # iRDMI ExitPolicy accept *:8008 #
>>> HTTP alternate ExitPolicy accept *:8074 # Gadu-Gadu ExitPolicy
>>> accept *:8080 # HTTP Proxies ExitPolicy accept *:8087-8088 #
>>> Simplify Media SPP Protocol, Radan HTTP ExitPolicy accept
>>> *:8332-8333 # BitCoin ExitPolicy accept *:8443 # PCsync HTTPS
>>> ExitPolicy accept *:8888 # HTTP Proxies, NewsEDGE ExitPolicy accept
>>> *:9418 # git ExitPolicy accept *:9999 # distinct ExitPolicy accept
>>> *:10000 # Network Data Management Protocol ExitPolicy accept
>>> *:11371 # OpenPGP hkp (http keyserver protocol) ExitPolicy accept
>>> *:12350 # Skype ExitPolicy accept *:19294 # Google Voice TCP
>>> ExitPolicy accept *:19638 # Ensim control panel ExitPolicy accept
>>> *:23456 # Skype ExitPolicy accept *:33033 # Skype ExitPolicy accept
>>> *:64738 # Mumble ExitPolicy reject *:*
>>>
>>> In addition, there's another Tor node running at the same ISP (but
>>> by a different person), on completely different hardware and a
>>> different router, that exhibits the same issue:
>>>
>>> https://globe.torproject.org/#/relay/50F37822AFA257B24B3343D9BBFB04
>>> 42E900FB4C
>>>
>>>   For background, I built and manage the network both servers are
>>> hosted on and have been doing so for 20 years. I also built both
>>> servers. The network is at less than 15% capacity, 99% of the
>>> time.
>>>
>>> CPU load is always at 0.00. Based in the USA, west coast.
>>>
>>> Ideas?  Is there simply less demand for tor traffic in the US?
>>>
>>> Cheers, Jon
>>>
>>>
>>> _______________________________________________ tor-relays mailing
>>> list tor-relays at lists.torproject.org
>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>>
>>>
>> - --
>> s7r
>> PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11
>> PGP Pubkey: http://www.sky-ip.org/s7r@sky-ip.org.asc
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2.0.22 (MingW32)
>>
>> iQEcBAEBAgAGBQJUKvcYAAoJEIN/pSyBJlsRft0IANm500IF63yielvNcKqVdXQl
>> j1fe532wa+/Ui3x3CCAj05lAEGFZlIhRZG70HQql+A5tTHFOUQbMhkJloXs5OOMC
>> XGwMy8f26A6ZbHd4YAtg4p1c6d7YRfd3QJD1k8yERoEG1jEOjtJANCsCuXCult7u
>> NyXL1t9UD12KMbTckIchBdqr5k2wA9e+RI8O60jSIq3h06kJ7yDA5yO6JNAvVRPE
>> 2FMCxrJ5Bu9wWhp7F4YvogMHXTlcVbVNubOe/D5oBumz7KjsjUPbshaWz3kbXJUY
>> 939O2dB5h3OrZkz9MqnlnpPkqcA4yTFZT8J3cXqtnOvKZx9SXhpj6WAXmua/Mo8=
>> =IYwa
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> tor-relays mailing list
>> tor-relays at lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20141001/57e9e83d/attachment.html>