6-STABLE: HZ>1000, RFC1323 non-compliance, and PF

Alan Amesbury amesbury at umn.edu
Fri Dec 16 12:38:58 PST 2005


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


More information about the freebsd-hackers mailing list