Hello all,
we are administrating 2 Tor Exits for privacyfoundation.ch [1].
In the last month we realized that the traffic which is going through our servers / throughput is by far less than the machines and the providers network can handle. We were internally and recently with Moritz from torservers.net looking at this problem but could not find a way to improve throughput. Even on the same machine the throughput between servers varies a lot with out any visible reason.
I hope you can help.
Our setup is two servers with a maximum of 4 tor processes (exit) each. Looking at CPU, Disk, RAM and so on the machines are not busy at all.
Konsole output top - 09:57:49 up 16 days, 11:57, 1 user, load average: 1.14, 0.91, 0.81 Tasks:244 total, 3 running,241 sleeping, 0 stopped, 0 zombie %Cpu0 :12.5 us, 3.4 sy, 0.0 ni,79.7 id, 0.0 wa, 0.0 hi, 4.4 si, 0.0 st %Cpu1 :15.9 us, 5.4 sy, 0.0 ni,74.3 id, 0.3 wa, 0.0 hi, 4.1 si, 0.0 st %Cpu2 :14.3 us, 2.7 sy, 0.0 ni,77.0 id, 0.0 wa, 0.0 hi, 6.0 si, 0.0 st %Cpu3 : 9.5 us, 3.4 sy, 0.0 ni,80.3 id, 0.0 wa, 0.0 hi, 6.8 si, 0.0 st KiB Mem: 3877624 total, 2739880 used, 1137744 free, 1288 buffers KiB Swap: 4026364 total, 364264 used, 3662100 free. 10752 cached Mem
Looking at the network connection it is without any problem possible to start big downloads without reducing TOR throughput. The servers are connected with 1 Gbit/s each.
The big question now is: Why do the machines do not have more throughput ? Is the reason for this the way the distribution through the Tor network works. Moritz hinted it might have to do with the way the tor "bandwidth scanners" measure the ability of a server to handle traffic.
Can you explain me / point me to documentation where this process is described and how this can be optimized. What are the criteria for tor exit node server traffic distribution ? How do the clients choose the exit ?
I would be very happy if you could provide some answers / documentation which will set me on the right track.
Thanks very much for you help.
Dirk
Hi, are you useing cat7 cable? Did you configure a DNS fall-back 8.8.8.8 to be on the safe side?
Ok, with (1000 mBit x2=) 2000mBit you are handling 114,3 MB/s
16,8 +2,7 +9,6 +19,7 +26,2 +7,0 +22,6 +9,7 = 114,3 MB/s
Thats already good. Did you declare a cut-off? You can experimentally try my follwing advice: For each Tor process set in torrc: BandwidthRate 13000000 bytes BandwidthBurst 13375000 bytes
So you end up with Server1: 4x 13000000 bytes = 4x13MB/s Server2: 4x 13000000 bytes = 4x13MB/s (in each direction) 104+104=208 MB/s You hopefully will end up with ~540TB per month.
(oh, don't miss your upgrade to 0.2.7.6) (-:
Am Sonntag, 13. Dezember 2015 21:18 schrieb Dirk Eschbach tor-relay.dirk@o.banes.ch:
Hello all,
we are administrating 2 Tor Exits for privacyfoundation.ch [1].
In the last month we realized that the traffic which is going through our servers / throughput is by far less than the machines and the providers network can handle. We were internally and recently with Moritz from torservers.net looking at this problem but could not find a way to improve throughput. Even on the same machine the throughput between servers varies a lot with out any visible reason.
I hope you can help.
Our setup is two servers with a maximum of 4 tor processes (exit) each. Looking at CPU, Disk, RAM and so on the machines are not busy at all.
Konsole output top - 09:57:49 up 16 days, 11:57, 1 user, load average: 1.14, 0.91, 0.81 Tasks:244 total, 3 running,241 sleeping, 0 stopped, 0 zombie %Cpu0 :12.5 us, 3.4 sy, 0.0 ni,79.7 id, 0.0 wa, 0.0 hi, 4.4 si, 0.0 st %Cpu1 :15.9 us, 5.4 sy, 0.0 ni,74.3 id, 0.3 wa, 0.0 hi, 4.1 si, 0.0 st %Cpu2 :14.3 us, 2.7 sy, 0.0 ni,77.0 id, 0.0 wa, 0.0 hi, 6.0 si, 0.0 st %Cpu3 : 9.5 us, 3.4 sy, 0.0 ni,80.3 id, 0.0 wa, 0.0 hi, 6.8 si, 0.0 st KiB Mem: 3877624 total, 2739880 used, 1137744 free, 1288 buffers KiB Swap: 4026364 total, 364264 used, 3662100 free. 10752 cached Mem
Looking at the network connection it is without any problem possible to start big downloads without reducing TOR throughput. The servers are connected with 1 Gbit/s each.
The big question now is: Why do the machines do not have more throughput ? Is the reason for this the way the distribution through the Tor network works. Moritz hinted it might have to do with the way the tor "bandwidth scanners" measure the ability of a server to handle traffic.
Can you explain me / point me to documentation where this process is described and how this can be optimized. What are the criteria for tor exit node server traffic distribution ? How do the clients choose the exit ?
I would be very happy if you could provide some answers / documentation which will set me on the right track.
Thanks very much for you help.
Dirk
[1] https://globe.torproject.org/#/search/query=digiges
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Even on the same machine the throughput between servers varies a lot with out any visible reason
I had a short look at
B060482C784788B8A564DECD904E14CB305C8B38 (your 'slowest') vs DC41244B158D1420C98C66F7B5E569C09DCE98FE ('fastest') running on the same IP.
The relay graphs look like B060 was down for a long period of time between October until a week ago. DC41 was not.
sample lookup https://exonerator.torproject.org/?ip=176.10.104.241%C3%97tamp=2015-10-10
Moritz hinted it might have to do with the way the tor "bandwidth scanners" measure the ability of a server to handle traffic.
Can you explain me / point me to documentation where this process is described
bw scanner spec can be found here:
https://gitweb.torproject.org/torflow.git/tree/NetworkScanners/BwAuthority/R...
on how their vote is processes for the consensus:
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n1890 https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2149
You can download votes from collector to find out how bwauths measured your relays:
https://collector.torproject.org/archive/relay-descriptors/votes/
On 14 Dec 2015, at 07:18, Dirk Eschbach tor-relay.dirk@o.banes.ch wrote:
...
The big question now is: Why do the machines do not have more throughput ? Is the reason for this the way the distribution through the Tor network works. Moritz hinted it might have to do with the way the tor "bandwidth scanners" measure the ability of a server to handle traffic.
No, this is not the issue, your relay's own self-measured throughput is the issue. See below.
Can you explain me / point me to documentation where this process is described and how this can be optimized. What are the criteria for tor exit node server traffic distribution ?
By consensus weight, which is determined by the bandwidth authorities. https://blog.torproject.org/blog/lifecycle-of-a-new-relay https://blog.torproject.org/blog/lifecycle-of-a-new-relay https://stem.torproject.org/tutorials/examples/votes_by_bandwidth_authoritie... https://stem.torproject.org/tutorials/examples/votes_by_bandwidth_authorities.html
How do the clients choose the exit ?
From those servers they believe exit to the address and port they want, randomly, weighted by the server's consensus weight.
The details of bandwidth weight selection are in section 3.4.2 of the Directory Specification: https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt
"The bandwidth in a "w" line should be taken as the best estimate of the router's actual capacity that the authority has. For now, this should be the lesser of the observed bandwidth and bandwidth rate limit from the server descriptor. It is given in kilobytes per second, and capped at some arbitrary value (currently 10 MB/s).
The Measured= keyword on a "w" line vote is currently computed by multiplying the previous published consensus bandwidth by the ratio of the measured average node stream capacity to the network average. If 3 or more authorities provide a Measured= keyword for a router, the authorities produce a consensus containing a "w" Bandwidth= keyword equal to the median of the Measured= votes."
When I look at the bandwidth authority votes for DigiGesTor1e1, they say: w Bandwidth=9586 Measured=24200 w Bandwidth=9586 Measured=15900 w Bandwidth=9586 Measured=43500 w Bandwidth=9586 Measured=19700 w Bandwidth=9586 Measured=19200
Those votes are in these large files: http://171.25.193.9:443/tor/status-vote/current/authority http://171.25.193.9:443/tor/status-vote/current/authority http://199.254.238.53/tor/status-vote/current/authority http://199.254.238.53/tor/status-vote/current/authority http://131.188.40.189/tor/status-vote/current/authority http://131.188.40.189/tor/status-vote/current/authority http://128.31.0.34:9131/tor/status-vote/current/authority http://128.31.0.34:9131/tor/status-vote/current/authority http://154.35.175.225/tor/status-vote/current/authority http://154.35.175.225/tor/status-vote/current/authority
So the bandwidth authorities have having no trouble measuring your relay, they think it should be 2x - 4x as fast. Your relay itself has't observed itself sustaining that performance over a 10-second interval, so it won't allow the directory authorities to assign it more bandwidth.
Section 2.1.1 of the Directory Specification:
""bandwidth" bandwidth-avg bandwidth-burst bandwidth-observed NL
[Exactly once]
Estimated bandwidth for this router, in bytes per second. The "average" bandwidth is the volume per second that the OR is willing to sustain over long periods; the "burst" bandwidth is the volume that the OR is willing to sustain in very short intervals. The "observed" value is an estimate of the capacity this relay can handle. The relay remembers the max bandwidth sustained output over any ten second period in the past day, and another sustained input. The "observed" value is the lesser of these two numbers."
Please improve the throughput your relay can sustain over a 10-second period. Try some performance tuning steps, testing your relay with Tor client after each one. (See below.)
Have you set a limit on MaxAdvertisedBandwidth in the torrc files?
Konsole output top - 09:57:49 up 16 days, 11:57, 1 user, load average: 1.14, 0.91, 0.81 Tasks:244 total, 3 running,241 sleeping, 0 stopped, 0 zombie %Cpu0 :12.5 us, 3.4 sy, 0.0 ni,79.7 id, 0.0 wa, 0.0 hi, 4.4 si, 0.0 st %Cpu1 :15.9 us, 5.4 sy, 0.0 ni,74.3 id, 0.3 wa, 0.0 hi, 4.1 si, 0.0 st %Cpu2 :14.3 us, 2.7 sy, 0.0 ni,77.0 id, 0.0 wa, 0.0 hi, 6.0 si, 0.0 st %Cpu3 : 9.5 us, 3.4 sy, 0.0 ni,80.3 id, 0.0 wa, 0.0 hi, 6.8 si, 0.0 st KiB Mem: 3877624 total, 2739880 used, 1137744 free, 1288 buffers KiB Swap: 4026364 total, 364264 used, 3662100 free. 10752 cached Mem
Looking at the network connection it is without any problem possible to start big downloads without reducing TOR throughput.
Have you tried doing a large download through your exit via a Tor client and seeing how fast that is? ExitNodes <fingerprint od your exit> StrictNodes 1
The servers are connected with 1 Gbit/s each.
It looks like your Tor processes are neither CPU nor network-bound.
Does your network connection drop packets or have large latency?
How many file descriptors are the tor processes allowed to open? How many connections does each tor process have open at once? (There should be thousands per process on a busy relay.)
https://gitweb.torproject.org/tor.git/tree/doc/TUNING https://gitweb.torproject.org/tor.git/tree/doc/TUNING
Are there any performance-related messages in the Tor logs?
Is your hardware / kernel / firewall / etc. capable of handling many connections?
Does your provider rate-limit any kinds of traffic? Does your provider limit the number of open connections?
Is your DNS resolver keeping up with the requests? Do you have a local caching DNS resolver on each machine?
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
Hello everyone,
thanks for replying. I did some further checks as you suggested. In the meantime I removed MaxAdvertisedBandwidth since the default should do.
I pinned the ExitNode in my Client and downloaded an Ubuntu image. Download was between 800 kbyte/s and 1 Mbyte/s. Not great - but not bad. When I start a wget on the machine directly it will be downloaded with 30 Mbyte/s. So I do not assume we are limited by the provider.
I checked and changed the ulimit.
Unfortunately no better results so far. I did not yet set up an local resolver - does it make such a difference ? We use the provides DNS and 8.8.8.8.
Finally a set logfiles to debug and started greping for err:
Dec 15 22:55:50.000 [info] {EDGE} connection_edge_process_relay_cell(): 617: end cell (misc error) for stream 7289. Removing stream. Dec 15 22:55:50.000 [debug] {NET} tor_tls_read(): read returned r=-1, err=-2 Dec 15 22:55:50.000 [debug] {NET} tor_tls_read(): read returned r=-1, err=-2 Dec 15 22:55:50.000 [debug] {NET} tor_tls_read(): read returned r=-1, err=-2 Dec 15 22:55:50.000 [debug] {NET} tor_tls_read(): read returned r=-1, err=-2 Dec 15 22:55:50.000 [info] {EDGE} connection_edge_process_relay_cell(): 356: end cell (misc error) for stream 42558. Removing stream. Dec 15 22:55:50.000 [debug] {NET} tor_tls_read(): read returned r=-1, err=-2 Dec 15 22:55:50.000 [debug] {NET} tor_tls_read(): read returned r=-1, err=-2 Dec 15 22:55:50.000 [debug] {NET} tor_tls_read(): read returned r=-1, err=-2 Dec 15 22:55:50.000 [debug] {NET} tor_tls_read(): read returned r=-1, err=-2 Dec 15 22:55:50.000 [info] {EDGE} connection_edge_process_relay_cell(): 491: end cell (misc error) for stream 36878. Removing stream. Dec 15 22:55:50.000 [debug] {NET} tor_tls_read(): read returned r=-1, err=-2 Dec 15 22:55:50.000 [debug] {NET} tor_tls_read(): read returned r=-1, err=-2 Dec 15 22:55:50.000 [debug] {NET} tor_tls_read(): read returned r=-1, err=-2 Dec 15 22:55:50.000 [debug] {NET} tor_tls_read(): read returned r=-1, err=-2 Dec 15 22:55:50.000 [debug] {NET} tor_tls_read(): read returned r=-1, err=-2 Dec 15 22:55:50.000 [debug] {NET} tor_tls_read(): read returned r=-1, err=-2 Dec 15 22:55:51.000 [debug] {NET} tor_tls_read(): read returned r=-1, err=-2 Dec 15 22:55:51.000 [info] {EDGE} connection_edge_process_relay_cell(): 177: end cell (misc error) for stream 60286. Removing stream. Dec 15 22:55:51.000 [debug] {NET} tor_tls_read(): read returned r=-1, err=-2 Dec 15 22:55:51.000 [debug] {NET} tor_tls_read(): read returned r=-1, err=-2 Dec 15 22:55:51.000 [debug] {NET} tor_tls_read(): read returned r=-1, err=-2 Dec 15 22:55:51.000 [debug] {NET} tor_tls_read(): read returned r=-1, err=-2 Dec 15 22:55:51.000 [debug] {NET} tor_tls_read(): read returned r=-1, err=-2 Dec 15 22:55:51.000 [info] {EDGE} connection_edge_process_relay_cell(): 374: end cell (misc error) for stream 60283. Removing stream. Dec 15 22:55:51.000 [debug] {NET} tor_tls_read(): read returned r=-1, err=-2 Dec 15 22:55:51.000 [debug] {NET} tor_tls_read(): read returned r=-1, err=-2 Dec 15 22:55:51.000 [info] {EDGE} connection_edge_process_relay_cell(): end cell (misc error) dropped, unknown stream. Dec 15 22:55:51.000 [info] {EDGE} connection_edge_process_relay_cell(): 174: end cell (misc error) for stream 60289. Removing stream. Dec 15 22:55:51.000 [info] {EDGE} connection_edge_process_relay_cell(): 384: end cell (misc error) for stream 60288. Removing stream. Dec 15 22:55:51.000 [debug] {NET} tor_tls_read(): read returned r=-1, err=-2 Dec 15 22:55:51.000 [debug] {NET} tor_tls_read(): read returned r=-1, err=-2 Dec 15 22:55:51.000 [debug] {NET} tor_tls_read(): read returned r=-1, err=-2 Dec 15 22:55:51.000 [debug] {NET} tor_tls_read(): read returned r=-1, err=-2 Dec 15 22:55:51.000 [info] {EDGE} connection_edge_process_relay_cell(): 590: end cell (misc error) for stream 60285. Removing stream. Dec 15 22:55:51.000 [info] {EDGE} connection_edge_process_relay_cell(): 587: end cell (misc error) for stream 60284. Removing stream. Dec 15 22:55:51.000 [debug] {NET} tor_tls_read(): read returned r=-1, err=-2 Dec 15 22:55:51.000 [info] {EDGE} connection_edge_process_relay_cell(): 338: end cell (misc error) for stream 32126. Removing stream. Dec 15 22:55:51.000 [debug] {NET} tor_tls_read(): read returned r=-1, err=-2 Dec 15 22:55:51.000 [debug] {NET} tor_tls_read(): read returned r=-1, err=-2 Dec 15 22:55:51.000 [info] {EDGE} connection_edge_process_relay_cell(): 676: end cell (misc error) for stream 60290. Removing stream.
I get very much of these. It does not look healthy to me. Is this normal ?
Again many thanks for your help.
best regards
Dirk
On 14.12.2015 00:06, Tim Wilson-Brown - teor wrote:
On 14 Dec 2015, at 07:18, Dirk Eschbach <tor-relay.dirk@o.banes.ch mailto:tor-relay.dirk@o.banes.ch> wrote:
...
The big question now is: Why do the machines do not have more throughput ? Is the reason for this the way the distribution through the Tor network works. Moritz hinted it might have to do with the way the tor "bandwidth scanners" measure the ability of a server to handle traffic.
No, this is not the issue, your relay's own self-measured throughput is the issue. See below.
Can you explain me / point me to documentation where this process is described and how this can be optimized. What are the criteria for tor exit node server traffic distribution ?
By consensus weight, which is determined by the bandwidth authorities. https://blog.torproject.org/blog/lifecycle-of-a-new-relay https://stem.torproject.org/tutorials/examples/votes_by_bandwidth_authoritie...
How do the clients choose the exit ?
From those servers they believe exit to the address and port they want, randomly, weighted by the server's consensus weight.
The details of bandwidth weight selection are in section 3.4.2 of the Directory Specification: https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt
"The bandwidth in a "w" line should be taken as the best estimate of the router's actual capacity that the authority has. For now, this should be the lesser of the observed bandwidth and bandwidth rate limit from the server descriptor. It is given in kilobytes per second, and capped at some arbitrary value (currently 10 MB/s).
The Measured= keyword on a "w" line vote is currently computed by multiplying the previous published consensus bandwidth by the ratio of the measured average node stream capacity to the network average. If 3 or more authorities provide a Measured= keyword for a router, the authorities produce a consensus containing a "w" Bandwidth= keyword equal to the median of the Measured= votes."
When I look at the bandwidth authority votes for DigiGesTor1e1, they say: w Bandwidth=9586 Measured=24200 w Bandwidth=9586 Measured=15900 w Bandwidth=9586 Measured=43500 w Bandwidth=9586 Measured=19700 w Bandwidth=9586 Measured=19200
Those votes are in these large files: http://171.25.193.9:443/tor/status-vote/current/authority http://199.254.238.53/tor/status-vote/current/authority http://131.188.40.189/tor/status-vote/current/authority http://128.31.0.34:9131/tor/status-vote/current/authority http://154.35.175.225/tor/status-vote/current/authority
So the bandwidth authorities have having no trouble measuring your relay, they think it should be 2x - 4x as fast. Your relay itself has't observed itself sustaining that performance over a 10-second interval, so it won't allow the directory authorities to assign it more bandwidth.
Section 2.1.1 of the Directory Specification:
""bandwidth" bandwidth-avg bandwidth-burst bandwidth-observed NL
[Exactly once] Estimated bandwidth for this router, in bytes per second. The "average" bandwidth is the volume per second that the OR iswilling to sustain over long periods; the "burst" bandwidth is the volume that the OR is willing to sustain in very short intervals. The "observed" value is an estimate of the capacity this relay can handle. The relay remembers the max bandwidth sustained output over any ten second period in the past day, and another sustained input. The "observed" value is the lesser of these two numbers."
Please improve the throughput your relay can sustain over a 10-second period. Try some performance tuning steps, testing your relay with Tor client after each one. (See below.)
Have you set a limit on MaxAdvertisedBandwidth in the torrc files?
Konsole output top - 09:57:49 up 16 days, 11:57, 1 user, load average: 1.14, 0.91, 0.81 Tasks:244 total, 3 running,241 sleeping, 0 stopped, 0 zombie %Cpu0 :12.5 us, 3.4 sy, 0.0 ni,79.7 id, 0.0 wa, 0.0 hi, 4.4 si, 0.0 st %Cpu1 :15.9 us, 5.4 sy, 0.0 ni,74.3 id, 0.3 wa, 0.0 hi, 4.1 si, 0.0 st %Cpu2 :14.3 us, 2.7 sy, 0.0 ni,77.0 id, 0.0 wa, 0.0 hi, 6.0 si, 0.0 st %Cpu3 : 9.5 us, 3.4 sy, 0.0 ni,80.3 id, 0.0 wa, 0.0 hi, 6.8 si, 0.0 st KiB Mem: 3877624 total, 2739880 used, 1137744 free, 1288 buffers KiB Swap: 4026364 total, 364264 used, 3662100 free. 10752 cached Mem
Looking at the network connection it is without any problem possible to start big downloads without reducing TOR throughput.
Have you tried doing a large download through your exit via a Tor client and seeing how fast that is? ExitNodes <fingerprint od your exit> StrictNodes 1
The servers are connected with 1 Gbit/s each.
It looks like your Tor processes are neither CPU nor network-bound.
Does your network connection drop packets or have large latency?
How many file descriptors are the tor processes allowed to open? How many connections does each tor process have open at once? (There should be thousands per process on a busy relay.)
https://gitweb.torproject.org/tor.git/tree/doc/TUNING
Are there any performance-related messages in the Tor logs?
Is your hardware / kernel / firewall / etc. capable of handling many connections?
Does your provider rate-limit any kinds of traffic? Does your provider limit the number of open connections?
Is your DNS resolver keeping up with the requests? Do you have a local caching DNS resolver on each machine?
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 16 Dec 2015, at 09:07, Dirk Eschbach tor-relay.dirk@o.banes.ch wrote:
...
Finally a set logfiles to debug and started greping for err:
Dec 15 22:55:50.000 [info] {EDGE} connection_edge_process_relay_cell(): 617: end cell (misc error) for stream 7289. Removing stream. Dec 15 22:55:50.000 [debug] {NET} tor_tls_read(): read returned r=-1, err=-2 …
err=-2 is SSL_ERROR_WANT_READ. It happens when OpenSSL is waiting for more data from the network.
It could be normal, so it's hard to tell if you're experiencing too many of these errors.
Are there delays reading from network sockets, or packet loss, or something similar?
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
Hello again,
I reply to nusenu/teor in this mail below mixed.
here delays reading from network sockets, or packet loss, or something
similar
Not really - mtr to google.com ------------------------------------------------------------------------------------------------- My traceroute [v0.85] tor1 (0.0.0.0) Tue Dec 15 23:41:38 2015 Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. ??? 2. v41.core1.zrh1.he.net 0.0% 26 2.3 4.7 1.1 13.4 3.3 3. equinix-zurich.net.google.com 0.0% 25 2.9 6.1 2.8 59.9 11.2 4. 216.239.56.97 0.0% 25 9.3 10.3 8.4 18.2 1.8 5. 216.239.57.135 0.0% 25 10.4 10.9 8.9 23.6 3.4 6. 66.249.95.23 0.0% 25 12.0 12.6 10.7 18.4 1.3 7. 74.125.37.97 0.0% 25 22.1 22.0 20.8 22.8 0.4 8. 209.85.246.164 0.0% 25 21.2 22.5 21.2 26.7 0.9 9. ??? 10. wm-in-f105.1e100.net 0.0% 25 22.9 22.3 20.9 23.2 0.2
-------------------------------------------------------------------------------------------------
example: https://lists.torproject.org/pipermail/tor-relays/2015-July/007402.html
O.k. I did install and config pdns. Lets see. I hope it helps.
Please be cautious when running an exit on debug loglevel - especially if you decide to paste your logs on a public mailing list.
Sure - nothing in there which is a problem. :-) Thanks again for helping.
best regards dirk
Hello Dirk,
mtr or downloading Ubuntu is not a valid task to check your network connectivity. Your server may has a connection speed of 1 GBit/s but that not the traffic you can push the whole time. It depends on multiple factors.
For example: I've a dedicated server in the netherlands with 1 GBit/s and my home connection in Germany with 50 MBit/s. Most of the time I can download with full speed from my server, but every day between 16:00 and 24:00 o'Clock the speed drops down to 100 kbyte/s. Why? The peering between Level 3 and my ISP is out of capacity.
If you add Tor circuits there are even more bottlenecks. You wrote:
"I pinned the ExitNode in my Client and downloaded an Ubuntu image. Download was between 800 kbyte/s and 1 Mbyte/s. Not great"
My absolute highest speed over Tor was 7 MByte/s. So at least all 3 servers (Exit, Middle and Guard) had hight connections speeds. A speed of 2-3 MByte/s is normal for me.
Long story short: Be happy that you run exit relays and don't care that much about your traffic. Also think about network diversity.
~Josef
Am 15.12.2015 um 23:50 schrieb Dirk Eschbach:
Hello again,
I reply to nusenu/teor in this mail below mixed.
here delays reading from network sockets, or packet loss, or something
similar
Not really - mtr to google.com
My traceroute [v0.85]tor1 (0.0.0.0) Tue Dec 15 23:41:38 2015 Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings Host Loss% Snt Last Avg Best Wrst StDev
- ???
- v41.core1.zrh1.he.net 0.0% 26
2.3 4.7 1.1 13.4 3.3 3. equinix-zurich.net.google.com 0.0% 25 2.9 6.1 2.8 59.9 11.2 4. 216.239.56.97 0.0% 25 9.3 10.3 8.4 18.2 1.8 5. 216.239.57.135 0.0% 25 10.4 10.9 8.9 23.6 3.4 6. 66.249.95.23 0.0% 25 12.0 12.6 10.7 18.4 1.3 7. 74.125.37.97 0.0% 25 22.1 22.0 20.8 22.8 0.4 8. 209.85.246.164 0.0% 25 21.2 22.5 21.2 26.7 0.9 9. ??? 10. wm-in-f105.1e100.net 0.0% 25 22.9 22.3 20.9 23.2 0.2
example: https://lists.torproject.org/pipermail/tor-relays/2015-July/007402.html
O.k. I did install and config pdns. Lets see. I hope it helps.
Please be cautious when running an exit on debug loglevel - especially if you decide to paste your logs on a public mailing list.
Sure - nothing in there which is a problem. :-) Thanks again for helping.
best regards dirk _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Unfortunately no better results so far. I did not yet set up an local resolver - does it make such a difference ?
yes.
example: https://lists.torproject.org/pipermail/tor-relays/2015-July/007402.html
Finally a set logfiles to debug
Please be cautious when running an exit on debug loglevel - especially if you decide to paste your logs on a public mailing list.
tor-relays@lists.torproject.org
-
Dirk Eschbach -
Josef 'veloc1ty' Stautner -
nusenu -
Tim Wilson-Brown - teor -
tor-server-creator＠use.startmail.com