topic Re: NTP and Alpha Hardware Clock in Operating System - OpenVMS

NTP and Alpha Hardware Clock

Rod Henderson — Fri, 24 Apr 2009 18:22:58 GMT

Does NTP update the hardware clock on an Alpha?

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

I assume on startup, the system time is set by a battery powered hardware clock. With the system time being disciplined by NTP, is the hardware clock automatic set to the system time? Maybe this is only done on system shutdown.

Re: NTP and Alpha Hardware Clock

Hoff — Fri, 24 Apr 2009 19:44:12 GMT

The SHUTDOWN.COM shutdown procedure does set the saved time with a SET TIME command.

Re: NTP and Alpha Hardware Clock

Rod Henderson — Fri, 24 Apr 2009 20:37:59 GMT

I was not searching right directories. I now have found the correct file and the set time statement.

Now the next question: Does NTP do this periodically? My only concern is when we get a non-graceful system shutdown, ie crash after he machine has been running for a couple of months.

Re: NTP and Alpha Hardware Clock

Hoff — Fri, 24 Apr 2009 20:52:44 GMT

AFAIK, no.

Neither the TCP/IP Services ntp server nor DECnet-Plus DTSS touch the TOY or the BB_WATCH in any fashion.

This same basic case was at the core of the yearly "fun" with some obscure VAX TOY clock "maintenance" requirements:

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

Re: NTP and Alpha Hardware Clock

Rod Henderson — Fri, 24 Apr 2009 20:59:13 GMT

Thanks.

Re: NTP and Alpha Hardware Clock

Rod Henderson — Fri, 24 Apr 2009 21:00:55 GMT

Looks like I have to rely on SHUTDOWN.COM

Re: NTP and Alpha Hardware Clock

RBrown_1 — Sat, 25 Apr 2009 00:24:06 GMT

Why not create a periodic batch job that does $ SET TIME ?

Re: NTP and Alpha Hardware Clock

Hoff — Sat, 25 Apr 2009 00:31:26 GMT

The batch job (or most any scheduling package) will most certainly work, but this looks to be the reverse-case at the core; the BB_WATCH is almost certainly going to drift away from the values returned by the ntp servers (and I trust the ntp servers more), so using ntpdate at boot-time (entirely possible, but not exactly cleanly due to the way the TCP/IP Services startup is sequenced) to synchronize the running system time with the ntp server before launching would seem the most efficient approach.

The one wildcard here is whether TCP/IP Services does this quick-synch with ntpdate itself; I haven't looked in detail. Based on a quick search, it doesn't. Or it doesn't seem to do this using ntpdate.

There may well be some other mechanism(s) that can be used here.

And yes, the periodic SET TIME does address other issues.