[ntp:questions] Re: Correcting my time servers clock drift on Alpha ES40s / Tru64

David Woolley david at djwhome.demon.co.uk
Tue Oct 25 08:19:24 UTC 2005


In article <1130206120.552423.243120 at g14g2000cwa.googlegroups.com>,
brett.sander at tenix.com wrote:

> and asked why we had the current configuration.  He said that he wanted
> the servers to stay in sync and acknowledged that the time would float
> (his main point was to keep them in sync).  Our network/server/system

In that case, you need to create a clear server hierarchy, not to peer,
or you need to use a protocol, like timed, that is intended for this 
usage.

> According to the man pages peer has the following description:

Your man pages claim conformance to version 3 of the protocol, and the
RFC, but you are clearly running version 4 of the protocol, for which there
is not yet a public specification.  Your supplier has probably simply retained
the man pages from the previous version.  (Personally I strongly disagree
with the policy of dropping man pages, but Dave Mills is a rather strong
willed person.)

> "This command specifies that the local server is to operate in
> "symmetric active" mode with the remote server host_address.  In this
> mode,the local server can be synchronized to the remote server and, in
> addition, the remote server can be synchronized by the local server.
> This is useful in a network of servers where, depending on various
> failure scenarios, either the local or remote server host may be the
> better source of time"

A fundamental assumption in NTP is that all machines are synchronised
to true time, so switching from source to source will still access a
correct time, but possibly with different error bounds.  Trying to peer
systems that use the local software clock simply results in unstable
behaviour because neither reference clock tracks true time.  If you have
multiple machines with a local clock as their source, they need to be
in a hierarchy so that one particular clock is always the dominant one
if it is accessible.  However, this is not a supported use of NTP, unless
the top of the hierarchy is synchronized to true time.

You will need to set the root clock before starting the main protocol.

> To my understanding, with our current setup, when terrance starts xntpd
> it checks its peers for their times.  Then it changes its time to match
> it (please correct me if I am wrong). Does it check both peers?(in our
> current setup with both phillip and 127.127.1.1 as peers)

If the configuration takes, in spite of the misuse of peer, the local
clock is a server of last resort unless you use "prefer".

> In the setup below, when terrance starts xntpd, it checks the server
> (its local clock) and then changes its time to meet it (I assume).

It's time is always the same as that of its local clock, so it can never
change its local clock to be match its local clock!!!!

> Does it then check phillip's time? What does it do if phillips time is
> different?

If you enabled it to look, by prefering the local clock, it would get 
confused because it would almost certainly have two clock with non
overlapping error bounds.  It may well reject both of them.  Actually,
I think it may ignore the peer in that case, because it isn't preferred
and because its stratum number is larger.




More information about the questions mailing list