Re: Isolated Network Drift Problem



Cal Webster wrote:
On Tue, 2008-11-25 at 22:23 +0000, David Woolley wrote:
Cal Webster wrote:
None of our client machines use the local clock. The servers
configured
like this are the other 3 "peer" NTP servers. Don't they need some
type
of time reference if the master server becomes unreachable?
No. PCs keep time even without NTP installed.

Okay, I understand that the "PC" (Intel Linux host) will keep time on
its own, albeit at some unpredictable level of accuracy. What I'm not
getting is whether the NTP service running on that host without a local
clock reference will be able to provide time to NTP clients. If so, will
it be more accurate or less accurate if all the NTP peers each use their
own local clock as a time reference as opposed to having no reference at
all.

When I tried removing the "server" and "fudge" lines for the local clock
from ntp.conf but leaving the server lines naming the sister peers,
ntpdq showed nothing in the "peer" or "association" listings.

After communicating with Steve Kostecke and reading the NTP Association
page at ntp.org I'm thinking that a combination of a master server using
a fairly accurate local clock with several Orphan mode servers will work
best.

ntpd disciplines the local clock. If you use the local clock as your reference, it will always read exactly the same as the local clock
being disciplined, so no corrections will ever be made. You have fallen
for an urban legend!

The Local Clock driver is a fiction used to allow an unsynchronised machine to appear synchronised to downstream machines.

Isn't having an "apparently" synchronized NTP server better than having
no NTP server at all? Since we can't all have GPS reference clocks or
Internet connections, some of us have to make use of what we do have.

I'm just looking for the best way to get the most accurate time possible
distributed to a couple hundred machines spread across 15 networks in 3
buildings. Maybe that's asking a lot but that's what I'm aiming to do.
Anything you can do to help would be greatly appreciated.

Thanks! :-)

./Cal

The most important thing to do or attempt is to get a primary source of time. This can be an atomic clock (extremely expensive, extremely stable, extremely accurate), or something directly connected to an atomic clock. A GPS timing receiver will capture signals from four satellites and solve a system of four equations in four unknowns: time, latitude, longitude, and elevation. Each of the satellites carries an atomic clock! The GPS timing receivers sell for ~$100 and up. If you can site such a receiver so that it has an unobstructed view of the sky, this is a very good source of time.

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. Stratum 2 servers are even more plentiful. Stratum one servers have direct access to an atomic clock or equivalent; e.g. GPS receiver. Stratum two servers get their time from stratum 1 servers. Stratum 3 gets time from stratum 2. .. . . If you can't use internet servers and you can't set up your own stratum one server, you are SOL.

It is possible to "fake it" using a server that has a good clock but performance will not be as good as having an atomic clock at the root of the tree. That rock solid beat of one second per second is easy to get in step with and easy to keep step with.

An unsynchronized clock WILL drift and will be more difficult to get in step with and keep step with.

I can tell you from experience that a GPS receiver will give you rock solid time and that clients will synchronize easily with it. So will an atomic clock but that costs $50,000 or $100,000 more than the GPS receiver!
.



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: Which release notes say sts$manager:utc$configure_tdf is obsolete
    ... >>in UTC, and after comparing it to the time as determined from its ... I think it will only attempt to change the clock if it is less than ... or a ST clock just after the spring forward, and NTP would fix it. ... guess of the real time that it makes from polling the time server. ...
    (comp.os.vms)
  • 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: 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)
  • Re: ntp, wie kann es so genau sein?
    ... ntp dann, wie lange das Signal unterwegs war? ... lich die Genauigkeit deiner Zeitquelle nicht erhoehen. ... Server ist (und was die Stratum-Werte anbetrifft, ... Stratum 1 Server, wenn der Stratum 1 Server eine wenig genaue Zeit- ...
    (de.comp.os.unix.linux.misc)