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.
tor-relays@lists.torproject.org