> From: Massimo Vitali [mailto:vitali@marionegri.it]
> 26-NOV-2004 17:59:15.37 time reset -0.297710 s
> 26-NOV-2004 17:59:15.41 synchronisation lost
> 26-NOV-2004 17:59:18.17 Acquired peer
> 26-NOV-2004 17:59:29.57 Acquired peer
> 29-NOV-2004 11:38:55.85 time reset -0.150629 s
> 29-NOV-2004 11:38:55.89 synchronisation lost
> 29-NOV-2004 11:39:02.56 Acquired peer
> 29-NOV-2004 11:39:03.52 Acquired peer

> After every "time reset" entry, there is a synchronization lost.

This is normal. Once you've changed the local clock you need to re-evaluate
all of the servers and peers again, since you have a new time reference to
base such evaluations on. The code was written by the NTP project folks to
get rid of all of the current state information about each connection, and
to re-establish them from the start so that the old assumptions about what
time it really is won't affect future calculations.

If you want details about how the NTP protocol works, and why things are
done the way they are, you can check out the NTP home page at:
http://www.ntp.org. The documentation is at:

> Moreover, even if "time reset" appears only a few times every day in
> the log file, the actual time set by NTP_SERVER process (as logged
> by AUDIT_SERVER) is done more frequently, about every hour, with
> identical old and new time. Is this the normal behavior?

Yes. When NTPD changes the system time it is actually just changing the
software-maintained time in OpenVMS. Once an hour it will force this time
to be written back to the hardware clock so that if the system goes down the
system time will be closer to correct after reboot, and NTPD will have a
better time estimate to start working from. It doesn't check to see if the
hardware clock time is already up to date, it just sets it to whatever the
software maintained value is.

-- Mike Bartman
Process Software, LLC