[tor-relays] slow relays

niftybunny abuse at to-surf-and-protect.net
Sun Jan 13 19:58:53 UTC 2019


D76E1FDC
D76E1FDC7A3D899282BB882F74111B36A6D14B64	2propstor 
Relay Search <https://metrics.torproject.org/rs.html#details/D76E1FDC7A3D899282BB882F74111B36A6D14B64> | ⇜ <https://consensus-health.torproject.org/consensus-health-2019-01-13-18-00.html#D76E1FDC7A3D899282BB882F74111B36A6D14B64>	Fast 
Guard 
HSDir 
Running 
Stable 
V2Dir 
Valid 
bw=7800	Fast 
Guard 
HSDir 
Running 
Stable 
V2Dir 
Valid	Fast 
Guard 
HSDir 
Running 
Stable 
V2Dir 
Valid 
bw=9000	Fast 
Guard 
HSDir 
Running 
Stable 
V2Dir 
Valid	Fast 
Guard 
HSDir 
Running 
Stable 
V2Dir 
Valid 
bw=13100	Fast 
!Guard 
HSDir 
Running 
Stable 
V2Dir 
Valid	Fast 
Guard 
HSDir 
Running 
Stable 
V2Dir 
Valid 
bw=4430	Fast 
Guard 
HSDir 
Running 
Stable 
V2Dir 
Valid	Fast 
Guard 
HSDir 
Running 
Stable 
V2Dir 
Valid 
bw=10500	Fast 
Guard 
HSDir 
Running 
Stable 
V2Dir 
Valid 
bw=9000 
bwauth=longclaw


Looking at https://consensus-health.torproject.org/consensus-health.html <https://consensus-health.torproject.org/consensus-health.html> my best guess would be that you are too far away from the Authority Servers. So your delay is too hight and the bw measurement is too low. Thats why the most high speed relays cluster in some countries / providers. I am sure Teor could this explain much better than I do. 

Markus


> On 13. Jan 2019, at 19:23, ronqtorrelays at risley.net wrote:
> 
> 
>> On Jan 12, 2019, at 18:32, teor <teor at riseup.net> wrote:
>> 
>> Here are some initial steps for troubleshooting:
>> https://trac.torproject.org/projects/tor/wiki/doc/MyRelayIsSlow
> 
> Hi!
> 
> I have been running a couple of relays for 4-5 years. In spite of following the advice in the link above, I still only average about 8Mb/s on both the relays, as reported by Nyx.
> 
> D76E1FDC7A3D899282BB882F74111B36A6D14B64
> 56DCA89A6B41ADA30E891EF65FDCC071DC05079B
> 
> Both are on 100Mb/s fiber optic lines, otherwise lightly loaded. Both have well over 99.99% uptime. They are on separate autonomous systems. One relay rarely has CPU usage above 5%. The other (on much lighter-weight hardware) approaches 40% CPU occasionally, but both have about the same reported bandwidth stats. The lines are both low-latency.
> 
> Both relay boxes can sustain file transfers at close to the full 100Mb/s (or more) for extended periods of time in testing. Packet loss between the boxes is nearly zero. Testing with iperf shows full bandwidth to even disparate parts of the internet.
> 
> One of the boxes is behind NAT, but with appropriate port forwarding. The other box sits directly on the net with a dedicated static IP.
> 
> Both boxes are running Linux Devuan ASCII, though I saw similar numbers with vanilla Debian and Ubuntu.
> 
> I haven't seen anything in the logs that indicates any problems.
> 
> I don't have any bandwidth limits set in torrc. The metrics.torproject.org page shows "Advertised Bandwidth" of 7.45 MiB/s and 5.11 MiB/s respectively, but the bandwidth graphs are only rarely above 1 MiB/s.
> 
> Both relays are reachable net-wide on their IPv4 addresses. I have IPv6 disabled for now. Correct addresses are showing on the directory authorities. They are the only relays on their respective IP addresses (indeed, on their respective AS's). They have seven flags on the consensus health page with what I think are reasonable bandwidth numbers (I'm not 100% sure how to interpret the "bw=4600" lines, but the number is over 4000 wherever it's reported for my relays.)
> 
> So why do my relays seem to only be using about 8% of their available bandwidth?
> 
> Thanks for any insight you can provide...
> 
> --Ron
> _______________________________________________
> tor-relays mailing list
> tor-relays at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20190113/cbb83ce8/attachment.html>


More information about the tor-relays mailing list