HP OpenVMS Systems

NTP, time, and clock skew?

» close window

The Question is:

 
I have an Alpha running VMS 7.1 and UCX 4.1 which is connected to a radio
clock. I have NTP configured to serve this time onto the network.
 
A number of the clients for this service are running VMS 7.2 and TCPIP 5.0.
 
An example from TCPIP$NTP.LOG follows
 
18 May 17:58:28  synchronized to xxx.xxx.xxx.xxx, stratum=1
18 May 18:21:57  time reset (slew) 0.346648 sec
18 May 18:21:57  synchronization lost
18 May 18:27:17  synchronized to xxx.xxx.xxx.xx, stratum=1
18 May 19:10:00  synchronization lost
18 May 19:11:04  synchronized to xxx.xxx.xxx.xxx, stratum=1
18 May 19:24:36  time reset (slew) -1.352260 sec
18 May 19:24:36  synchronization lost
18 May 19:29:57  synchronized to xxx.xxx.xxx.xxx, stratum=1
18 May 20:07:20  synchronization lost
18 May 20:08:24  synchronized to xxx.xxx.xxx.xxx, stratum=1
18 May 20:21:53  time reset (slew) 1.951375 sec
18 May 20:21:53  synchronization lost
18 May 20:27:13  synchronized to xxx.xxx.xxx.xxx, stratum=1
18 May 22:22:28  time reset (slew) -0.984848 sec
18 May 22:22:28  synchronization lost
18 May 22:27:49  synchronized to xxx.xxx.xxx.xxx, stratum=1
18 May 23:22:03  time reset (slew) -1.014171 sec
18 May 23:22:03  synchronization lost
18 May 23:27:23  synchronized to xxx.xxx.xxx.xxx, stratum=1
19 May 01:07:43  synchronization lost
19 May 01:08:47  synchronized to xxx.xxx.xxx.xxx, stratum=1
19 May 01:22:15  time reset (slew) -2.014119 sec
19 May 01:22:16  synchronization lost
19 May 01:27:36  synchronized to xxx.xxx.xxx.xxx, stratum=1
 
where xxx.xxx.xxx.xxx is the TCP/IP address of the server machine.
 
The radio clock is accessed once per hour to keep the server machine time
accurate. This is done at 4 minutes past the hour so appears to be unrelated
to the NTP client losing sync.
 
What might be causing this?
 
Cheers,
 
Stu.
 

The Answer is :

 
  First, move to TCP/IP Services V4.2 or to V5.0, and apply any available
  ECO kit.  In particular, the version of NTP used in TCP/IP Services
  releases starting at V5.0 is significantly updated from earlier versions.
 
  If the question is in reference to the "synchronization lost", that
  message is normal whenever the system clock drifts more than 128
  milliseconds.
 
  As for the cause of the clock drift, that could be anything from normal
  (thermal) clock variations, a hardware problem, or to the effects of
  unspecified local high-IPL software blocking the processing of clock
  ticks.  (The metal back of a wrist watch is inherently temperature-
  stabilized to roughly 37c, greatly improving the time-keeping abilities
  of the watch.)
 
  The specification for maximum clock drift in the Alpha hardware clock is
  50 ppm, that's less than +/-.000050 seconds of drift per second, less than
  +/-.000050 days of drift per day, or less than +/-.000050 years of drift
  per year, etc.   (eg: An error of one second over a day-long interval is
  roughly 11ppm, or 1000000/(24*60*60).)  The software-maintained system
  time can drift more, primarily due to other system activity.
 
  Additional NTP information is available at:
 
    http://www.eecis.udel.edu/~ntp/
 

  

     

     
answer written or last revised on ( 20-MAY-1999 )
     
» close window