NTP Under UCX Questions
nos...@nohost.no.net
We wish to have members of our alpha cluster sync to servers that keep
time via GPS they are already present and being used to keep the time
accurate on Wintel boxes.
I'd like to know if it's possible to set the maximum amount of
difference between the system time and the server time so that UCX does
not change the time if it is greater than the set maximum. I believe
that is referred to as aperture but I haven't seen a means to set this.
Is it also possible to configure UCX so that it does not slew or drift
the clock but makes instaneous corrections to the system time when it
determines that there is a difference?
Thanks.
Hoff Hoffman
:Our setup is a VMS cluster running VMS 7.1 and UCX ver 4.1.
Both of which are ancient. NTP has seen significant upgrades
in more recent TCP/IP Services versions. V5.4 or V5.5 would
be better and more current choices, IIRC. V5.4 and later have
NTP V4 implementations.
:I'd like to know if it's possible to set the maximum amount of
:difference between the system time and the server time so that UCX does
:not change the time if it is greater than the set maximum. I believe
:that is referred to as aperture but I haven't seen a means to set this.
There is no means to set this value. It's hard-coded.
If you want to see the basic NTP code, see the udel reference
implementation of NTP V4. (The FAQ has a pointer.)
:Is it also possible to configure UCX so that it does not slew or drift
:the clock but makes instaneous corrections to the system time when it
:determines that there is a difference?
That's not permissible under NTP. NTP drifts. If you want the
big change, shut off NTP and use ntpdate (IIRC) to reset the
time.
Conversely, twice a year, the calculated time does see a one-hour
change for those political geographies that can and do celebrate
the Daylight Saving Time (DST) "fun". That too is how the standard
says the environment should operate. (NTP doesn't handle the DST
switch-over, that's handled automatically in more recent OpenVMS
versions -- the AUTO_DLIGHT_SAV mechanism is another potential
reason to upgrade from V7.1 to V7.3 or later, obviously.)
The usual reason I've seen these cases are tools or applications
that are using time for a database key or such, but that are not
using UTC.
--
There's a whole new section of UTC calls available in OpenVMS V7.3
and later, see the more current utility routines reference manual
for documentation on the DTSS UTC calls. (The documentation on
these calls is in the V8.2 manuals, as a start.)
--
I'm updating the FAQ section on time and time-keeping as part of
the next edition of the FAQ, in honor of the flood of questions
arising from the recent US Federal legislative DST activities.
---------------------------- #include <rtfaq.h> -----------------------------
For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq
--------------------------- pure personal opinion ---------------------------
Hoff (Stephen) Hoffman OpenVMS Engineering hoff[at]hp.com
Chris
"Hoff Hoffman" <ho...@hp.nospam> wrote in message
news:wc3Re.11425$4P6....@news.cpqcorp.net...
> In article <11h96j3...@corp.supernews.com>, nos...@nohost.no.net
writes:
> :Our setup is a VMS cluster running VMS 7.1 and UCX ver 4.1.
>
> Both of which are ancient. NTP has seen significant upgrades
> in more recent TCP/IP Services versions. V5.4 or V5.5 would
> be better and more current choices, IIRC. V5.4 and later have
> NTP V4 implementations.
>
> :I'd like to know if it's possible to set the maximum amount of
> :difference between the system time and the server time so that UCX does
> :not change the time if it is greater than the set maximum. I believe
> :that is referred to as aperture but I haven't seen a means to set this.
>
> There is no means to set this value. It's hard-coded.
Can be specified if you were using a 3rd party TCP/IP product (eg. TCPware)
(I believe the logical value is called "TCPWARE_NTP_WAYTOOBIG" .... nice
terminology)
>
> If you want to see the basic NTP code, see the udel reference
> implementation of NTP V4. (The FAQ has a pointer.)
>
> :Is it also possible to configure UCX so that it does not slew or drift
> :the clock but makes instaneous corrections to the system time when it
> :determines that there is a difference?
>
> That's not permissible under NTP. NTP drifts. If you want the
> big change, shut off NTP and use ntpdate (IIRC) to reset the
> time.
>
Again slew versus step is configurable with other products (TCPware)
pr...@prep.synonet.com
> I'd like to know if it's possible to set the maximum amount of
> difference between the system time and the server time so that UCX
> does not change the time if it is greater than the set maximum. I
> believe that is referred to as aperture but I haven't seen a means
> to set this.
If you are running ntp, there is a max tiem difference ntp will
continue to run with. Over that, it declares the world bonkers and
exits. It also slews the time by setting the tick rate fast or slow so
time is monotonic and does not have large `holes' from stepping.
VMS really needs a current ntp.
--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
comp.os.vms,- The Older, Grumpier Slashdot
Raw, Cooked or Well-done, it's all half baked.
EPIC, The Architecture of the future, always has been, always will be.
Alex Daniels
news:87irxj4...@prep.synonet.com...
> nos...@nohost.no.net writes:
<SNIP>
>
> VMS really needs a current ntp.
>
The NTP port in TCP/IP Services 5.5 (shipped with V8.2) is based on NTP
4.2.0 (
http://h71000.www7.hp.com/doc/82FINAL/tcprn/TCPIP055_RELEASE_NOTES.PDF ).
NTP 4.2.0 is the current stable release of NTP (
http://ntp.isc.org/bin/view/Main/SoftwareDownloads#Current_versions_of_NTP_Download )
Alex
pr...@prep.synonet.com
> <pr...@prep.synonet.com> wrote in message
>> VMS really needs a current ntp.
> The NTP port in TCP/IP Services 5.5 (shipped with V8.2) is based on
> NTP 4.2.0 (
> http://h71000.www7.hp.com/doc/82FINAL/tcprn/TCPIP055_RELEASE_NOTES.PDF
> ).
> NTP 4.2.0 is the current stable release of NTP (
> http://ntp.isc.org/bin/view/Main/SoftwareDownloads#Current_versions_of_NTP_Download
> )
Yah, thank you TCP group...