CVSROOT: /cvs
Module name: src
Changes by: d...@cvs.openbsd.org 2020/12/16 21:15:03
Modified files:
sys/dev/pci : if_mcx.c
Log message:
rework the maths used to set mbuf timestamps.
there's a comment that explains how it works now, but the result is
that i get much tighter and more consistent synchronisation between
the kernel clock and the values derived from the mcx timestamps
now.
however, i only just worked out that there is still an unresolved
problem where the kernel clock changes how fast it ticks. this
happens when ntpd uses adjtime(2) or adjfreq(2) to try and make the
kernel tick at the same rate as the rest of the universe (well, the
small bit of it that it can observe). these adjustments to the
kernel clock immediately skew the timestamps that mcx calculates,
but then it also throws off the mcx calibration calculations that
run every 30 seconds. the offsets calculated in the next calibration
period are often (very) negative.
eg, when things are synced up nicely and you do a read of the mcx
timer and immediately follow it with a nanouptime(9) call, on this
box it calculates that the time in between those two events is about
2600ns. in the calibration period after ntpd did a very small adjtime
call, it now thinks the time between those two events is -700000ns.
this is a pretty obvious problem in hindsight. i can't think of a
simple solution to it at the moment though so i'm going to leave
mcx timestamping disabled for now.
