NTP behaviour changed ? (step or slewing large clock offset)

[Guinaudeau]

I have used NTP version 4.1.0 (actually, TCPIP V5.4 ECO2) to synchronize a VMS Alpha machine. The machine was out of synchronization since a long time due to an incorrect NTP configuration, and its clock offset was about 70 seconds.

I repaired the NTP configuration a few days ago and i observed the following behaviour of NTP : although the clock offset was larger than 128 ms, NTP did not make a STEP but SLEWs continuously it (see the log further). I already noticed this on another machine too.

I read documentation about the NTP protocol and i remembered also another behaviour of NTP in previous versions of OpenVMS : if clock offset small (documentation indicates "below 128 milliseconds"), all time adjustments are
small and smooth ; if clock offset larger ("above 128 milliseconds"), NTP will
quickly make a single STEP change. I remember such a behaviour on previous versions of OpenVMS NTP too.

As someone mentioned in another thread about time synchronization, there are customer applications that are quite allergic to the STEP changes, particularly backward steps. This is an important concern in our application (a SCADA system), and we dont use NTP for this reason on many VMS machines. We dont use DTSS too because the application should keep exact control over the standard time / daylight time change.

I did not find details about this NTP behaviour in the OpenVMS TCPIP documentation. It sounds to me like a change in the behaviour of NTP compared with previous versions. This change should permit us to use the NTP time
synchronization also on machines where our time-sensitive application is running.

My question : could someone confirm this ? will the next versions of OpenVMS NTP behave this way too ?

[JKrucus]

My recollection of using NTP when I needed to reset a clock that was about 2 minutes off, was that it did 10 second corrections every one hour. I was too impatient to wait for it so I reset the clock manually within one second and let NTP do the rest.

On previous versions of NTP it would jump the clock in one step, unless it was 30 minutes or more off, in which case it did not change the time ever. I discovered this after a daylight savings change that did not adjust the TDF offset correctly.

I have had applications that do not tolerate the clock backing up, and for those we manually stopped/started the application for the fall-back time change.

Once NTP gets the clock set it is very good about keeping it accurate. I have not heard of any application time issues, except for fall-back one hour.

[Ian Miller.]

note for the daylight saving time change there is now a system service that can be called so your application is informed about it.

[Guinaudeau]

'On previous versions of NTP it would jump the clock in one step, unless it was 30 minutes or more off, in which case it did not change the time ever. I discovered this after a daylight savings change that
did not adjust the TDF offset correctly.'

I also have seen some jump of several seconds at once with VMS NTP, but it was on older versions. Sounds like VMS NTP would now slew where previousl version steps several seconds.

I read a documentation of NTP for other platforms where there is a compile option for NTP to behave always to SLEW and never to STEP several seconds at once. But I did not read that NTP V4.x will be always SLEW-ing in case of large clock offset.

Question : is this "always SLEW-ing" behaviour a change coming with NTP V4.1.0 by itself (platform indenpendant) [and i missed the correct information about this] or is it a specific behaviour choosen on VMS ?

'I have had applications that do not tolerate the clock backing up, and
for those we manually stopped/started the application for the fall-back time change.'

We have a similar situation : where our time-sensitive application is running, the application is responsible for the standard/daylight time change. Example DAYLIGHT_SAVINGS.COM illustrates a possible way to do this.

louis

[Volker Halle · Accepted solution]

Louis,

there is a reference in the TCPIP V5.4 Relase Notes about NTP and slewing behaviour change between V3 and V4:

3.15 NTP Problems and Restrictions
NTP uses a slew mechanism to synchronize the system clock. The method that NTP uses to obtain a maximum slew value (the maximum amount that NTP will adjust the clock in one attempt) changes when you upgrade from NTP Version 3 to NTP Version 4. As a result of this change, it may take longer for clocks to come into synchronization under NTPv4 than it did under NTPv3.

TCPIP V5.5 comes with NTP V4.2.0 (V5.4 has V4.1.0)

Volker.

[Guinaudeau]

Volker,

i should have a look at release notes first !

I looked at NTP web-site for this version 4 : actually, the release is said to be under development and there is no RFC for it.

It might be an option for the release of NTP version 4 under VMS, and I understand that the new TCPIP release V5.5 (NTP 4.2.0) will behave the same way.

I dont close immediately the thread, could someone add a precision about V5.5 ??? Release notes are not available for now.

louis

[Kris Clippeleyr]

Hi,

TCP/IP 5.5 is available for (and included with) OpenVMS V8.2.
As for the release notes:

The NTP slew mechanism for gradually adjusting a clock has been enhanced to facilitate synchronization for offsets of one second or larger. The maximum slew value (the maximum amount that NTP will adjust the clock in one attempt) has been modified to enable the clock to synchronize more quickly for such offsets. NTP now takes only 20 seconds to correct a one-second offset, compared to approximately 30 minutes for earlier versions of NTP.

For clock offsets that are less than one second, the slew mechanism has not been modified.


Regards,
Kris (aka Qkcl)

[Guinaudeau]

thanks for these informations. that's enough to decide what we can do with NTP.

i am closing now the thread.

louis

[Guinaudeau]

informations were helpfull to decide what we can do with NTP in our case.