NTP problems

[Gavin Davenport]

Where does this pernicious idea that running ntpdate(8) out of cron is
such a good way to keep a clock in synch come from?  It isn't much
good at all -- the only time it was ever worth doing is when the
client machine was behind a dialup link and it was more important to
control when the line was bought up than it was to keep the clock in
synch.

>> Yes I don't like it at all - its hard-stepping the clock rather than the
gradual drift.
>> You can't use NTPdate to set the time if the daemon is running anyway
i.e.:

19 Jul 15:30:12 ntpdate[47153]: the NTP socket is in use, exiting

ntpd(8) automatically checks against the remote servers at intervals,
which it can change as required.  It also knows how to compare the
trend in recorded time of day of the local clock against the network
time.  That means that it sets the clock to run faster or slower and
so come into line, rather than jumping the clock to whatever happens
to be the correct time at that instant, and never mind that the local
clock is running at 55 minutes to the hour.

All of this takes time: you need to allow ntpd(8) at least 24h and
preferably longer before you can tell if it is managing to keep your
clock properly in synch.  Add the line:

>>I have a drift file defined and it exists - its current contents is:
jeeves# more /usr/local/etc/ntp.drift
73.416
>> the package provided standard startup file (/etc/rc.d/ntpd) does exactly
as you describe, it parses for the first server entry, ntpdates the clock on
system boot and then starts the daemon.

Regarding my (local) NTP server - thats perfectly well behaved and is synced
to a load of NTP servers.
[root at ponsonby root]# ntpq -p
     remote           refid      st t when poll reach   delay   offset
jitter
============================================================================
==
 LOCAL(0)        LOCAL(0)        10 l   31   64  377    0.000    0.000
0.008
+ntp.demon.co.uk tock.usno.navy.  2 -  436 1024  377   28.648   10.030
3.658
-utserv.mcc.ac.u ntp3.ja.net      2 -  394 1024  377   30.907    7.638
2.957
*lanczos.maths.t .GPPS.           1 -  239 1024  377   41.051   11.442
0.661
-fartein.ifi.uio chronos.cru.fr   2 -  425 1024  377   66.993    9.699
0.652
+ntp0.cis.strath swisstime.ee.et  2 -  237 1024  377   31.892   11.630
2.30

I tried leaving it on just the daemon (rather than NO daemon and using cron)
and within 3-4 days its a whole day ahead. My weekly sunday log rotations
happened last night sometime.

I admit it could well now be a hardware issue - but I'm curious as it there
is anything in 'mergmaster' (following cvsup and a make world and make
buildkernel) which have required extra attention since I upgraded the OS and
kernel. It worked prefectly well _before_ I upgraded.

It just remarkable - I don't think I've ever seen a machine gain or loose so
much time. Grrrrrrrrrrrrr.

Rebuilding with debug now.

Thanks,

Gavs