mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-24 12:23:32 +01:00
Don't delay uploading a new desc if bw estimate was 0
When a tor relay starts up and has no historical information about its bandwidth capability, it uploads a descriptor with a bw estimate of 0. It then starts its bw selftest, but has to wait 20 minutes to upload the next descriptor due to the MAX_BANDWIDTH_CHANGE_FREQ delay. This change should mean that on average, relays start seeing meaningful traffic a little quicker, since they will have a higher chance to appear in the consensus with a nonzero bw. Patch by Roger, changes file and comment by Sebastian.
This commit is contained in:
parent
bce32e0a35
commit
14abf1c3f1
5
changes/bug13000
Normal file
5
changes/bug13000
Normal file
@ -0,0 +1,5 @@
|
||||
o Minor bugfixes:
|
||||
- If our previous bandwidth estimate was 0 bytes, allow publishing a
|
||||
new relay descriptor immediately. Fixes bug 13000; bugfix on
|
||||
0.1.1.6-alpha.
|
||||
|
@ -2063,7 +2063,8 @@ mark_my_descriptor_dirty(const char *reason)
|
||||
}
|
||||
|
||||
/** How frequently will we republish our descriptor because of large (factor
|
||||
* of 2) shifts in estimated bandwidth? */
|
||||
* of 2) shifts in estimated bandwidth? Note: We don't use this constant
|
||||
* if our previous bandwidth estimate was exactly 0. */
|
||||
#define MAX_BANDWIDTH_CHANGE_FREQ (20*60)
|
||||
|
||||
/** Check whether bandwidth has changed a lot since the last time we announced
|
||||
@ -2081,7 +2082,7 @@ check_descriptor_bandwidth_changed(time_t now)
|
||||
if ((prev != cur && (!prev || !cur)) ||
|
||||
cur > prev*2 ||
|
||||
cur < prev/2) {
|
||||
if (last_changed+MAX_BANDWIDTH_CHANGE_FREQ < now) {
|
||||
if (last_changed+MAX_BANDWIDTH_CHANGE_FREQ < now || !prev) {
|
||||
log_info(LD_GENERAL,
|
||||
"Measured bandwidth has changed; rebuilding descriptor.");
|
||||
mark_my_descriptor_dirty("bandwidth has changed");
|
||||
|
Loading…
Reference in New Issue
Block a user