[ntp:questions] Re: What does 73.78.73.84 refer to?

David Woolley david at djwhome.demon.co.uk
Sat Nov 12 17:30:53 UTC 2005


In article <pan.2005.11.11.14.19.40.747105 at mail.localhost.invalid>,
"Tim <tim at mail.localhost.invalid>" <> wrote:

> I can assure that it is.  Consider this:  If I set my clock once, then
> hope that it's going to stay correct, it's in the same condition whether I
> set that via NTP or some other method (e.g listening to the radio).

You have an incorrect analogy of how NTP works.

Assuming you adjust the pendulum length, trim the balance wheel spring,
or tweak the variable capacitor across the crystal, so as to slightly
over compensate for the error in the speed of the mechanism, by an amount
that depends on the time offset, and you continue doing this, eventually
there will be negligible time error and the clock will be going at just
the right speed so that it wil stay very close to the correct time for
a very long time.

NTP only twists the knob on the back of the clock as a last resort (when
the error is more than 128ms).

(If you are under 40, you may not be so aware that clocks used to be 
adjustable, as, with quartz clocks, it is not longer a user adjustment, 
and may not even be a factory one on cheap devices.)

> You'd have to be continually verifying time, with something like NTP, to
> say you've got a system that could be used as a time server.

Once you have the frequency error trimmed out, you should stay within 100
ms for over a day.  You don't need to continually re-check the time and NTP,
even when connected, will back off the intervals once it has converged.

> For what it's worth, my hardware clock on one motherboard is damn good. 
> It's only ever out by about 1 second a month.  I could easily use that as

If you are running NTP on Linux, the kernel will be correcting the
hardware clock every 11 minutes, whilst there is a valid synchronisation
source, to make it agree with NTP time.  (I'd expect about 5 seconds a month
for an NTP that had lost all its synchronisation sources, when they had
previously been good.)

> My experience with NTP stopping wouldn't seem to indicate a crash, just a
> dummy spit.  Without at least a local reference, it'd stop serving time if
> remote references were lost.  If remote references weren't available when

That's correct, but the downstream systems will free run with the last
frequency correction.  However, this is the first time you have said that
this is not a leaf node.  The reason it stops serving is that it is no
longer a reliable source, so the downstream machines' idea of true time
is probably as good as its.  Sometimes it is more important to have matching
times than correct times, and the local clock can be useful then.

> you tried to start it, it would start then shut down.  Though I think a

That's not true of the Linux (Red Hat, even) ntpd's that I have used.  They
will continue waiting for a server to come up.  It's possible that you will
have a problem if the DNS resolution times out leaving no possible servers,
but even that does't seem right as you can dynamically add them.




More information about the questions mailing list