NTP Configuration and Use

[fabiomacabu]

Hi All,

I have an Alphaserver running OpenVMS 7.2-2 and TCPIP Services v 5.1. I´m trying to do a time synchronization with a GPS with a builtin NTP server. So I execute following steps:

1) Configure Host

TCPIP> SET HOST GPS_TEST /ADD=140.0.194.15/ALIAS="gps_test"

2) Configure TCPIP$NTP.CONF

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

3) Run @sys$startup:TCPIP$NTP_STARTUP

The process is running, but nothing happens... I tried following:

A) $ ntpdate -q 140.0.194.15
Socket bind error.
Verify that the NTP server (TCPIP$NTP) is not running on this host.
%SYSTEM-F-DUPLNAM, duplicate name

B) $ ntptrace gps_test
GPS_TEST: *Timeout*

C) $ ntpq -n

ntpq> peer
remote refid st t when poll reach delay offset disp
==============================================================================
140.0.194.15 0.0.0.0 16 u - 64 0 0.00 0.000 16000.0
ntpq>
ntpq> associations
ind assID status conf reach auth condition last_event cnt
===========================================================
1 13028 8000 yes no

I don´t know what is happening. Actually the gps synchronize other two Windows machines. Can anyone help to solve this problem?

Thanks in advance, Fabio

[Hoff · Accepted solution]

Is TCPIP$NTP.CONF configured and correct?

AskHL: Configuring NTP On OpenVMS:

http://labs.hoffmanlabs.com/node/1280

Restrictions and details on ntpdate are there, too.

Also get and load the "current" TCP/IP Services patch for V5.1, too.

[Andy Bustamante]

You're using an older out of date version of the operating system and TCPIP. I'm sure you know that and there are reasons.

I believe you need to shut down ntp services (@sys$startup:tcpip$ntp_shutdown) to use the ntpq utility. Your error message:

>>>Verify that the NTP server (TCPIP$NTP) is not running on this host.

points to this as well.

The logs for ntp are in SYS$SPECIFIC:[TCPIP$NTP], the name of the log changed between versions. Also, there is an issue with older releases where the log file when ntp is started remains open. This can be a problem with purging. I believe this was first corrrected in an ECO for TCPIP 5.4.

[Andy Bustamante]

And of course use

@sys$startup:tcpip$ntp_startup

to restart ntp when you've completed your debugging.

You should confirm your time zone settings as well. Hoff may have a more current entry but start with http://labs.hoffmanlabs.com/node/72

[Bob Blunt]

You have to have TCPIP$NTP.CONF setup properly. There are examples in the template in SYS$SYSPECIFIC:[TCPIP$NTP]. Add your GPS NTP server into the list as those examples show and it's always good to have some backup sources just in case your local source goes away for some reason. Once you have your local server properly added to the file you should stop and restart NTP to connect to your source(s). The logfile, usually either TCPIP$NTP_RUN.LOG or TCPIP$NTP.LOG may not show "immediate" activity, you might have to wait fifteen or so minutes for the first log entries to accumulate.

There are several information sources on the Internet for NTP, most seem to be (I think) at the University of Delaware. You should be able to find troubleshooting information for the various NTP tools and utilities there. Some of those should give you a better idea what the output means. The real key for NTP on OpenVMS (even for the antique versions) is getting the .CONF file setup properly and starting the NTP service using that file. Unless, of course, you have reachability problems between the OpenVMS system and the GPS source.

[Aaron Sakovich]

Andy said:

"I believe you need to shut down ntp services (@sys$startup:tcpip$ntp_shutdown) to use the ntpq utility."

Actually, it's when you use ntpdate that the NTP server must be shutdown, because ntpdate can be used to "manually" set the system time. ntpq is just for querying.

Just because an NTP server or client works with a Windows system does not mean that it will work with other systems that adhere to industry standards. Microsoft decided in their infinite wisdom NOT to adhere to the RFC spec, and used TCP instead of UDP for NTP traffic. I've seen several firewall appliances that do not take this into account, and must have custom rules crafted to allow Windows NTP traffic to pass. If there's a firewall or even a router in between you and the GPS or Windows systems, there is a distinct possibility that you may not be able to see it.

Do check your logs as Bob suggested; these should have some good clues. If necessary, you can set the logical TCPIP$NTP_LOG_LEVEL/System anywheres from 1 to 6 to increase the verbosity in the logs. Restart NTP after changing this logical.

HTH

[fabiomacabu]

Thanks for all!!