[tor-relays] relay maintenance without losing consensus weight?

Tim Wilson-Brown - teor teor2345 at gmail.com
Tue Mar 8 15:20:09 UTC 2016


> On 8 Mar 2016, at 22:37, Zwiebel <zwiebel at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20160308/c66af949/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20160308/c66af949/attachment.sig>


More information about the tor-relays mailing list