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

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