[ntp:questions] Re: NTP seems unsuitable for this application... what do you think?
david at djwhome.demon.co.uk
Thu Dec 2 22:15:19 UTC 2004
In article <%eFrd.4$5V2.2 at dfw-service2.ext.ray.com>,
John Seal <sealj at indy.raytheon.com> wrote:
> "if two NTP servers are synchronized to each other as peers, what
> actually happens is the clocks decide among themselves which is the
> better source of time, and both clocks attempt to synchronize to that".
I think that there is a lot of urban folk law about peering. If you
really want the two to negotiate, you need timed, not ntpd. This came
with SunOS and may be the other protocol your documentation refers to.
timed doesn't provide a correct time, only a mutually agreed one.
With ntpd, in this case, both machines will consider their local clocks
to be perfect as they have the lowest stratum number, are preferred,
and have a zero offset. The other machine, after a small amount of drift
will also be outside the very small estimated error tolerance of the local
clock. The local clocks also never fail, even if they have never been
given a good time.
As I understand it, the effect of peering is to take the other machine into
consideration when trying to decide which clocks are true-chimers, but you
haven't got any tie breakers and the perceived error band is very small.
(Even then, I think they will only take into account machines that are not
at higher stratum numbers.) The peer is also available if it becomes the
server nearest the root that survives the true chimer test.
One other thing to watch out for is that people tend to answer based
on an assumption that you are only slightly at variance from a normal
configuration, but you are actually a very long way from a normal
configuration. To have something like a normal system, the GPS would
have to be operating a proper reference clock driver, and servicing it
all the time. That driver would have to refuse to give out time unless
there was a GPS signal.
More information about the questions