Re: Which release notes say sts$manager:utc$configure_tdf is obsolete

From: John Santos (john_at_egh.com)
Date: 04/07/05 

Date: Thu, 07 Apr 2005 08:12:43 GMT

JF Mezei wrote:
> John Santos wrote:
>
>>in UTC, and after comparing it to the time as determined from its
>>servers, to fudge the time slightly forward or back.
>
>
> Fudge ? Wouldn't NTP simply set the time ? I think that it has something
> about not handling large time differences and doing so in maximum
> increments until the time difference is small enough that a final
> adjustment is made.

Well, ultimately something has to do a $SETIME to change the system
clock, but NTP is probably using unix system services (in UTC) to
do it, and is relying on the C I/O library or some library that is
part of the TCP/IP package to do it. That's why I said "fudge".

I think it will only attempt to change the clock if it is less than
a few thousand seconds off (3600 seconds = 1 hour, I don't remember
if the maximum discrepancy is deliberately less than an hour to
prevent it from trying to fix DST, or a little more than an hour,
so it can fix the clock if the system manager set the clock wrong
at boot time because he was using a DST watch after DST had ended
or a ST clock just after the spring forward, and NTP would fix it.

It does it by changing the clock in small intervals until it gets
close, and then by smaller intervals until it gets closer, but I
don't know the actual algorithm. I've also heard it described as
making the clock run fast (if it is behind) or slow (if it is
ahead), rather than jumping the clock. Maybe some systems can do
this in their clock service, and it gets emulated on others.
(Like tell the clock service routine to skip one tick in every
60 until it has skipped 150 seconds worth of ticks, if it is
running 150 seconds fast, or count 2 ticks instead of 1 tick once
every n ticks until it has advanced by 35.6 seconds if it is 35.6
seconds slow, and really do this if the clock service is capable
of it, but instead emulate this by adjusting the clock forward or
back by a few milliseconds several thousand times if that's the
way you have to do it.) Anyway, this is all speculation about
mechanisms... NTP slowly skews the system clock to match its best
guess of the real time that it makes from polling the time server.
(It uses the average round-trip response time to guess how old
the server's response was when it got it, so it can really get
pretty accurate.)

> However, on other machines I have which are NTP aware, I just tell it to
> check against the NTP server once a day or at boot time.
>

A program I downloaded from NIST many years ago for my PC does that.
It just checks in at boot time and about once a day. Whether this
is good enough depends on how accurate your timing needs are, and
how good the clock in your system is. I remember our VAX 11/780
was much worse than all our PDP11's, which had LTCs and were always
within a second, provided you set them correctly at boot time. The
VAX would drift several minutes a month.

> Is there really a point in having NTP run continuously ?

Some apps really care about an accurate clock. I think Kerberos
is one of them. (TCPWare won't let you enable its Kerberos client
unless you also have NTP enabled.)

> I just do a NTPDAT once a week. I don't like to clutter SHOW SYSTEM with
> processes that hang around doing nothing all week.
>

Good enough for jazz. ;-)

>
>>Given all above, for the first time in living memory, all my systems
>>(VAX V7.3 and V7.1, Alpha V7.3-1 and V7.3-2, Macs, Unices (mostly
>>Solaris and Linux, but one DEC Unix Alpha), PC's, Tivo, cell phones,
>>etc. at home, work, customer sites (4 timezones) seem to have survived
>>a DST change without any problems last Sunday.
>
>
> Out of curiosity, how do large networks handle setting clocks on all
> their routers during the time changes ? Are the CISCO routers smart
> enough to have the logic to determine the actual date/time of time
> changes each year ? Or must the network managers tell each router at
> what date/time to make the change ?
>

I doubt the routers care one whit about the time changes. Maybe if
they are fancy enough, you can tell them what time zone (and timezone
rule) to use, and so they can display local time in there status
screens, error reports, etc. but for routing, they don't care about
the time at all, and if they are also local NTP servers, they just
sync with a lower tier NTP server. NTP is all in UTC.

(Just in case someone doesn't know this and is confused by my
constant harping on UTC, UTC is Universal Coordinated Time
(French acronym, maybe?) and is the modern successor to GMT
- Greenwich Mean Time. It is the same everywhere (no timezones),
and doesn't spring forward or fall back. It just marches on.
I think many or all Unix systems keep their internal time in
UTC and just convert to or from local time for display purposes
or for doing the equivalent of DIR/SINCE (i.e. the file timestamps
on the disks are all in UTC as well). Maybe that's why these
things are so much harder to use on Unix and require separate
utilities (like find) instead of being built in to everything?
(Gratuitous Unix slap ;-))

>
>>>BTW, NTP seems to be much easier to set up than it appears at
>>
>>first sight.
>
>
> I have mine setup but not configured. I just run ntpdat at regular
> intervals to set the clock. Offset is always less than a second. KISS.
>
> BTW, MACs come pre-configured to an apple NTP server. That is really
> neat in terms of professional packaging of an OS. (and has done so since
> MAC OS 8.6). It is embedded in the time/date control panel, not some
> totally separate application. (In VMS terms, the NTP stuff as well as
> timezone settings and DST seeting would all be done through the SET TIME
> command, instead of having bits pand pieces in logical names, SYSGEN
> parameters, config files, NTP config etc.

Yup, right now we have a firewall at work that prevents access to the
the apple timeservers (I've been meaning to open this up), and if my
Powerbook has died because I forgot to shut it down and the battery
went dead (takes about 4 days in standby mode) it always forgets the
time, and if I first plug it in at work, it can't talk to the apple
timeserver and thinks its New Year's Eve, Dec 31, 1969! This is a pain
to fix, since I have to manually disable automatic time setting, set
the clock to the correct time (at least within a few minutes), shut
down and reboot it, then (if I remember) change the timeserver to be
one of our local ones (inside the firewall.) Then when I take it
home, it can't talk to our work NTP server and gets snippy again.
(You can change which NTP server it uses by typing its name into the
dialog box, and it will remember it, but it doesn't change servers
automatically when you change location, like it does most network-
related things (DNS servers, routers, etc.), and if you switch back
to one of the apple servers, it doesn't retain our work server in its
drop-down list, so to change back I need to type it in again.

I wonder if there is a problem with it that it forgets the time when
the battery goes dead, or if this is normal? Maybe they always figure
you'll either set the time manually or have access to one of their
time servers, so this is expected behavior?

To get back on topic to VMS, it sure could use some cleaning up
as you suggest. 

-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539

Relevant Pages

  • Re: Correcting my time servers clock drift on AlphaES40s / Tru64
    ... of a working NTP setup, but is not a design objective of NTP. ... is then a stratum 1 time server, Phillip looks to Terrance as its time server, ... with Terrance reading it's system clock. ... In that case, you need to create a clear server hierarchy, not to peer, ...
    (comp.protocols.time.ntp)
  • Re: Naval Observatory Master Clock
    ... Now, if the timers have to set legally traceable to NIST in the theoretic case, snarf the time via NTP and set your timers to the clock value plus one-half the dispersion. ... NIST doesn't set the standard for time. ... NTP is designed to keep the clock of your computer as closely sync'ed to "true" UTC time as is possible with the particular hardware/OS/software configuration you have, and some configurations are capable of better accuracy than others. ...
    (comp.protocols.time.ntp)
  • Re: NTP Loses sync over time.
    ... SNTP is not NTP and one can expect SNTP implementations to drift by ... the full clock frequency error between polls. ... A minute a day exceeds the capture range of the full version 4 NTP ... If the server is using a broken source ...
    (comp.protocols.time.ntp)
  • Re: Isolated Network Drift Problem
    ... No. PCs keep time even without NTP installed. ... clock reference will be able to provide time to NTP clients. ... page at ntp.org I'm thinking that a combination of a master server using ... If it is not possible for you to have your own stratum 1 time server, there are a fair number of them on the internet. ...
    (comp.protocols.time.ntp)
  • Re: Correcting my time servers clock drift on AlphaES40s / Tru64
    ... Keeping several machines together is a pleasant side-effect of a working NTP setup, but is not a design objective of NTP. ... is then a stratum 1 time server, Phillip looks to Terrance as its time server, and all is well. ... use ntp on phillip to get time from ntpd on Terrance, with Terrance reading it's system clock. ... In that case, you need to create a clear server hierarchy, not to peer, ...
    (comp.protocols.time.ntp)
Loading