gavdav at gavdav.demon.co.uk
Sat Jul 19 15:36:00 BST 2003
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
>> Yes I don't like it at all - its hard-stepping the clock rather than the
>> You can't use NTPdate to set the time if the daemon is running anyway
19 Jul 15:30:12 ntpdate: 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
>> 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
LOCAL(0) LOCAL(0) 10 l 31 64 377 0.000 0.000
+ntp.demon.co.uk tock.usno.navy. 2 - 436 1024 377 28.648 10.030
-utserv.mcc.ac.u ntp3.ja.net 2 - 394 1024 377 30.907 7.638
*lanczos.maths.t .GPPS. 1 - 239 1024 377 41.051 11.442
-fartein.ifi.uio chronos.cru.fr 2 - 425 1024 377 66.993 9.699
+ntp0.cis.strath swisstime.ee.et 2 - 237 1024 377 31.892 11.630
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.
More information about the Ukfreebsd