Hi list, I’m running a guard relay from my home connection on a Raspberry Pi 4. My internet connection is 1000/100 Mbps, and I thought I’d allocate half of the upload bandwidth for the relay. Then I set RelayBandwidthRate to 10 MB/s, because I thought that Tor would upload 5 MB/s and download 5 MB/s. However, the maximum observed bandwidth was always about 6 MB/s. I’d like to know what could cause this low observed bandwidth. I don’t think it’s the Raspberry Pi, because CPU usage is always low and it has a Gigabit connection to the router. The router itself easily reaches Gigabit speeds, so 10 MB/s should be a breeze. Could it be the number of connections? nyx indicates that the connections are always about 4000. If this is the case, how can I know if the connections bottleneck is the router or the Raspberry Pi? Additionally, I’d like to ask for a rule of thumb for setting the RelayBandwithBurst. I set it to 20 MB/s because I’m ok with the relay using the whole upload bandwidth (about 10 MB/s, or 100 Mbps) for short periods of time, but as I already explained I’m never seeing such speeds. For reference my relay’s fingerprint is F942EE73F1B8E39125F617FA85E80E4C9E540A2E. -m
Hi,
On 12 Apr 2020, at 10:10, Mario Costa <mario.costa@icloud.com> wrote:
I’m running a guard relay from my home connection on a Raspberry Pi 4. My internet connection is 1000/100 Mbps, and I thought I’d allocate half of the upload bandwidth for the relay. Then I set RelayBandwidthRate to 10 MB/s, because I thought that Tor would upload 5 MB/s and download 5 MB/s.
You have an asymmetric connections and Tor is a relay network. So your relay's speed will be limited by the slowest of your upload and download. Tor also assumes your connection is full duplex. (That is, there are separate limits of 10 MB/s up and 10 MB/s down.) You should set rate to the highest sustained bandwidth you're happy for Tor to use. Tor could use that much bandwidth for seconds or hours. That bandwidth should be lower than your connection bandwidth. (The minimum of your upload and download.)
However, the maximum observed bandwidth was always about 6 MB/s. I’d like to know what could cause this low observed bandwidth. I don’t think it’s the Raspberry Pi, because CPU usage is always low and it has a Gigabit connection to the router.
Where are you seeing this observed bandwidth? Tor reports its observed bandwidth over the busiest 10 second period each day. 60% of the rate is actually a pretty high load, because Tor is a low-latency network. (Once utilisation gets over around 10%, latency starts increasing.) If your connection is a high latency connection, Tor may send bandwidth to lower-latency connections. You can read a similar thread here: https://lists.torproject.org/pipermail/tor-relays/2020-April/018348.html
The router itself easily reaches Gigabit speeds, so 10 MB/s should be a breeze. Could it be the number of connections? nyx indicates that the connections are always about 4000. If this is the case, how can I know if the connections bottleneck is the router or the Raspberry Pi?
4000 seems pretty normal. There are only around 6000 relays. Check your tor, kernel, and router logs for TCP warnings?
Additionally, I’d like to ask for a rule of thumb for setting the RelayBandwithBurst. I set it to 20 MB/s because I’m ok with the relay using the whole upload bandwidth (about 10 MB/s, or 100 Mbps) for short periods of time, but as I already explained I’m never seeing such speeds.
Setting your burst higher than your connection speed can cause latency or packet drops. Tor will allocate less bandwidth to slow or unreliable relays. You won't see the burst in Tor's observed bandwidth. The burst is over 1-2 seconds. The rate is averaged over a few seconds. Observed is over 10 seconds. Tor will compensate for a burst by having a few slow seconds afterwards. Set the burst to the highest speed you ever want the relay to use over 1-2 seconds. The burst should be equal to or lower than your connection speed. (In your case, the lowest of your upload and download speed.)
For reference my relay’s fingerprint is F942EE73F1B8E39125F617FA85E80E4C9E540A2E.
If you want Tor to use more bandwidth, try setting rate and burst to 10 Mbps. That way, you won't be causing congestion or packet drops. You may have to wait for a few weeks or months for your bandwidth to stabilise. https://blog.torproject.org/lifecycle-new-relay T
Il giorno 14 apr 2020, alle ore 14:48, teor <teor@riseup.net> ha scritto:
Hi,
On 12 Apr 2020, at 10:10, Mario Costa <mario.costa@icloud.com> wrote:
I’m running a guard relay from my home connection on a Raspberry Pi 4. My internet connection is 1000/100 Mbps, and I thought I’d allocate half of the upload bandwidth for the relay. Then I set RelayBandwidthRate to 10 MB/s, because I thought that Tor would upload 5 MB/s and download 5 MB/s.
You have an asymmetric connections and Tor is a relay network. So your relay's speed will be limited by the slowest of your upload and download.
Tor also assumes your connection is full duplex. (That is, there are separate limits of 10 MB/s up and 10 MB/s down.)
You should set rate to the highest sustained bandwidth you're happy for Tor to use. Tor could use that much bandwidth for seconds or hours. That bandwidth should be lower than your connection bandwidth. (The minimum of your upload and download.)
However, the maximum observed bandwidth was always about 6 MB/s. I’d like to know what could cause this low observed bandwidth. I don’t think it’s the Raspberry Pi, because CPU usage is always low and it has a Gigabit connection to the router.
Where are you seeing this observed bandwidth?
Tor reports its observed bandwidth over the busiest 10 second period each day.
60% of the rate is actually a pretty high load, because Tor is a low-latency network. (Once utilisation gets over around 10%, latency starts increasing.)
If your connection is a high latency connection, Tor may send bandwidth to lower-latency connections.
You can read a similar thread here: https://lists.torproject.org/pipermail/tor-relays/2020-April/018348.html <https://lists.torproject.org/pipermail/tor-relays/2020-April/018348.html>
The router itself easily reaches Gigabit speeds, so 10 MB/s should be a breeze. Could it be the number of connections? nyx indicates that the connections are always about 4000. If this is the case, how can I know if the connections bottleneck is the router or the Raspberry Pi?
4000 seems pretty normal. There are only around 6000 relays. Check your tor, kernel, and router logs for TCP warnings?
Additionally, I’d like to ask for a rule of thumb for setting the RelayBandwithBurst. I set it to 20 MB/s because I’m ok with the relay using the whole upload bandwidth (about 10 MB/s, or 100 Mbps) for short periods of time, but as I already explained I’m never seeing such speeds.
Setting your burst higher than your connection speed can cause latency or packet drops. Tor will allocate less bandwidth to slow or unreliable relays.
You won't see the burst in Tor's observed bandwidth. The burst is over 1-2 seconds. The rate is averaged over a few seconds. Observed is over 10 seconds.
Tor will compensate for a burst by having a few slow seconds afterwards.
Set the burst to the highest speed you ever want the relay to use over 1-2 seconds. The burst should be equal to or lower than your connection speed. (In your case, the lowest of your upload and download speed.)
For reference my relay’s fingerprint is F942EE73F1B8E39125F617FA85E80E4C9E540A2E.
If you want Tor to use more bandwidth, try setting rate and burst to 10 Mbps.
That way, you won't be causing congestion or packet drops.
You may have to wait for a few weeks or months for your bandwidth to stabilise. https://blog.torproject.org/lifecycle-new-relay <https://blog.torproject.org/lifecycle-new-relay>
T
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Thank you, I mistakenly thought the the Bandwidth limits were up+down, this really clarified many things.
Il giorno 14 apr 2020, alle ore 17:21, torjoy <south_america_bridges@protonmail.com> ha scritto:
Hi Mario,
I'm having same trouble with raspberry pi 3b... I use Wi-Fi connection with high throughput. My local connection can copy files up to 15MB/s to this RPi. It is a USB adapter (mediatek MT7601). I'm asking myself that speed on tor network shouldn't be more than 2 MB/s. I've limited the maximum in 3,2 MB/s and burst to 4,3 MB/s, my connection here in Brazil is just of 240 Mb/s // 24 Mb/s... At least 2,2 MB/s should be reached in the measurements i guess. In the past i shouldn't pass from 600 KB/s thus because my CPU consumption with TOR was near to 100%. But i've set more parallel threads in torrc and recompilled my openssl to support it the linux crypto engine, that can handle faster crypto operations. With this i've enabled hardware acceleration on torrc and reached a little bit more than 1MB/s in the measurements.
Luiz
Sent with ProtonMail Secure Email.
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
As the guys explained to me you will not reach constant full load, and if your relay is fairly new it can take some time. Plus, I don’t think that wifi is the best choice for a relay. Even if your RasPi 3 doesn’t have a Gigabit adapter, a 100 Mbps ethernet connection should be more than enough for your desired Bandwidth limits. -m
Hi Mario, I'm having same trouble with raspberry pi 3b... I use Wi-Fi connection with high throughput. My local connection can copy files up to 15MB/s to this RPi. It is a USB adapter (mediatek MT7601). I'm asking myself that speed on tor network shouldn't be more than 2 MB/s. I've limited the maximum in 3,2 MB/s and burst to 4,3 MB/s, my connection here in Brazil is just of 240 Mb/s // 24 Mb/s... At least 2,2 MB/s should be reached in the measurements i guess. In the past i shouldn't pass from 600 KB/s thus because my CPU consumption with TOR was near to 100%. But i've set more parallel threads in torrc and recompilled my openssl to support it the linux crypto engine, that can handle faster crypto operations. With this i've enabled hardware acceleration on torrc and reached a little bit more than 1MB/s in the measurements. Luiz Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ Em Sábado, 11 de Abril de 2020 às 09:55, Mario Costa <mario.costa@icloud.com> escreveu:
Hi list,
I’m running a guard relay from my home connection on a Raspberry Pi 4. My internet connection is 1000/100 Mbps, and I thought I’d allocate half of the upload bandwidth for the relay. Then I set RelayBandwidthRate to 10 MB/s, because I thought that Tor would upload 5 MB/s and download 5 MB/s.
However, the maximum observed bandwidth was always about 6 MB/s. I’d like to know what could cause this low observed bandwidth. I don’t think it’s the Raspberry Pi, because CPU usage is always low and it has a Gigabit connection to the router.
The router itself easily reaches Gigabit speeds, so 10 MB/s should be a breeze. Could it be the number of connections? nyx indicates that the connections are always about 4000. If this is the case, how can I know if the connections bottleneck is the router or the Raspberry Pi?
Additionally, I’d like to ask for a rule of thumb for setting the RelayBandwithBurst. I set it to 20 MB/s because I’m ok with the relay using the whole upload bandwidth (about 10 MB/s, or 100 Mbps) for short periods of time, but as I already explained I’m never seeing such speeds.
For reference my relay’s fingerprint is F942EE73F1B8E39125F617FA85E80E4C9E540A2E.
-m
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[Hi Mario! I wrote this draft and then stopped half-through, and then teor wrote a good response too. So I'm going to send it as-is, rather than quietly delete it, in case it helps reinforce some of the points that teor made.] On Sat, Apr 11, 2020 at 02:55:59PM +0200, Mario Costa wrote:
I???m running a guard relay from my home connection on a Raspberry Pi 4.
Thanks for running a relay!
My internet connection is 1000/100 Mbps, and I thought I???d allocate half of the upload bandwidth for the relay. Then I set RelayBandwidthRate to 10 MB/s, because I thought that Tor would upload 5 MB/s and download 5 MB/s.
Actually, a rate of 10mbytes/s means it will do up to 10mbytes/s upload and also up to 10mbytes/s download. That is, the rate setting applies to 'each way', not 'total for both'.
However, the maximum observed bandwidth was always about 6 MB/s. I???d like to know what could cause this low observed bandwidth. I don???t think it???s the Raspberry Pi, because CPU usage is always low and it has a Gigabit connection to the router.
Answer #1: that 6mbytes/s is the most the relay has seen itself actually handle, in any ten-second period. That is, there was some ten second period over the past few days where the relay sent 60mbytes of actual traffic, and also some ten second period (doesn't have to be the same one) where it received 60mbytes of actual traffic. So it isn't that the relay measured itself and found that it could only do 6mbytes/s. It's that the load from actual user traffic has reached that high, and so that's the number that it has seen itself do ("observed"). And that leads to the natural follow-up question of "Ok, but how come the user traffic only got that high? I could handle a lot more!" And that's a harder question to answer, because it has to do with overall network load ("what all the Tor users together are trying to do right now"), and with load balancing across all the relays ("how much of that traffic gets sent toward your relay"). The simple answer is that random chance hasn't yet brought the combination of user flows to your relay at the right time to show it that it can do more. But here, your 100mbit up limit looks like it could actually matter. The reason is that you can't push more than about 12 megabytes in a second, and that could impact whether you end up pushing more than 60 megabytes in 10 seconds. I tried to construct a concrete scenario with numbers that add up, but I have so far failed to make a convincing one. So maybe 100mbit is sufficiently high that there aren't realistic scenarios where it will be a limitation. I'm not sure. Hope this helps, --Roger
Hi Roger, Thank you for your answer, you and teor really helped me figure this out. I set BW rate and burst to 10 MB/s and hope to get more traffic once the relay becomes guard for enough clients. Being on a dynamic IP I guess that every time the ISP changes my address and have to get a new guard flag, I’ll experience a drop in traffic. -m
Il giorno 16 apr 2020, alle ore 16:22, Roger Dingledine <arma@torproject.org> ha scritto:
[Hi Mario! I wrote this draft and then stopped half-through, and then teor wrote a good response too. So I'm going to send it as-is, rather than quietly delete it, in case it helps reinforce some of the points that teor made.]
On Sat, Apr 11, 2020 at 02:55:59PM +0200, Mario Costa wrote:
I???m running a guard relay from my home connection on a Raspberry Pi 4.
Thanks for running a relay!
My internet connection is 1000/100 Mbps, and I thought I???d allocate half of the upload bandwidth for the relay. Then I set RelayBandwidthRate to 10 MB/s, because I thought that Tor would upload 5 MB/s and download 5 MB/s.
Actually, a rate of 10mbytes/s means it will do up to 10mbytes/s upload and also up to 10mbytes/s download. That is, the rate setting applies to 'each way', not 'total for both'.
However, the maximum observed bandwidth was always about 6 MB/s. I???d like to know what could cause this low observed bandwidth. I don???t think it???s the Raspberry Pi, because CPU usage is always low and it has a Gigabit connection to the router.
Answer #1: that 6mbytes/s is the most the relay has seen itself actually handle, in any ten-second period. That is, there was some ten second period over the past few days where the relay sent 60mbytes of actual traffic, and also some ten second period (doesn't have to be the same one) where it received 60mbytes of actual traffic.
So it isn't that the relay measured itself and found that it could only do 6mbytes/s. It's that the load from actual user traffic has reached that high, and so that's the number that it has seen itself do ("observed").
And that leads to the natural follow-up question of "Ok, but how come the user traffic only got that high? I could handle a lot more!"
And that's a harder question to answer, because it has to do with overall network load ("what all the Tor users together are trying to do right now"), and with load balancing across all the relays ("how much of that traffic gets sent toward your relay").
The simple answer is that random chance hasn't yet brought the combination of user flows to your relay at the right time to show it that it can do more.
But here, your 100mbit up limit looks like it could actually matter. The reason is that you can't push more than about 12 megabytes in a second, and that could impact whether you end up pushing more than 60 megabytes in 10 seconds. I tried to construct a concrete scenario with numbers that add up, but I have so far failed to make a convincing one. So maybe 100mbit is sufficiently high that there aren't realistic scenarios where it will be a limitation. I'm not sure.
Hope this helps, --Roger
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
participants (4)
-
Mario Costa -
Roger Dingledine -
teor -
torjoy