At what difference in time, will NTP give up and stop?

[Clark Powell]

I know that NTP will stop if the difference of time on it's OpenVMS system and the network time standard are greater than a certain delta. What is that delta? Also, is there a way to force NTP to check the delta immediately?

thanks
Clark Powell

[Hoff · Accepted solution]

A better question would be "why are my system times so out of spec?", and that might lead to pointers to ECO kits or such, or to issues with the clock chip, or memory errors or other high-IPL processing that can block interrupts, or whatever might be causing the running time to find itself outside what ntp allows.

A bad ntpd time server can play havoc here and lead to the OpenVMS analog of the more classic ntp WAYTOOBIG error, too.

But to answer the literal question posed, it's called the panic interval, it's 1000 seconds either way by default (per the documentation), and it's selectable through the ntp configuration file.

If you want to be truly mellow about the accepted time, then set the tinker panic value to 0 in the configuration file ("tinker panic 0") for the ntp daemon.

Implementation details vary by TCP/IP stack provider and by the version. The tinker panic knob requires NTP 4 or later, AFAIK.

[Clark Powell]

I have been tinkering with the "tinker panic" number of seconds. One thing that strikes me is how varied and long a time, it takes for NTP to discover that the "tinker panic 60" limit has been passed. Is there a way to speed this process up?
notes:
This line as been added to TCPIP$NTP.CONF
tinker panic 60 # Give up and shutdown NTP if time is over 60 seconds off

[Hoff]

What's the goal here: clock slew, fast convergence, or clock accuracy?

ntp is designed for slow convergence.

The usual way to get ntpd to immediately notice changes in the configuration file is (and I think this is documented) is to restart the daemon.

As for controlling polling and the speed of (hopefully) convergence, see the ntp documentation over at the http://www.ntp.org/ site.

tinker of 60? That value implies a need a local timebase if the configuration can't tolerate a slew minute or so; I'd not look to have ntp punt for that low a skew value. The default value for clock slew is fairly tolerate before ntp punts, which implies you have specific (and unstated) requirements for synchronization.

ntp steps if the time is off by 128 ms or more, and punts entirely if the value is off by 1000 s or more, or by 60 s in this case. This latter value is what you had asked for.

If out by 128 ms or more, the clock will be stepped (with the assistance of the clock information from the drift file) toward the right value.

The max drift per step is around 500 ppm IIRC, so larger skews can take a while for the running time to converge.

If you need faster convergence, some implementations will let you drop maxpoll and minpoll. Some don't honor that. I don't know off-hand if the particular IP stack you're using here allows alternate polling intervals. (This scheme is also sometimes combined with a request to immediately set the clock (right) once on startup, but I've not used that mechanism.)

[Fernando Mühe]

At Multinet, just use the following parameters at NTP.CONF

slewalways
panic 1

The first one will force NTP_SERVER not to step the time, but to slew it instead;

The second one will stop NTP_SERVER if it finds that the time had changed more than the chosen parameter (in seconds).

[]´s
Fernando

[Clark Powell]

My objective is to detect large deviations in OpenVMS system time by using NTP as a trip wire. The assumption is that the NTP servers have the correct time and any difference in the system time from NTP server time is either going to be corrected by NTP or NTP is going to shut itself down if the difference is great enough. I hope to be able to detect the shutdown of NTP in this case and have it trigger operator or programmer intervention. One way would be to have our console works send a page when it sees and OPCOM message from NTP.

The first step in this development is to find out how much variation in time the application running on the OpenVMS system can handle. That should be the panic limit. Beyond that difference, the programmer must intervene and below that difference NTP can handle fixing the problem.

I got started on this bent when "AUTO_DLIGHT_SAV = 1" blew up on me. I started thinking that time is an important quantity and while we are monitoring all sorts of system resources and user demands on our system, we are not monitoring time. So I decided to come up with a scheme to monitor time taking advantage of NTP and it's characteristics.

[Hoff]

ntp itself tosses UTC around, so it seems feasible there's a way within ntp to get into a weird off-by-an-hour state due to DST. (ntp doesn't know about timezones and such.)

If this is sufficiently recent OpenVMS version, there is a notification that can be captured for the DST change. That could be captured by an application. AFAIK, HP doesn't document tapping into the time-change procedure JBC$DST_COMMAND.COM underneath the job controller but it might well be feasible to hang a security audit or security alarm off of the procedure. There are other time-related audits around, too.

Do you have another host around running DECnet? If so, rolling your own time test tool using DCL task-to-task is easy. Basic operations and a f$cvtime call or three and you're good to go. (the xqtype.com tool on the freeware should get you most of the way there.)

I don't tend to use the automatic DST stuff on the production OpenVMS servers I manage. Which means I either go through the semi-annual DST hassles, or I run UTC.

[Fernando Mühe]

Clark, this is exactly my situation. I have a very crictical application that can't handle deviations more than 1 sec. When I set multinet ntp_server panic parameter to 1, it automatically stop itself if it finds a time diff greater than this parameter, and generates an OPCOM message. Very straight forward and very simple. Hope it helps you.

[Volker Halle]

Clark,

I'm using SET AUDIT/AUDIT/ENABLE=TIME to at least audit time and clock changes during DST and other possible manual time changes. This does not audit time changes by NTP though.

Volker.