NTP won't synch to remote time source.

[Shael Richmond]

I'm pretty sure it's a Windows problem. I had the same issue trying to synch from the company time server(windows). I called support and said nothing was wrong with UCX, it was a windows problem. I changed my ntp to point to the same server the windows server was pointed to and everything has been fine.

[Trevor Phillips]

Regarding it being a windows problem - I should have added earlier that we can get other platforms (a Novell and UNIX system) to obtain the time and successfully set their clocks from the w2k3 server via NTP.

We are a couple of TCPIP ECOs behind on the Alpha system, which I will try and get installed to rule them out.

[Robert_Boyd]

Have you verified that you have the TDF set up properly on the VMS system? If the TDF has not been configured using SYS$MANAGER:UTC$CONFIGURE_TDF or the equivalent procedure on your version of VMS, NTP won't synchronize.

On one system I had this problem. As soon as I properly configured the TDF, NTP started synchronizing within a few minutes.

[Trevor Phillips]

Thanks for the tips so far.

UTC$TIME_SETUP SHOW produced the following:
.
AUTO_DLIGHT_SAV is set to "0"

The Logical name SYS$TIMEZONE_RULE is not defined
The Logical name SYS$TIMEZONE_NAME is not defined
The Logical name SYS$TIMEZONE_DAYLIGHTSAVING is not defined

LOCAL TIME ZONE = GB_EIRE - STANDARD TIME
LOCAL TIME = 22-FEB-05
DIFFERENTIAL FACTOR 0.00
TIMEZONE RULE
.
.
I ran UTC$TIME_SETUP to reset the time zone settings and create the logicals (btw UTC$TIME_SETUP has several entries for GB-EIRE in the main menu - is this a feature?).

Anyway, I played about with setting the timezone and TDF. So far NTP will still not synch. I ran an ntpdate to bring the clock back into line (as it is an operational system and was now 15 secs fast) which worked as expected.

[Robert_Boyd]

From the VMS FAQ:

4.3 Managing Timezones, Timekeeping, UTC, and Daylight Savings?

You will want to use the command procedure:

* SYS$MANAGER:UTC$TIME_SETUP.COM

to configure the OpenVMS Timezone Differential Factor (TDF) on OpenVMS V6.0 and later. Select the BOTH option. This configures the OpenVMS TDF settings, though it may or may not configure the TDF and the timezone rules needed or used by other software packages. Please do NOT directly invoke the following command procedures:

* SYS$MANAGER:UTC$CONFIGURE_TDF.COM ! do not directly use
* SYS$MANAGER:UTC$TIMEZONE_SETUP.COM ! do not directly use

TCP/IP Services V5.0 and later use the OpenVMS TDF, UTC, and timezone support. Earlier versions use a TDF mechanism and timezone database that is internal to the TCP/IP Services package. Also on the earlier versions, the TDF must be manually configured within TCP/IP Services, in addition to the OpenVMS configuration of the TDF.

DECnet-Plus in V7.3 and later uses the OpenVMS TDF, UTC, and timezone support, and displays its timezone prompts using UTC$TIME_SETUP.COM. Earlier versions use a TDF TDF mechanism, timezone database, and automatic switch-over that is internal to the DECnet-Plus package. Also on earlier versions, the TDF must be configured within the DECnet-Plus DECdtss package, in addition to the OpenVMS configuration of the TDF.

Application code using HP C (formerly Compaq C, formerly DEC C) will use the OpenVMS UTC and TDF mechanisms when the C code is compiled on OpenVMS V7.0 and later (and when the macro _VMS_V6_SOURCE is NOT defined). HP C does NOT use the OpenVMS UTC and TDF mechanisms when the C code is compiled on OpenVMS releases prior to V7.0, or when the preprocessor declaration _VMS_V6_SOURCE is declared.

DCE DTS TDF details TDB.

[Trevor Phillips]

Yes, I had read through this after your first post Robert. Unless I am really missing the obvious here everything is set as it should be.

The time is being rejected due to sanity checks - but I am struggling to find out why. I have configured NTP to produce full logs (as to the default basic logs) after making the timezone changes, and will review the results today (and post any interesting points from them).

Any other advice always welcome!
Thanks, Trevor.

[Garry Fruth]

Check out section 2.2 of the following:
http://www.eecis.udel.edu/%7emills/database/status/arpa/arpa95c.pdf

Search for the word Sanity in the following:
http://www.lo0.com/ntp/ntpq.htm
This one explains the flash variable.

Could you attach the full output of the pstatus command?

Also, it would be interesting to see
mc tcpip$ntpq
host w2k3
peers

[Trevor Phillips]

Output to pstatus attached (ip addresses commented out).


I am reviewing the documents referenced - thanks!.

[Garry Fruth]

I don't know why it is not reflected in the flash variable. But it looks like root dispersion is well above 1 second, causing test 8 to fail.

[Trevor Phillips]

Apologies for the delay in replying (was off). Still chasing why dispersion is out so much. Have attached logs from ntp (ntp logging set to maximum). Am reviewing at the moment.