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

Brian T. Brunner brian.t.brunner at gai-tronics.com
Tue Oct 25 14:24:27 UTC 2005

This sounds like a job for "NTP For Dummies(tm)", which is the type of
job my needs call for.

You (Brett) don't need the systems to be on UTC as much as you need them 
to be together.  Keeping several machines together is a pleasant side-effect 
of a working NTP setup, but is not a design objective of NTP.

Options: 1: Can you get a GPS time receiver? They're in the neighborhood 
of $100 and will serve time as a "ref clock", the machine it's on (?Terrance?)
is then a stratum 1 time server, Phillip looks to Terrance as its time server, 
and all is well.

Options 2: Can Terrance and Philip look to "outside" networked machines?
If so they can be configured to get fairly good time from public servers,
and all is well.

Option 3: Skip ntp altogether, some human has the job of giving Terrance
a good-enough time (via reading /dev/wrist/timex and setting system time)
and Phillip needs a cron job to read Terrance's time on say an hourly basis.

Option 4: (the one you're using now) use ntp on phillip to get time from 
ntpd on Terrance, with Terrance reading it's system clock.

Which of these is your best fit solution?

Brian Brunner
brian.t.brunner at gai-tronics.com

>>> David Woolley <david at djwhome.demon.co.uk> 10/25/05 04:19AM >>>
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 

> 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 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.

questions mailing list
questions at lists.ntp.isc.org 
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept
for the presence of computer viruses.

www.hubbell.com - Hubbell Incorporated

More information about the questions mailing list