Time Sync problem using NTP

[Alpha_1_1]

Hi,

I've been advised of a problem by users of a VMS-hosted application, in that their PC system clocks are being reset by minus one hour when they synchronise with my AlphaServer.

The users run a script that has the command

NET TIME \\POST06 /SET /Y

which displays the current time on the server but also reports it as an hour earlier and sets the incorrect time on the client.

However, when I check the time on the Alpha, it's correct.

The background to this is that several months ago we introduced TCPIP$NTP as our time sync service, replacing DTSS as part of a wider exercise to align the times of all servers on our domain under a common protocol.

I disabled the DTSS service but that didn't prevent it from restarting following a reboot at the weekend, a fact I didn't realise until this morning.

On the client side, PCs syncing with the server have their date/time setting "Automatically adjust for Daylight Savings Time" disabled, and the application admins don't want to have to reset this on 120 clients.

I've disabled DTSS on the server but although it has cleared the conflict announcements in TCPIP$NTP_RUN.LOG it hasn't helped the clients.

The following logicals also appear - should I delete them?

"SYS$LOCALTIME" = "SYS$SYSROOT:[SYS$ZONEINFO.SYSTEM]GB-EIRE."
"SYS$TIMEZONE_DAYLIGHT_SAVING" = "1"
"SYS$TIMEZONE_DIFFERENTIAL" = "3600"
"SYS$TIMEZONE_NAME" = "BST"
"SYS$TIMEZONE_RULE" = "GMT0BST-1,M3.5.0/01,M10.4.0/02"

A copy of the TCPIP$NTP.CONF and TCPIP$NTP_RUN.LOG are attached.

The server is an ES45 running OVMS 7.3-2 and TCPIP 5.4 ECO 6.

I'm reasonably sure the problem lies with the restart of DTSS, but I'd like to be certain. i think ultimately I need to eliminate DTSS entirely from the server...

If anyone's observed this sort of behaviour in the past, I'd appreciate any advice you might have.

Thanks,

Bob

[Joseph Huber_1]

I don't know if it is sufficient, but try to define/system NET$DISABLE_DTSS "1" in sylogicals.com,
then dtss$startup.com should not do anything.

[marsh_1]

hi,

has this issue existed since you moved to BST ?
do the clients have to run the time synch now or was this just historical ?

those logicals are quite normal if you have utc$time_setup to set your local time zone.

fwiw

[Alpha_1_1]

Joseph - thanks. I've added that parameter today and hopefully it will make a difference.

Mark - What I think happened was that we switched on TCPIP$NTP and disabled DTSS but before the most recent DST change at the end of March.

When we rebooted for a patch upgrade yesterday, DTSS must have restarted and reasserted a time setting that forced the clients to set their clocks back an hour.

In any event, I've left the logicals in place and won't be removing them, and the application admins have deployed a fix which appears to have resolved things on the client side.

In the absence of further evidence I'm looking at DTSS as the culprit - it just seems a little bizarre, is all...

Bob

[Hoff]

NTP knows from UTC/GMT only, and the local boxes handle the daylight saving time (DST) offset. NTP does not transmit localtime, only UTC/GMT.

Which tends to imply that either the OpenVMS box has the one-hour-off DST problem, or that the Windows boxes have their own one-hour-off DST configuration problem. The hour-off is due to the arcane and buggy ways that both OpenVMS and Windows deal with system time and with DST, a DST setting error, or due to a lack of current ECO kits for the box (which AFAIK should not be the case with GMT/BST as that's not changed here.)

The one-hour-off stuff has been covered in the OpenVMS FAQ and at the HoffmanLabs site for a while, and you're in the range where some of the values can be a bit wonky if you don't have the ECOs loaded.

As for the DTSS errors in that attachment text file, use the NET$DISABLE_DTSS logical name mentioned earlier. (This arrived via ECO kit on some releases, so - if you don't see it on your current release - then look around for a DECnet-Plus ECO kit.)

On more than a few sites, I've recommended entirely punting this whole time-related morass, and moving to UTC. This means you can be explaining stuff more often, but that you're fixing stuff less often. Neither OpenVMS nor Windows has a particularly robust implementation of timekeeping.

Here's some related reading on how this stuff works:

http://labs.hoffmanlabs.com/node/72
http://labs.hoffmanlabs.com/node/841

The OpenVMS FAQ is here:

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

Pedant note: yes, I know that UTC isn't quite GMT.