Re: [tor-relays] dynamically adjusting bandwidth

The question is, should I put in an adjustment for 'MaxAdvertisedBandwidth' during the backup window or make any other change to advise remote relays to de-prioritize the node for the duration?
Another unanswered question now understood: As a consequence of a simple parameter tweak, Vidalia buggily zapped (for the second time) the relay configuration and turned off relaying. Quickly restored 'torrc' and restarted the relay, but noticed that the getinfo dir/server/authority observed bandwidth value (third of three) was zapped to a low value for about an hour. This had the effect of causing four out of nine authorities to remove the Guard flag and almost resulted in a consensus "not Guard" state. So the answer here is definitely DO NOT lower 'MaxAdvertisedBandwidth' during intervals when 'RelayBandwidthRate' is reduced for events like offsite backups. Doing so will probably cause the Guard flag to be removed when it is present. The only possible exception would be if one has insane amounts of bandwidth and the lowered value is still quite high. Seems unlikely that 'MaxAdvertisedBandwidth' has any immediate effect on the selection algorithm is only averaged into consensus bandwidth gradually, so probably it's best to not make temporary reductions.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 starlight.2013q4@binnacle.cx:
The question is, should I put in an adjustment for 'MaxAdvertisedBandwidth' during the backup window or make any other change to advise remote relays to de-prioritize the node for the duration? [snip] So the answer here is definitely DO NOT lower 'MaxAdvertisedBandwidth' during intervals when 'RelayBandwidthRate' is reduced for events like offsite backups. Doing so will probably cause the Guard flag to be removed when it is present.
Thank you, this is really useful to know for Cipollini[1]. We're working currently on automatic bandwidth tuning and congestion avoidance. 1. https://github.com/gordon-morehouse/cipollini Best, - -Gordon M. -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJSdnQyAAoJED/jpRoe7/ujKLAH/1Y8zvahIDDrbTqPzRN0HsOP C+TIuqpbR9VDjPhLHgcywbiEBEr6gTLbezh+EnCZeky0bO3WZ1ZHlTZ0Szow3X4P tG7wY47Q34G+g78oKk8jfzYUlq1M2Mo3Lbkce/lkHe3hGece1nqItgLmXGswXP8h AaYUpDEQy6y1jXGTDtwMPQadZ2Qg7oZg4sXrIQ3yZlDWuBVLXzXK+I/GsO40Yd2n 1XGdXkV1r6D095ofBuLXSriO+kKs1qpE9HHb1mvlKYDPe5w2KebUJo1OmzWeDuHE lsLETbf4QUOf0B8opkBGK8VjqjRYDII/dNp9OJbUGVy6hFxVrYxmAXWYRBMNEoY= =Wtgz -----END PGP SIGNATURE-----
participants (2)
-
Gordon Morehouse
-
starlight.2013q4ï¼ binnacle.cx