NTP sync issues

[Steven P Underwood]

NTPQ is one of the reasons I think it is not reading the config files: NOAH is the VAx, MOSES is the Alpha with the issue.

CSW-on-NOAH->ntpq -p
remote refid st t when poll reach delay offset disp
==============================================================================
*DC1 timekeeper.isi. 2 u 11 64 377 0.00 -14.224 9.14
+DC2 DC1 3 u 14 64 377 0.00 -27.298 8.33
MOSES 0.0.0.0 16 u 38 1024 0 0.00 0.000 16000.0
CSW-on-NOAH->ntptrace
LOCALHOST: stratum 3, offset 0.005000, synch distance 0.19643
DC1: stratum 2, offset -0.008523, synch distance 0.15201
timekeeper.isi.edu: stratum 1, offset -0.012773, synch distance 0.00000, refid '
GPS'
CSW-on-NOAH->

SYSMGR-on-MOSES->ntpq -p
No association ID's returned
SYSMGR-on-MOSES->ntptrace
LOCALHOST: stratum 16, offset -0.000416, synch distance 1.11162
0.0.0.0: *Timeout*
SYSMGR-on-MOSES->

[Bill Hall]

Steven,

Are you sure the Alpha's conf file can be read by the TCPIP$NTP account? Do you have a homogeneous cluster?

Bill

[Hoff]

Does the Windows box have a real NTP server, or does it have the (simple) SNTP server? Most Windows boxes I've dealt with use an SNTP infrastructure, and NTP (on any platform) doesn't like to sync to SNTP. SNTP can sync to NTP, but the other way doesn't work so well. (There was a very scathing posting from an NTP expert a while back, blasting the problems with W32TIME service; the versions of SNTP found prior to Windows XP were very flaky. At best. More recently, the synch does occur though within the SNTP limits, which is some seconds of skew-age, IIRC. NTP is tighter.)

There exists a list of public NTP servers here:
http://support.ntp.org/bin/view/Servers/WebHome

Check the local (SYS$SPECIFIC:) roots for differences in the ntp.conf file.

In a cluster, you can (also) use SET TIME/CLUSTER (which was undocumented for a while, but it's back) to zonk the time cluster-wide. That written, the usual approach is to run NTP across the hosts.

In the immediate case, the first thing I'd check is the TCP/IP Services version. V5.0A is old and pretty crufty. If you can't upgrade that version to a more current one, do apply the most current ECO for V5.0A.

Patch (ECO) FAQ:
http://64.223.189.234/node/348

Why the Alpha isn't picking up the file implies that NTP client is shut down, or is not finding the ntp.conf file you think it is, it cannot connect to the time provider, or the ntpd daemon is malfunctioning.

Longer-duration information on the run log would be interesting. It can take a very long time for the serves to synchronize. At least a couple of hours run, and mayhap a day.

On the server line, I'd probably add "minpoll 12 maxpoll 17" (very conservative, 6 and 12 is significantly more aggressive), or "burst minpoll 12 maxpoll 17", or iburst onto the time server definition lines in your ntp.conf file.

I don't know off-hand if V5.0A has an ntp which support burst or iburst. (The current stuff does have this.)

And for a question you might get to: NTP doesn't do daylight saving time (DST), and you're too far back (or not far enough back) to have the most recent timezone definitions. You'll be rolling your own update here, if you need to track the US changes. OpenVMS TZ and DST details are here:

http://64.223.189.234/node/72

Stephen Hoffman
HoffmanLabs LLC

[EdgarZamora · Accepted solution]

A couple of suggestions:

Increase your log level by defining a systemwide logical TCPIP$NTP_LOG_LEVEL 6 then restarting ntp. That should give you more information in the log file.

Secondly, the config file comment mentions that the hostnames should be fully qualified. You might want to try that just to get that out of the way (I know it works on the VAX with just using the alias but you never know). Change the dc1 and dc2 to fully qualified names.

Good luck and please post the log file results.

[Steven P Underwood]

Thank you all... It appears to be the alias as mentioned in the last post. All these hosts are in the local hosts table on the server, but entering the IP address seems to have gotten it working. I did raise the LOG_LEVEL to keep a closer eye on it for a while.

To answer the other questions...
DC1 and DC2 are Win2003 servers which are allowed out to the internet (not my decision).
I was trying to get away from the manual $ SET TIME/CLUSTER needed every night.
I know these are old versions, but the config is frozen, I'm told because of the COBOL version being used and an unwillingness to recompile all the code. If I could not get it running, it was going to need to stay manual :(
DST change is handled via a batch queue job.

Again, thanks.

[Steven P Underwood]

Closing thread, Details in the previous post.

[EdgarZamora]

Make sure you turn off or lower the log level as the log file will get quite large.