[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP



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@xxxxxxxxxxxxxxxxxxxx] On Behalf
Of teor
Sent: Tuesday, January 03, 2017 5:31 AM
To: tor-relays@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [tor-relays] Unwarranted discrimination of relays with dynamic
IP


> On 28 Dec 2016, at 02:50, Rana <ranaventures@xxxxxxxxx> 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
------------------------------------------------------------------------




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