[tor-dev] Raising AuthDirMaxServersPerAddr to 4?

[Roger Dingledine]

On Sun, Jun 02, 2019 at 10:11:46PM +1000, teor wrote:
> The relay's recent history is a bit more complicated. This fingerprint has
> only been around since October 2018.

Actually, no, it's been around since something like 2006. But it looks
like it was a small relay in recent years, until it became huge in 2018.

> And there are two exits on this machine. Here's the other one:
> 
> https://metrics.torproject.org/rs.html#details/6B37261F1248DA6E6BB924161F8D7B019BC3B5B4
> 
> It's RelayBandwidthRate-limited to 15 MBytes/s, so the operator's first
> step should be to remove this limit, and wait a week for the bandwidths
> to stabilise.

I asked about this, and this other exit is not on the same machine. It's
on the same IP address, yes, but it's running on a different computer,
and that computer is lacking AESNI and other things that would let it
scale well with Tor's current multithreading situation.

I encouraged the operator to raise the Burst on che1, since it seems
pretty much maxed out (which means every second some users are suffering
by having their traffic rate limited). And also to consider moving che1
onto the same hardware as che, because maybe it can scale better even
though it would be sharing the same cpu with che.

> The first exit is also rate-limited to 85 MBytes/s. It might be a good
> idea to remove both limits at the same time.

Well, closer to 90mbytes, or about 717 mbits/s, with a burst up to 819
mbits/s (depending on your definition of m). I can't imagine that raising
those rate limits will make a big difference. But you're right that he
should raise them anyway, just to rule it out as another variable.

> Can you hold off on your proposed changes until we see what happens after
> the bandwidth limits are removed?

Yes. But it seems like a poor tradeoff to me, to continue delaying exit
relay operators from contributing as much as they want to contribute, when
we could apply this bandaid while continuing to work on the better fixes.

That said, for this particular instance, I am beginning to think that
raising AuthDirMaxServersPerAddr to 3 (rather than 4) would be a good
next step for seeing how that goes.

Thanks!
--Roger