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

Tue Sep 30 18:46:06 UTC 2014

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/1F6598EA09A82E7A5D3131E71A97C806E6FDA4A1
>>
>>   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/50F37822AFA257B24B3343D9BBFB0442E900FB4C
>>
>>   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 --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3729 bytes
Desc: S/MIME-cryptografische ondertekening
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20140930/6d9c2f71/attachment.bin>