On 7/10/22 22:28, Logforme wrote:
A week ago I implemented connection limits per Toralf's post:
iptables -A INPUT -p tcp --destination-port 443 -m connlimit
--connlimit-mask 32 --connlimit-above 30 -j DROP
This reduced the number of connections to about 1.
I just now noticed that the
Logforme:
On 2022-07-06 21:19, Roger Dingledine wrote:
But it was replaced with a new overload (boo), from way too many Tor
clients running at a few cloud providers. The main result for relay
operators is greatly increased file descriptor use, with a few IP
addresses or /24's generating the
On 2022-07-06 21:19, Roger Dingledine wrote:
But it was replaced with a new overload (boo), from way too many Tor
clients running at a few cloud providers. The main result for relay
operators is greatly increased file descriptor use, with a few IP
addresses or /24's generating the majority of
On Mon, Jun 27, 2022 at 10:58:42PM -0400, Roger Dingledine wrote:
> So: I am giving you all here some early warning, in case you see anything
> odd on the network when we make this change. Let us know if you do. :)
So far so good. Performance looks like it improved.
The "intro2 cell" overload
On Mon, Jun 27, 2022 at 10:58:42PM -0400, Roger Dingledine wrote:
> this change
> means that clients will now choose between two guard relays by default
> (rather than just one) when building circuits.
One of the people on the forum asked if this change applies to bridge
users (including
Hi folks,
As part of the hackweek projects
( https://gitlab.torproject.org/tpo/community/hackweek/ ),
some of us are thinking about simple tweaks we can do to tune the network
to better handle this month's traffic overload.
The long term answer is to try out proposal 327:
