relay maintenance without losing consensus weight?
Hello, is there a way to shut down Tor relays for a short time without losing consensus weight or bandwidth? Last week I installed a newer Tor version and added more RAM and now my relays lost a third of their bandwidth. Last time I've upgraded the hardware was in January and the relays didn't fully recover from the downtime in the last two months. I'd gladly provide 200Mb/s+ of relay bandwidth if I could, but Tor won't let me. - Zwiebel
On 8 Mar 2016, at 22:37, Zwiebel <zwiebel@kawo2.rwth-aachen.de> wrote:
Hello, is there a way to shut down Tor relays for a short time without losing consensus weight or bandwidth?
This is a frequently asked question, particularly if you add "losing flags" to the relay operator's list of concerns. I wonder if it's worth adding a FAQ or wiki entry with potential answers: It takes time: * wait, and the authorities and bandwidth authorities will re-assess your relay over about a week; * clients may have given up on you as a guard, and may not come back for several months; The network is dynamic: * if the network is growing, your relay's share is going to be lower over time; * if the network is not using its full relay capacity, this is good, because packets travel faster; * (it's also good because sudden increases can be absorbed without impacting existing users); We make bug fixes and add features: * we recently fixed a bug where a relay would submit a descriptor with an 0 DirPort when it restarted (0.2.7.7 [unreleased], 0.2.8.1-alpha); * in 0.2.8, network load is moved from the authorities to fallback directory mirrors, please opt-in if your relay is stable; * in 0.2.8, network load is moved from directory mirrors with DirPorts, to almost all relays via tunnelled directory connections. Depending on your relay's role in the network, it might see more or less traffic with these changes.
Last week I installed a newer Tor version and added more RAM and now my relays lost a third of their bandwidth. Last time I've upgraded the hardware was in January and the relays didn't fully recover from the downtime in the last two months. I'd gladly provide 200Mb/s+ of relay bandwidth if I could, but Tor won't let me.
Networks need extra capacity - it increases average speeds, and absorbs sudden usage spikes. Consider starting a second tor instance on other ports to use the extra capacity on your server. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
On Tue, Mar 08, 2016 at 11:20:09PM +0800, Tim Wilson-Brown - teor wrote:
On 8 Mar 2016, at 22:37, Zwiebel <zwiebel@kawo2.rwth-aachen.de> wrote:
Hello, is there a way to shut down Tor relays for a short time without losing consensus weight or bandwidth?
This is a frequently asked question, particularly if you add "losing flags" to the relay operator's list of concerns.
So... is it possible?
Zwiebel wrote:
Tim Wilson-Brown - teor wrote:
Zwiebel wrote: is there a way to shut down Tor relays for a short time without losing consensus weight or bandwidth?
This is a frequently asked question, particularly if you add "losing flags" to the relay operator's list of concerns.
So... is it possible?
I don't think that short maintenance outages should significantly impact consensus weight. Bandwidth takes a little while to ramp back up because people need to build circuits through your relay again. Anyway, if you need to do maintenance, don't wait. The network benefits more from a secure, reliable relay with 5% less consensus weight. :-)
You can take it down for some days without losing any flags or consensus weight. Had it with my exit i have at home. I had to reinstall it and i have the same stats as before. Best regards, Volker
Am 08.03.2016 um 19:26 schrieb Michael McConville <mmcco@mykolab.com>:
Zwiebel wrote:
Tim Wilson-Brown - teor wrote:
Zwiebel wrote: is there a way to shut down Tor relays for a short time without losing consensus weight or bandwidth?
This is a frequently asked question, particularly if you add "losing flags" to the relay operator's list of concerns.
So... is it possible?
I don't think that short maintenance outages should significantly impact consensus weight. Bandwidth takes a little while to ramp back up because people need to build circuits through your relay again.
Anyway, if you need to do maintenance, don't wait. The network benefits more from a secure, reliable relay with 5% less consensus weight. :-) _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 08.03.2016 19:30, Volker Mink wrote:
You can take it down for some days without losing any flags or consensus weight. Had it with my exit i have at home. I had to reinstall it and i have the same stats as before.
The HSDir flag will be cleared after each restart of the Tor daemon, and be set again after a certain amount of uptime. The consensus weight doesn't change significantly due to short maintenance outages.
On 9 Mar 2016, at 05:26, Michael McConville <mmcco@mykolab.com> wrote:
Zwiebel wrote:
Tim Wilson-Brown - teor wrote:
Zwiebel wrote: is there a way to shut down Tor relays for a short time without losing consensus weight or bandwidth?
This is a frequently asked question, particularly if you add "losing flags" to the relay operator's list of concerns.
So... is it possible?
I don't think that short maintenance outages should significantly impact consensus weight. Bandwidth takes a little while to ramp back up because people need to build circuits through your relay again.
Anyway, if you need to do maintenance, don't wait. The network benefits more from a secure, reliable relay with 5% less consensus weight. :-)
If you take down your relay and keep the same key, IP address(es) and port(s), then most flags should come back quickly. If you change any of those details, particularly the key, then the network will take some time (a week to several months) to re-evaluate your relay. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
participants (5)
-
Michael McConville -
Random Tor Node Operator -
Tim Wilson-Brown - teor -
Volker Mink -
Zwiebel