I asked about the lost synchronization after every reset a couple of years
ago when I turned on NTP. Apparently that's normal. (Personally, I think
if that's an intentional step in the procedure, which is my impression from
what I've read here in the past, the message should be a little different.
This makes it look like something's wrong.)

As for resets not appearing in the NTPDlog, again based on what I've read
here, I think only the resets that are large enough to require a "step"
reset are logged. The "slew" resets don't seem to make it into the NTPD log.

Frankly, if that's all you see in your log, I'm jealous. Here's just a
small section of my NTP log (including the only "reset" entry I've seen
this month):

22 Nov 08:36:42 selected new sync source 192.5.41.40, now at stratum 2
22 Nov 08:39:17 selected new sync source 192.43.244.18, now at stratum 2
22 Nov 08:44:39 lost contact with peer 192.5.41.40
22 Nov 08:53:13 acquired peer 192.5.41.40
22 Nov 09:11:18 selected new sync source 192.5.41.41, now at stratum 2
22 Nov 09:20:50 selected new sync source 192.43.244.18, now at stratum 2
22 Nov 09:24:11 selected new sync source 192.5.41.40, now at stratum 2
22 Nov 09:31:33 selected new sync source 192.43.244.18, now at stratum 2
22 Nov 09:57:42 selected new sync source 192.5.41.41, now at stratum 2
22 Nov 10:00:31 selected new sync source 192.43.244.18, now at stratum 2
22 Nov 10:23:47 lost contact with peer 192.5.41.40
22 Nov 10:31:17 acquired peer 192.5.41.40
22 Nov 11:34:41 selected new sync source 192.5.41.40, now at stratum 2
22 Nov 11:40:02 lost contact with peer 192.43.244.18
22 Nov 11:55:43 selected new sync source 204.87.183.6, now at stratum 3
22 Nov 11:55:46 selected new sync source 192.5.41.40, now at stratum 2
22 Nov 12:13:54 selected new sync source 204.87.183.6, now at stratum 3
22 Nov 12:13:55 selected new sync source 192.5.41.40, now at stratum 2
22 Nov 12:25:41 selected new sync source 192.5.41.41, now at stratum 2
22 Nov 12:29:04 clock reset (via step) -0.320115 sec, clearing.
22 Nov 12:29:04 selected new sync source 204.87.183.6, now at stratum 3
22 Nov 12:29:04 lost all sync peers, free running
22 Nov 12:29:57 acquired peer 204.87.183.6
22 Nov 12:29:58 acquired peer 192.5.41.41
22 Nov 12:34:14 selected new sync source 204.87.183.6, now at stratum 3
22 Nov 12:35:29 selected new sync source 192.5.41.41, now at stratum 2
22 Nov 12:59:56 acquired peer 192.5.41.40
22 Nov 13:08:39 selected new sync source 192.5.41.40, now at stratum 2
22 Nov 13:18:14 selected new sync source 192.5.41.41, now at stratum 2
22 Nov 13:20:25 selected new sync source 204.87.183.6, now at stratum 3
22 Nov 13:20:25 selected new sync source 192.5.41.41, now at stratum 2
22 Nov 13:23:38 selected new sync source 204.87.183.6, now at stratum 3
22 Nov 13:24:42 selected new sync source 192.5.41.41, now at stratum 2
22 Nov 13:31:29 acquired peer 192.43.244.18
22 Nov 13:32:11 selected new sync source 192.5.41.40, now at stratum 2
22 Nov 13:37:01 selected new sync source 192.5.41.41, now at stratum 2
22 Nov 13:38:37 selected new sync source 192.5.41.40, now at stratum 2
22 Nov 13:40:14 selected new sync source 192.5.41.41, now at stratum 2


I assume the format differences are due to the version difference. I'm
still on V4.4 Rev A-X. You'll notice that all those entries occur in just a
5 hour span. This is normal here. I used to obsess about it, wondering why
it kept losing contact and why it kept selecting a new sync source. I
finally gave up. I happens on all four of the VMS boxes I'm running it on,
so I don't think it's a server issue. I referred it to our Networks group
and they couldn't figure out anything on their end. I decided as long as it
works and keeps the clock set, I'll just not worry about it.


> Process Software MultiNet V5.0 Rev A-X, COMPAQ AlphaServer DS20E 666 MHz,
> OpenVMS AXP V7.3-1


> After configuring and starting NTP, the file MULTINET:NTPD.LOG shows like
> this:


> 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 193.204.114.233
> 26-NOV-2004 17:59:29.57 Acquired peer 193.204.114.232
> 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 193.204.114.232
> 29-NOV-2004 11:39:03.52 Acquired peer 193.204.114.233
> 29-NOV-2004 14:14:35.80 time reset 0.252742 s
> 29-NOV-2004 14:14:35.83 synchronisation lost
> 29-NOV-2004 14:14:36.77 Acquired peer 193.204.114.233
> 29-NOV-2004 14:14:39.67 Acquired peer 193.204.114.232
> 29-NOV-2004 15:05:30.03 time reset -0.159782 s
> 29-NOV-2004 15:05:30.08 synchronisation lost
> 29-NOV-2004 15:05:32.96 Acquired peer 193.204.114.233
> 29-NOV-2004 15:05:44.12 Acquired peer 193.204.114.232


> After every "time reset" entry, there is a synchronization lost.
> 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?


> Thank you very much in advance


> --------------------------------------------------------------------------
> Massimo Vitali, System & Network Administrator
> Istituto di Ricerche Farmacologiche MARIO NEGRI (http://www.marionegri.it)
> e-mail: vitali@marionegri.it



--

Tim Calvert
Lead Systems Programmer email: calvert@marshall.edu
Marshall University Phone: (304)696-3210
Huntington, WV FAX: (304)696-3601