Hello again DU admins,
I wish to thank Dan Riley (dsr_at_mail.lns.cornell.edu), who replied to my
query shortly after I produced my first summary. Dan's message sheds
important new light on the subject, so I had to share it with this list
in the form of a summary addenda.
Here is Dan's reply in its entirety:
No one quite pinned the tail on the timekeeper on this one, so let me
add a few things. First, you need to realize that there are two
levels of activity--one is ntpd itself synchronizing to an external
timekeeper, and the second is ntpd adjusting the time of the localhost
to match that time.
> the syslog's daemon.log file of repeated message like "xntpd [3074]:
> Previous time adjustment didn't complete".
This message means that the call to the adjtime system call that
corrects the clock on the local system returned a non-zero value for
the amount of time still to be corrected from the previous call--it
means that, for some reason, the kernel did not finish applying the
previous correction to the local time. This is strictly a local
event; connectivity or synchronization to the external timekeeper has
nothing to do with it.
Operationally, we seem to see these most frequently when the system is
under a heavy interrupt load--lots of disk and network activity--but I
don't know what the detailed cause is. It may indicate a load problem
on the system, but it usually isn't all that detrimental to accurate
timekeeping.
> It seems like xntpd is at
> times (no pun intended!) unable to maintain synchronization with the
> router's clock. Is this message type normal in the operation of the
> xntpd daemon? Sometimes, I'm also seeing messages indicating that the
> synchronization actually succeeds: "xntpd[3074]: synchronized to
> nn.nn.nn.nn, stratum=3".
The "synchronized to nn.nn.nn.nn" message is logged when ntpd changes
the time source it is synchronizing to. It doesn't mean that the
local clock is actually successfully synchronized--it is strictly an
issue between xntpd and the time source. If you synchronize to just
the one Cisco, these probably mean that your system is, for some
reason, losing synchronization with the router, and there should be
additional peer events syslogged (probably with incomprehensible hex
status codes--later versions of xntpd print more intelligible
messages). xntpd is fairly tolerant of interruptions as long as it
does get to synchronize now and then (though this depends on what kind
of tolerance you are aiming for). I'd suggest getting familiar with
xntpdc, starting with "xntpdc -p", to get a better feel for how well
your system is synchronizing.
The occasional loss of synchronization would worry me some, unless you
already know the path to the router loses packets (which would still
worry me, but worrying about our network is part of my job).
--
Dan Riley
dsr_at_mail.lns.cornell.edu
Wilson Lab, Cornell University
<URL:http://www.lns.cornell.edu/~dsr/>
"History teaches us that days like this are best spent in bed"
--
Charles Vachon -- Administrateur de systhme
Fonds de la Riforme Cadastrale du Quibec
Ministhre des Ressources Naturelles du Quibec
cvachon2_at_mrn.gouv.qc.ca -- (418) 627-6355 x2760
Received on Mon Nov 02 1998 - 15:33:36 NZDT