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/6B37261F1248DA6E6BB924161F8D7...
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