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 <[email protected]> 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 [email protected] >>> 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/[email protected] >> -----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 >> [email protected] >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> >> >
_______________________________________________ tor-relays mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
