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... Is there a way to identify the cause of this drop? Is there anyone else in same situation? Thanks Seb
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 ------------------------------------------------------------------------------
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
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 ------------------------------------------------------------------------------
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
Based on found numbers, some thoughts: * shouldn't there be more authority servers? DNS system has 13 root servers spread over the globe... * 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 ** 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 * authority participating in consensus change, and with only few active (4-5) at a time, impact of a single authority on network is amplified 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? Cheers Seb On Tue, 8 Nov 2016 at 17:37 r1610091651 <r1610091651@telenet.be> wrote:
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 -- 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 ------------------------------------------------------------------------------
https://atlas.torproject.org/#details/B771AA877687F88E6F1CA5354756DF6C8A7B6B... the same, others are perfectly fine. no clue why :/ markus 2016-11-08 12:52 GMT+01:00 r1610091651 <r1610091651@telenet.be>:
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...
Is there a way to identify the cause of this drop? Is there anyone else in same situation?
Thanks Seb
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
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 -- 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 ------------------------------------------------------------------------------
participants (3)
-
Markus Koch -
r1610091651 -
teor