Hi There I evaluated some relays with newly assigned (red) guard flags. All of them had already the stable flag assigned. And (so far I could see) all of them had (almost) static IP addresses. In my case, this may be the reason why I don't get a guard flag. My ISP changes it every 24 hours. However, I'd be fine with "just" operating a fast middle node. I will keep an eye on this. Mike
Speaking of guards, could someone come with a theory pf what happened here https://atlas.torproject.org/#details/707A9A3358E0D8653089AF32A097570A96400CC6 ? The IP is static, the relay exists for 18 days and has Stable flag since maybe 2 weeks, the measured bandwidth -153 KB/s - exactly equals the bandwidth limit in torrc for 2 weeks now. What could explan the sudden catastrophic drop in bandwidth after linear if not exponential growth? This article https://blog.torproject.org/blog/lifecycle-of-a-new-relay describes exactly this pattern but the drop occurs when a Guard flag is awarded. In this case, no guard fag. Any ideas?
From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of balbea16 Sent: Tuesday, December 27, 2016 5:05 PM To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP
Hi There I evaluated some relays with newly assigned (red) guard flags. All of them had already the stable flag assigned. And (so far I could see) all of them had (almost) static IP addresses. In my case, this may be the reason why I don't get a guard flag. My ISP changes it every 24 hours. However, I'd be fine with "just" operating a fast middle node. I will keep an eye on this. Mike
On 28 Dec 2016, at 02:50, Rana ranaventures@gmail.com wrote:
Speaking of guards, could someone come with a theory pf what happened here? The IP is static, the relay exists for 18 days and has Stable flag since maybe 2 weeks, the measured bandwidth -153 KB/s - exactly equals the bandwidth limit in torrc for 2 weeks now. What could explan the sudden catastrophic drop in bandwidth after linear if not exponential growth? This articledescribes exactly this pattern but the drop occurs when a Guard flag is awarded. In this case, no guard fag. Any ideas?
When your relay reaches its bandwidth rate, it has no spare capacity. Therefore, the bandwidth authority measurements (and consensus weight) are lower.
Since the consensus weight is lower, clients use the relay less. The relay has spare capacity, and the bandwidth authority measurements (and consensus weight) are higher.
This feedback process continues until the relay utilisation and consensus weight stabilise.
(Large page) https://consensus-health.torproject.org/consensus-health-2017-01-03-02-00.ht...
In this particular case, the changes are large. This might be because: * the bandwidth rate is low, * the connection speed is high compared to the bandwidth rate, * the IP address changes, or * the relay restarts, or * perhaps some other reason.
T
-- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
To recap, we are talking about https://atlas.torproject.org/#details/707A9A3358E0D8653089AF32A097570A96400C C6
Thanks but your explanation does not seem to apply here. The measured BW is equal to the limit and has been the same rock solid number (153.6 KB/s) for weeks. As you see on the graph, the actual throughput is nowhere near the limit. The IP is static and therefore never changed. The relay almost never restarted and certainly did not restart for weeks before the drop occurred (uptime is 24 days now). And as you see it never really recovered from the drop and seems to have stabilized at about 7% of its (as measured and reported in Atlas) capacity.
What am I missing?
-----Original Message----- From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of teor Sent: Tuesday, January 03, 2017 5:31 AM To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP
On 28 Dec 2016, at 02:50, Rana ranaventures@gmail.com wrote:
Speaking of guards, could someone come with a theory pf what happened
here? The IP is static, the relay exists for 18 days and has Stable flag since maybe 2 weeks, the measured bandwidth -153 KB/s - exactly equals the bandwidth limit in torrc for 2 weeks now. What could explan the sudden catastrophic drop in bandwidth after linear if not exponential growth? This articledescribes exactly this pattern but the drop occurs when a Guard flag is awarded. In this case, no guard fag. Any ideas?
When your relay reaches its bandwidth rate, it has no spare capacity. Therefore, the bandwidth authority measurements (and consensus weight) are lower.
Since the consensus weight is lower, clients use the relay less. The relay has spare capacity, and the bandwidth authority measurements (and consensus weight) are higher.
This feedback process continues until the relay utilisation and consensus weight stabilise.
(Large page) https://consensus-health.torproject.org/consensus-health-2017-01-03-02-00.ht ml#707A9A3358E0D8653089AF32A097570A96400CC6
In this particular case, the changes are large. This might be because: * the bandwidth rate is low, * the connection speed is high compared to the bandwidth rate, * the IP address changes, or * the relay restarts, or * perhaps some other reason.
T
-- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
On 3 Jan 2017, at 17:21, Rana ranaventures@gmail.com wrote:
To recap, we are talking about https://atlas.torproject.org/#details/707A9A3358E0D8653089AF32A097570A96400C C6
Thanks but your explanation does not seem to apply here. The measured BW is equal to the limit and has been the same rock solid number (153.6 KB/s) for weeks.
Please stop calling it the measured bandwidth. It's confusing. The heading is "Advertised Bandwidth".
The components of the Atlas advertised bandwidth are: (View Source or Mouse Over the Advertised Bandwidth figure) https://atlas.torproject.org/#details/707A9A3358E0D8653089AF32A097570A96400C...
Advertised Bandwidth: 153.6 KB/s Bandwidth rate: 153.6 KB/s Bandwidth burst: 179.2 KB/s Observed bandwidth: 173.03 KB/s
Look in my previous emails for definitions of these figures, and how the advertised bandwidth is calculated from them.
As you see on the graph, the actual throughput is nowhere near the limit.
The reported bandwidth doesn't need to be near the limit to decrease the measured bandwidth. Any client usage decreases the extra bandwidth available for measurement, and therefore decreases the measurement.
The IP is static and therefore never changed. The relay almost never restarted and certainly did not restart for weeks before the drop occurred (uptime is 24 days now). And as you see it never really recovered from the drop and seems to have stabilized at about 7% of its (as measured and reported in Atlas) capacity.
It seems your relay's sustained capacity might be much less than the bandwidth rate. There are many factors that can limit relay capacity. Look in previous emails on this list for some of the different factors.
What am I missing?
Maybe the measurement system works, and your relay just can't sustain high volumes of traffic (or large numbers of connections).
T
-- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
tor-relays@lists.torproject.org
-
balbea16 -
Rana -
teor