The previous drops, i know why they happened (related to server unavailability) so I know the cause. For 5th however I have no clue.

Seb

On Tue, 8 Nov 2016 at 13:12 teor teor2345@gmail.com wrote:

...

On 8 Nov. 2016, at 22:52, r1610091651 r1610091651@telenet.be wrote:

Hi all

The consensus weight of the relay I'm running drop recently (5th of nov)

to almost half of previous value. To my knowledge there was no changes on my end.

...

https://atlas.torproject.org/#details/36EE8D47E570B8D5515460A9972F3CFD9EDFDF...

If you look at the 1 month graph, this does not seem to be unusual for your relay.

...

Is there a way to identify the cause of this drop?

The bandwidth authorities measured your relay as being able to handle approximately 2490 KByte/s. (High 4370, Low 1410, Median 2490.)

(large page)

https://consensus-health.torproject.org/consensus-health-2016-11-08-11-00.ht...

Your relay's observed bandwidth is also 2.39 MByte/s (hover over the bandwidth heading in atlas for these details), so its consensus weight will be limited to approximately ~2447 (KByte/s) anyway.

If you want to increase these measurements, try increasing the BandwidthRate and BandwidthBurst in your relay's torrc, and waiting a week.

...

Is there anyone else in same situation?

The system is functioning as designed: your relay's observed maximum bandwidth is almost identical to the bandwidth measured by the bandwidth authorities.

If you want to fix this, add more bandwidth.

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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Thanks for the link to consensus-health, based data available:

05/11 17:00 longclaw=4540 gabelmoo=4170 moria1=4410 faravahar=2520 => cons: 4170

05/11 18:00 longclaw=4550 gabelmoo=*2170* moria1=4410 faravahar=2520 => cons: *2520*

So that explains the drop.

Seb

On Tue, 8 Nov 2016 at 13:40 teor teor2345@gmail.com wrote:

...

On 8 Nov. 2016, at 23:32, r1610091651 r1610091651@telenet.be wrote:

The previous drops, i know why they happened (related to server

unavailability) so I know the cause. For 5th however I have no clue.

As far as I can tell, the relay is accurately measured.

Sometimes, this means that you get a lower measurement than you might have had before.

Accurate bandwidth measurements are a good thing for tor users, even if the changes in the measurement are sometimes (temporarily) disappointing to relay operators.

If you want to improve the measurements, try adding more bandwidth. For your relay, this means increasing BandwidthRate and BandwidthBurst.

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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

(It really would help if you posted your replies below the previous reply.)

On 9 Nov. 2016, at 10:07, r1610091651 r1610091651@telenet.be wrote:

Based on found numbers, some thoughts:

• shouldn't there be more authority servers? DNS system has 13 root servers spread over the globe…

There are 5 bandwidth authorities, we're working on getting more.

• not all authority servers are equal:

** reported data varies greatly between servers https://consensus-health.torproject.org/consensus-health-2016-11-08-19-00.ht...: maatuska=1400 <> gabelmoo=4060

Yes, the speed measured by a bandwidth authority depends on: * location of the bandwidth authority, * time of measurement, * randomly chosen relay pair, * latency and bandwidth through that pair to the remote download site, * other load on the bandwidth authority and relays at the time.

In general, the further away your relay is from the bandwidth authority, the lower the measurement will be.

** some authorities vary greatly in reported data: https://consensus-health.torproject.org/consensus-health-2016-11-08-19-00.ht...: gabelmoo=4060 https://consensus-health.torproject.org/consensus-health-2016-11-08-18-00.ht...: gabelmoo=2110

Yes, measurements are timing and load dependent.

• authority participating in consensus change, and with only few active (4-5) at a time, impact of a single authority on network is amplified

This is why the median is used.

By having more servers

• consensus would be more stable (low-median)
• leading to more accurate assessment of nodes
• and wider utilisation of the available nodes
• leading to higher network throughput

Does that sound plausible?

The first two, yes, the last two, perhaps. Maybe lower latency is more important than throughput?

But each bandwidth authority uses bandwidth that would otherwise be available to clients. So there is a tradeoff.

T

On 8 Nov. 2016, at 23:15, Markus Koch niftybunny@googlemail.com wrote:

https://atlas.torproject.org/#details/B771AA877687F88E6F1CA5354756DF6C8A7B6B...

the same, others are perfectly fine. no clue why :/

(This conversation might make more sense if you replied below the original email, which is known as bottom-posting.)

...

Is there a way to identify the cause of this drop?

The bandwidth authorities measured your relay as being able to handle approximately

9960 KByte/s (High 17500, Low 5470, Low-Median 9960.)

(large page)

https://consensus-health.torproject.org/consensus-health-2016-11-08-11-00.ht...

Your relay's observed bandwidth is also

12.37 MByte/s

(hover over the bandwidth heading in atlas for these details), so its consensus weight will be limited to approximately

~12667

(KByte/s) anyway.

If you want to increase these measurements, try increasing the

actual traffic your relay can handle.

...

Is there anyone else in same situation?

The system is functioning as designed: your relay's observed maximum bandwidth is

approximately the same as

the bandwidth measured by the bandwidth authorities.

If you want to fix this, add more bandwidth.

T