NTP Problems

[Jefferson Humber]

The company has recently installed an NTP server which I am trying to sync my OpenVMS systems against.

I have used NTPDATE to successfully update the local OpenVMS system to the time server, but trying to maintain sync. with NTP running as a service is causing issues.

I have setup the .CONF file with a single line in for the time server to connect too.

The output I am getting from the NTP service states the following;

11 Mar 16:44:31 ntpd version = 4.1.0
11 Mar 16:44:31 precision = 10000 usec
11 Mar 16:44:32 frequency initialized 0.000 from SYS$SPECIFIC:[TCPIP$NTP]TCPIP$NTP.DRIFT
11 Mar 16:47:51 time slew 158.823000 s
11 Mar 16:48:56 synchronisation lost
11 Mar 17:44:35 offset: 158.823000 sec freq: 0.000 ppm poll: 16 sec error: 0.008735
11 Mar 18:44:36 offset: 158.823000 sec freq: 0.000 ppm poll: 16 sec error: 0.008735

In the example above the local system is off by 158 seconds, since I have started the service the time hasn't been pulled in at all, and is still 158 seconds out ?

This is happening under TCP/IP v.5.4 & 5.3 (Alpha & VAX).

Am I doing something wrong here ?

Thanks in advance,

Jeff

[Robert_Boyd]

Jeff,

Have you gone into TCPIP$CONFIG under Core Environment and done the complete Time Zone setup? That's the 1st thing to check.

You don't mention the steps you've followed to start running NTP, presumably you've enabled the NTP server component as well.

You might post a sanitized version of the .CONF file.

What do you get if you try

$ NTPTRACE

?

Robert

[Jefferson Humber]

Robert,

TCP/IP setup OK.

Timezone logicals as follows (UK).

(LNM$SYSTEM_TABLE)

"SYS$DST_DELTA_TIME" = "ffffeb1b3ab18920"
"SYS$LOCALTIME" = "SYS$SYSROOT:[SYS$ZONEINFO.SYSTEM]GB-EIRE."
"SYS$TIMEZONE_DAYLIGHT_SAVING" = "0"
"SYS$TIMEZONE_DIFFERENTIAL" = "0"
"SYS$TIMEZONE_NAME" = "GMT"
"SYS$TIMEZONE_RULE" = "GMT0BST-1,M3.4.0/01,M10.5.0/02"
"TCPIP$BIND_TIMEOUT" = "...."

NTP started through SYS$MANAGER:TCPIP$NTP_STARTUP.COM

The only lines uncommented in the .CONF file are as follows;

driftfile SYS$SPECIFIC:[TCPIP$NTP]TCPIP$NTP.DRIFT

server 164.137.1.21

The output I get from the NTPTRACE is as follows;

SFFCI5>ntptrace 164.137.1.21
164.137.1.21: stratum 2, offset 1.493902, synch distance 1.00000
gbayls01.gb.batgen.com: stratum 2, offset 1.755818, synch distance 1.00000
gbghls04.gb.batgen.com: stratum 2, offset 1.266054, synch distance 1.00000
xlcrls01.batgen.com: stratum 2, offset -0.097131, synch distance 2.01331
timeserver.my.batgen.com: stratum 1, offset 0.076987, synch distance 0.00000, refid 'GPS'

Could it be something to do with the Stratum level assigned to the timeserver ?

Thanks again in advance,

Jeff

[Kjell Carlsson]

Hello Jeff

Have you tried 'peer 164.137.1.21'
instead of 'server'.

Kjell

[Didier Ravagli]

Hello
Let see if DTSS process is disabled.

[Petr Spisek]

Hi,
I think, NTP doesn't change large difference in the time. Try to set time manualy (approximately) and restart NTP service.
Petr

[Jefferson Humber]

There is no DTSS on the systems.

The manual states anything less than +/- 1000 seconds should be OK.

Am currently trying PEER instead of SERVER in the .CONF file.

However, I have just learnt that the local server is running MS W32Time SNTP. I feel this is the problem, it's not proper NTP. ;-(

Jeff

[Robert_Boyd]

Jeff,

As long as the server and your client are able to agree on the version of NTP they are communicating on they should be fine. The versions supported by TCP/IP 5.4 and 5.3 should be adequate.

One thing you might do is invoke NTPQ and every couple of minutes enter a 'peer' command and an 'assoc' command and track any changes that you see in the output from that over about 30 minutes. It can take quite a while for things to settle down. Eventually it should reach a more or less stable situation. It would be interesting to see what the status looks like at that point.

Within ntpq you might also try the command 'host 164.137.1.21' and then enter the peer and assoc commands and see what kind of output you get.

I was thinking that you might have an issue of security settings -- but from your trace it wouldn't appear that your client is having any trouble talking with the server. The output that you showed from your log shows your NTP client attempting to slew the clock so it was at least one time trying to make an adjustment.