On Sun, 4 Jul 2004, Patrick Welche wrote:

> Upgrading to clock.c 1.84 wasn't enough.. there is serious skew. The 2.0E
> NetBSD boxes are keeping time well, but not the 2.0G ones (very slow).
>
> Thoughts on how to track this down (given that there are no errors, and
> the ntp.conf files haven't changed)?

What platform, and what version of kern_microtime.c? Make sure you
have v1.10. v1.7-1.9 caused the clock to *read* low for periods, even
though the overall timekeeping was not slow.

If not that, you could always try backing out changes selectively,
either kern/kern_microtime.c or i386/isa/clock.c (as applies: many
platforms don't use either of those files).

Also, be sure that it's really frequency skew in the kernel
timekeeping, rather than a serious frequency error with "ntpd", by
stopping the daemon and clearing the frequency correction from the
kernel loop, either with "ntptime -f 0 -o 0 -s 0" or by rebooting
(without starting "ntpd"). You need to rule the problem described
here,

  http://www.ntp.org/ntpfaq/NTP-s-config.htm#Q-COMPAT

before seriously pursuing a kernel issue. (We have the "version 4"
daemon with the "version 3" kernel loop.) Simply put, if the value in
"/var/db/ntp.drift" is way off base, it could take days to straighten
out, even if nothing else is wrong. If that's the only problem, you
just need to manually change it to something close to where it's
supposed to be before starting "ntpd".

By the way, in the NTP project codebase, the daemon loop has been
completely revamped, and it does seem to handle the frequency error
a little better. The daily snapshots should build out of the box on
NetBSD:

  http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/

I think a case could be made for importing a snapshot into the tree,
although it's probably too late for NetBSD 2.0.

Frederick