reduced the bandwidth stats interval from 4 hours to 24 hours, and
reduced urgent (2x change) descriptor bandwidth reports from every 20 minutes to every 3 hours.
But we think we can make descriptor bandwidth reports even slower on large relays, because they have less need to ramp up their bandwidth.
Here are our options:
don't report until the change is larger, for example, 4x
don't report for longer, for example, every 6 hours or 24 hours
delay the reporting of the first large change, as well as subsequent large changes
Here are the open questions:
tor traffic has a daily cycle, so do we need to report large bandwidth changes multiple times a day to cope with this? (I think the answer is "no", because small changes are already reported every 18 hours on the standard descriptor schedule, and that seems to work fine. And large changes are already reported once, then the delay is imposed.)
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items 0
Show closed items
No child items are currently assigned. Use child items to break down this issue into smaller parts.
Linked items 0
Link issues together to show that they're related.
Learn more.
I am a fan of "publish a new descriptor for sufficiently-changed bandwidth estimates if your uptime is less than 24 hours, else assume that things are sufficiently established and the next regularly scheduled descriptor update will be enough".
I am a fan of "publish a new descriptor for sufficiently-changed bandwidth estimates if your uptime is less than 24 hours, else assume that things are sufficiently established and the next regularly scheduled descriptor update will be enough".
I can imagine two pathological cases here:
relays that reboot (or hibernate) every 24 hours, and
relays that hibernate or go offline, rather than just having started.
We'll need to account for both these cases, but they'll make the relay lose the guard flag, so we don't need to be so concerned about them.
If we code this feature so we can make bandwidth reporting faster on non-default networks, that would make it easier to test bandwidth authorities in chutney (see also #16386 (moved)).
I am a fan of "publish a new descriptor for sufficiently-changed bandwidth estimates if your uptime is less than 24 hours, else assume that things are sufficiently established and the next regularly scheduled descriptor update will be enough".
This seems like a nice simple solution to the issue. Let's make it happen.
Should instead i do get_uptime() > 60*60*24 return; at the beginning of the function so that there are not any further checks when the relay is up for more than 1 day?
Trac: Owner: N/Ato juga Status: new to assigned Cc: juga toN/A
Should instead i do get_uptime() > 60*60*24 return; at the beginning of the function so that there are not any further checks when the relay is up for more than 1 day?
Yes, but please make 60*60*24 a named #define with a comment. It should be like MAX_BANDWIDTH_CHANGE_FREQ.
test_router.c only contains 1 test and adding a test for this does not seem possible without adding more mocking functions, as get_uptime and bandwidthcapacity