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