dillon at apollo.backplane.com
Fri May 11 22:03:26 UTC 2007
Another idea to help track down timebase problems. Port dntpd to
FreeBSD. You need like three sysctls (because the ntp API and the
original sysctl API are both insufficient). Alternatively you could
probably hack dntpd to run in debug mode without having to implement
any new sysctls, as long as you be sure to clean out any active
kernel timebase adjustments in the kernel before you run it.
Here's some sample output:
Dntpd in debug mode will print out the results from two staggered
continuously running linear regressions (resets after 30 samples,
staggered by 15 samples).
For anyone who understands how linear regressions work, finding kernel
timekeeping bugs is really easy with this sort of output. You get the
slope, y-intercept, correlation, and standard deviation, and then you
get calculated frequency drift and time offset based on those numbers.
The correlation is accurate after around 10 samples. Note that
frequency drift calculations require longer intervals to get better
results. The forced 30 second interval set in the sample output is
way too short, hence the errors (it has to be in 90th percentile to
even have a chance of producing a reasonable PPM calculation). But
also remember we are talking parts per million here.
If you throw away iteration numbers < 15 or so you will get very nice
output and kernel bugs will show up in fairly short order. Kernel
bugs will show up as non-trivial y-intercept calculations over
multiple samples, large jumps in the offset, inability to get a good
correlation (provisio: sample interval has to be at least 120 seconds,
not the 30 in my example), and so on and so forth.
Also be sure to use a locked ntp source, otherwise running corrections on
the source will show up as problems in the debug output. ntp.pool.org
is usually good enough. It's fun checking various time sources with
an idle box with a good timebase. hhahahhaha. OMG.
<dillon at backplane.com>
More information about the freebsd-stable