Date: Fri, 16 Dec 2005 14:38:52 -0600 From: Alan Amesbury <amesbury@umn.edu> To: freebsd-hackers@freebsd.org Subject: 6-STABLE: HZ>1000, RFC1323 non-compliance, and PF Message-ID: <43A325DC.306@umn.edu>
next in thread | raw e-mail | index | archive | help
On a relatively recently CVSup'ed 6-STABLE box, /sys/i386/conf/NOTES says: # DEVICE_POLLING adds support for mixed interrupt-polling handling # of network device drivers, which has significant benefits in terms # of robustness to overloads and responsivity, as well as permitting # accurate scheduling of the CPU time between kernel network processing # and other activities. The drawback is a moderate (up to 1/HZ seconds) # potential increase in response times. # It is strongly recommended to use HZ=1000 or 2000 with DEVICE_POLLING # to achieve smoother behaviour. # Additionally, you can enable/disable polling at runtime with help of # the ifconfig(8) utility, and select the CPU fraction reserved to # userland with the sysctl variable kern.polling.user_frac # (default 50, range 0..100). Because we have several systems equipped with em(4)-compatible cards that are intended to accept traffic at gigabit speeds, I've configured them with HZ=2000, per the notes above. However, 6-STABLE has also included some newer pf(4) code, which is fundamentally incompatible with a HZ setting this high. I did some digging and eventually came up with this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/61404 The problems we've seen appear to be because FreeBSD boxes with HZ=2000 are picking non-RFC1323-compliant timestamps, which are being discarded by the recently added PAWS code in FreeBSD's implementation of pf(4), which seems to be consistent with the observations made in the discussion linked to by the PR. Since this problem has been known for close to two years, I was wondering if anyone had heard of any progress being made on it The PR includes a patch, but the notes make it look like it's applicable to the 4.x branch, not the newer stuff. It's an issue that definitely affects us, and I suspect we can't be the only ones. So..... Any good news on this? Also, what can I do to assist in terms of testing or otherwise getting this bug fixed? -- Alan Amesbury University of Minnesota
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43A325DC.306>