NTP on startup

[Rod Henderson]

How do I get NTP to set time on startup?

The system is a Compaq AlphaServer DS20E 666 Mhz running OpenVMS V8.3

I would like to configure the NTP service such that when it is started it gets the time from the servers listed in the conf file and sets the clock to this time and then proceeds to drift. I believe this can be done for unix systems with a switch on ntpd. Can the equivalent be done for OpenVMS?

If not, then could I run ntpdate on system startup? If so, when and from where should I do it?

Rod

[RBrown_1]

Have you already run SYS$MANAGER:TCP$NTPD_STARTUP.COM? Once you have done that, NTP will always start at system startup.

[Rod Henderson]

The NTP service is running just fine.

What I would like to do is to get the NTP service, at system startup, is to do the equivalant to what ntpdate does, i.e., immediately set the clock to the reference time, no drifting, then continue as drifting from this point.

[Joseph Huber_1]

I can't test it on my system,
but You could try to put
$ mcr TCPIP$NTPDATE host
in TCPIP$NTP_SYSTARTUP.COM
to see if it works at this stage .

[Hoff]

TCP/IP Services NTP starts up and runs automatically just fine and sets the Alpha or VAX or Itanium Integrity system just fine, if the box is configured for it.

Start with the TCP/IP Services manual (or whichever IP stack is in use here), and follow the directions through. This is a several-step process, and (for TCP/IP Services) involves the TCPIP$CONFIG tool (to configure the ntp server) and typically then some manual editing of configuration files (and then typically back into the config tool to start the ntp server). Once configured and running, the ntp server will restart on subsequent reboots.

Do also ensure you have a time server available and running, and not blocked by a firewall or vLAN or such.

Do also ensure that there is no other conflicting time server mechanism. Ensure you have shut off DECnet-Plus DTSS, for instance.

If your system time is sufficiently far off the ntp server value, ntp can punt and reject the time.

As a start here, ensure that ntp is fully configured, that ntp is starting, and that ntp is not detecting a sufficiently skewed time value. ntp can log stuff in its own log file, and you can also use tools including ntpq to troubleshoot the settings.

And as a general rule, I usually prefer to run OpenVMS set to UTC/GMT, rather than dealing with timezone and daylight time settings and other problems. Answering the "yes, we know the time looks wrong" questions is a whole lot easier than dealing with the problems that then arise when the TZ or DST goes weird. Or does what it is supposed to, and derails something.

Here's the high-level overview of the sequence and the files and the settings for TCP/IP Services and setting up the ntp server:

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

And here are the manuals:

http://www.hp.com/go/openvms/doc

[Rod Henderson]

NTP is working fine. It is configured properly, DTSS is disabled, it is getting the time from the servers and everthing is just fine.

All I want to know is what do I need to do to ensure the initial system time is retrieved from an NTP server before the NTP service is started, i.e., I do not want the NTP service to start drifting from the time loaded from the hardware clock at startup.

[Hoff]

This seems to be a high-tech variation of the classic old joke about watches. (If you have one watch, you know what time it is. If you have two watches, you're never quite sure.)

It is typically expected that an ntp server is more accurate than the TOY or (in this case) BB_WATCH; than the console clock.

The specified BB_WATCH accuracy is .005%, circa 130 seconds per month, 26 minutes per year. This per the OpenVMS FAQ. Whether your boxes are in or out of spec is another discussion.

I'd expect that most of the ntp servers available around would provide better accuracy; check the US NIST listings.

If accuracy or synchronization matters here, you'll likely end up with a better local time base; some sort of add-on clock or clock interface. VAX, Alpha and Itanium systems make comparatively bad clocks.

IIRC, the TCP/IP Server doesn't have the hooks needed to connect to a local external time-base (other than the local clock or via ntp and the network), but other ntp-capable boxes do have the ability to connect to a local hardware clock.

And if you need to jump right to the current time rather than the usual drifting, there are ways to do that, too.

[Hoff]

And from the TCP/IP Services manuals (and before you ask), here you go:

"NTP provides several utility programs that help you manage and make changes to the NTP server. These utilities include:

NTPDATE, the date and time utility that sets the local date and time by polling the specified server. Run NTPDATE manually or from the host startup script to set the clock at boot time before NTP starts.

NTPDATE does not set the date if NTP is already running on the same host.

For information about using NTPDATE, see Section B.7.1."

[Joseph Huber_1]

And the manual excerpt cited by Hoff means precisely:
the only place to let NTPDATE set the time is TCPIP$NTP_SYSTARTUP.COM : TCPIP is started, and the NTP server is not yet started (look into TCPIP$NTP_STARTUP to see where systartup is executedL: ntp_systartup executes immediately before enable service ntp).

Now if Rod's concern is to avoid wrong time stamps in certain log files like audit,accounting,errlog, then it is too late, since those start before systartup_vms, which in turn starts tcpip.

[The Brit]

So this is really nothing to do with NTP!

From what you say, you want to set the system time from some external source, BEFORE you start NTP.

The real question is why? Do you expect the system time to be so far off that synchronizing will take too long??

DAve