* Libertas <liber...@mykolab.com> [2015-01-02 06:25]: > I've tuned PF parameters in the past, but it doesn't seem to be the > issue. My current pfctl and netstat -m outputs suggest that there are > more than enough available resources and no reported failures.
just a sidenote, it is safe to bump the default state limit, very far even on anything semi-modern. the default limit of 10k states is good for workstations and the like or tiny embedded-style deployments. I've gone up to 2M, things get a bit slow if your state table really is that big but everything keeps working. > I remember someone on tor-...@list.nycbug.org suggesting that it could > be at least partially due to PF being slower than other OS's firewalls. I feel offended :) Pretty certainly not. > However, we're now finding that a profusion of gettimeofday() syscalls > may be the issue. It was independently discovered by the operator of > IPredator, the highest-bandwidth Tor relay: > > https://ipredator.se/guide/torserver#performance > > My 800 KB/s exit node had up to 7,000 gettimeofday() calls a second, > along with hundreds of clock_gettime() calls. those aren't all that cheap... -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS. Virtual & Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
