Re: [tor-relays] Low observed bandwith

[Mario Costa]

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  
> 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

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Low observed bandwith

[Mario Costa]

> Il giorno 14 apr 2020, alle ore 14:48, teor  ha scritto:
> 
> Hi,
> 
>> On 12 Apr 2020, at 10:10, Mario Costa  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
> 
> ___
> 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 
>  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
> 

Re: [tor-relays] Low observed bandwith

[Roger Dingledine]

[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

Re: [tor-relays] Low observed bandwith

[torjoy]

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  
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


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Low observed bandwith

[teor]

Hi,

> On 12 Apr 2020, at 10:10, Mario Costa  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

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Low observed bandwith

[Mario Costa]

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