How can I tell if UCX NTP is working?

[Jeremy Begg]

An occasional customer is running a CI VMScluster of 7 VAXes with VMS 7.1 and UCX 4.2 ECO 4.

(And please don't tell me they need to upgrade!)

This customer is having problems with the system clocks not staying in synch so I suggested we enable NTP, and they have asked me to do so.

I used UCX$CONFIG.COM to enable the service on one node (for initial testing), and I've created SYS$SPECIFIC:[UCX$NTP]UCX$NTP.CONF with two 'server' hosts specified in it, one at a local Uni and the other at a major ISP.

I ran @SYS$MANAGER:UCX$NTPD_STARTUP.COM to start the server and it is running.  But I have no idea if it's doing anything.  The log file contains only two lines:

$ type sys$specific:[ucx$ntp]ucx$ntpd.log
* Timezone Differential Factor is 36000
* basetime: NTS offset is 1258984800.000000
$

Those lines were written as soon as the server started, about 3 hours ago, and nothing has been written since.  I was hoping to see messages about it acquiring one or both servers, or maybe an error.

The timezone differential isn't actually correct for this site - it should be 39600 - would that be preventing it locking on to the NTP servers?  (Like I said, this is an 'occasional' customer - I only get involved on the infrequent occasions they want something done to their system.)

Also, what does the phrase 'NTS offset' mean?  I.e. what is it an offset from, and what are the units?

Thanks,

Jeremy Begg

[Volker Halle · Accepted solution]

Jeremy,

NTP handles time in UTC, so a wrong TDF can prevent synchronization.

There seem to be no NTP-related 'tools' (like NTPDATE or NTPQ) available with UCX V4.2, so troubleshooting this is somewhere between very hard and impossible.

Can you 'trace' communication to the NTP servers ? Does the IP communication work at all (no firewalls inbetween) ?

I just tried this with UCX V4.2 ECO 1:

- looks like you need to specify IP addresses in UCX$NTP.CONF - not IP names - in the 'peer' statement

- $ TCPIPTRACE ip-address-of-NTP-server shows some packets being exchanged to/from port 123

And after waiting about 5 minutes, I see this:

VAXVMS $ ty UCX$NTPD.LOG
* Timezone Differential Factor is 3600
* basetime: NTS offset is 1259017200.000000
* acquired peer 192.53.103.108
* selected new sync source 192.53.103.108, now at stratum 2
 13:18:07.97    -1.055446 seconds, trip 0.1800, aperture 1.0554, hold 4
 13:18:18.05    -1.058984 seconds, trip 0.1700, aperture 1.0554, hold 3
 13:19:22.09    -1.075287 seconds, trip 0.2000, aperture 1.0554, hold 2
 13:20:26.11    -1.082228 seconds, trip 0.2100, aperture 1.0554, hold 1
 13:21:30.12    -1.080820 seconds, trip 0.2100, aperture 1.0554, hold 0
 13:22:34.28    -1.106609 seconds, filtered, aperture 1.055446

After some more minutes:

 13:23:38.38    -1.082428 seconds, new tick  98282 for 62 seconds
 13:24:42.25    -0.004172 seconds, new tick  99999 for 59 seconds
 13:25:46.24    +0.007422 seconds, new tick 100001 for 107 seconds
 13:27:54.25    +0.023974 seconds, discarded, trip > 0.098992

So it looks like it might actually work...

Volker.

[Bob Blunt]

Jeremy, typical NTP question...  Basically it IS working from the standpoint that it started, detected that the offset was too big to adjust and it stopped trying.  There isn't any easy way to say this but UCX 4.1 NTP is pretty primitive.  It can get the job done but the main loss is that you haven't got as many tools in your case as you might with a newer release.  So if you want to interpret that as a knee-jerk "you HAVE to upgrade" so be it, it isn't.

Look in SYS$MANAGER for UCX* command procedures.  I hope that there is one you can use there that has some UCX-friendly symbols including tools you can use to test NTP's connections to your "higher" stratum sources of time information.  V4.1 is old enough I can't remember what the command procedure is called (if it exists at all).  It MAY be UCX$DEFINE_COMMANDS or something similar.  Type it out and look for symbols that start with NTP* and, I hope, there should be one that you can use to verify your connection.

When NTP gets in this condition, in my experience, it usually leaves an error somewhere that tells you more clearly that the time is too far off from the "base" to adjust back into synch.  So you need to make sure that the time and offsets are set correctly and the system time is less than an hour out of whack so NTP can do it's thing.  As far as *what* the differential means?  The difference between your system time and, usually, your time source and NTP thinks this is too big to even try.  The units?  I'll be honest, I'm not 100% sure, but I think that they're VMS 'ticks?'  1/100 of a second?  The value you're seeing seems gigantic but without knowing more about your system time, etc, all I can say is that the time difference seems really huge and NTP will never even try to fix that.  If I remember NTP doesn't really like to see big time differences like when DST starts or ends so even an hour may be considered too large a difference to drift.

If you can't find anything else online about UCX' NTP implementation you might just google and check out the websites at the University of Delaware where NTP was developed.  Their info might give more details about what the offset means.

bob

[Jeremy Begg]

Thanks Volker, specifying the NTP servers by IP address rather than name did the trick!

I have re-read the documentation and it says, "8.2.1 Creating the Configuration File [...] add the names of the participating hosts ..." but the examples all use IP addresses rather than names.

As suspected, the incorrect TDF was about to cause a problem: NTP acquired the synch source and decided the offset was -3530 seconds.  If I had let it run it would probably have made a 1-hour adjustment to the system time. (From memory the default NTP threshold is 4000 seconds.)

So after shutting down NTP, setting the correct TDF and restarting NTP the log now shows this:

* Timezone Differential Factor is 39600
* basetime: NTS offset is 1259067600.000000
* acquired server 192.231.203.132
* selected new sync source 192.231.203.132, now at stratum 3
 10:48:33.47   +72.675141 seconds, trip 0.1600, aperture 72.6751, hold 4
 10:48:43.51   +72.679432 seconds, trip 0.1400, aperture 72.6751, hold 3
 10:49:47.54   +72.665653 seconds, trip 0.1700, aperture 72.6657, hold 2
 10:50:51.50   +72.685423 seconds, trip 0.1300, aperture 72.6657, hold 1
 10:51:55.60   +72.685632 seconds, trip 0.1300, aperture 72.6657, hold 0
 10:52:59.61   +72.680754 seconds, filtered, aperture 72.665653

 10:54:03.63   +72.686162 seconds, clock step/set

* clock reset ~+72.686 sec by something, clearing.
* Timezone Differential Factor is 39600
* basetime: NTS offset is 1259067600.000000
* re-acquired server 192.231.203.132
* selected new sync source 192.231.203.132, now at stratum 3
 10:56:21.42    -0.070023 seconds, trip 0.2700, aperture 0.0700, hold 4
 10:56:31.47    -0.010319 seconds, trip 0.1500, aperture 0.0103, hold 3

 10:57:35.45    +0.000492 seconds, trip 0.1300, aperture 0.0105, hold 2
 10:58:39.46    -0.004643 seconds, trip 0.1400, aperture 0.0146, hold 1
 10:59:43.47    -0.009398 seconds, trip 0.1500, aperture 0.0194, hold 0
 11:00:47.47    -0.009316 seconds, new tick  99998 for 63 seconds
 11:01:51.49    +0.003706 seconds, new tick 100001 for 53 seconds

 11:02:55.47    -0.002870 seconds, new tick  99999 for 41 seconds

So far so good, I'll go and configure the other cluster members.

Regards,

Jeremy Begg