[ntp:questions] Quick sync between two computers not connected to the internet
davehart at gmail.com
Tue Mar 23 18:24:25 UTC 2010
On Mar 23, 16:38 UTC, Chuck Swiger <cswiger at mac.com> wrote:
> In most cases, it is easier to solve the problem of sync'ing all computers to a
> correct timesource (and thus all be mutually in sync), then it is to setup a
> bunch of truly & completely isolated machines which happen to stay in sync.
> If I really had to solve the latter problem, I would likely connect the machines
> to a valid NTP timesource long enough to calibrate each machines' intrinsic
> drift from realtime, and then run time in standalone mode against their local clock.
This sounds like a good practical answer to the original question. I
would go further and suggest only a single machine needs to have its
frequency drift tamed by ntpd to get close enough to correct that the
rest of the PCs are only very marginally more likely to have problems
syncing to that single PC than a stable external reference.
The challenge is that all the PCs (at least those that work well with
ntpd, thinking of power saving and spread-spectrum clocking woes) have
clocks that are within a few hundred parts-per-million (PPM) in
frequency with the internationally agreed length of a second. ntpd
has a hard limit of 500 PPM for slewed correction, accomplished by
adjusting the frequency of the OS clock over the range -500 to 500
PPM. ntpd will keep the clock crudely in sync for clocks with
frequency error too close to the limit of 500 PPM to leave enough
wiggle room for ntpd's preferred method of correcting both offset and
frequency errors by adjusting the OS clock frequency. In that
degenerate case, ntpd will be repeatedly stepping (setting) the OS
clock, including backward steps as needed.
By running ntpd against an external time source (whether via NTP or a
local reference clock) on one machine for a few days, you should
observe its reported frequency (ntpq -c "rv 0 frequency", or as part
of ntpq -crv) settling down, and you should see the clock being
maintained with at most one step of the clock soon after starting
ntpd. At that point, the contents of the driftfile can be assumed to
bring ntpd on that machine within a handful of PPM of correct, with
the major remaining error due to the temperature coefficient of the
crystal oscillator, which is around 1 PPM per degree Celsius.
At that point you can move/reconfigure that PC into the isolated
network and configure it to be authoritative based on its local clock,
by configuring the LOCAL refclock 127.127.1.0 and "fudging" its
stratum up (I'd suggest to 8). Point ntpd on all the other machines
to the frequency-tamed LOCAL refclock box and before long all of them
should come in line, with their frequency correction in driftfile
settling down to eliminate most of the inherent clock drift.
The best way to keep a set of machines humming in tune is for them all
to share a single source, or for them to all agree on the priority of
sources so when the primary is unusable, they all switch to the same
The simplest way to achieve that is to use a single NTP server and
point all clients at it. If you already have a natural central server
like a database which the need for time sync is tightly-related to,
this may be the best approach.
If you want to maintain close sync without a single point of failure,
another way is to configure several (3 or more) with the LOCAL
refclock at elevated stratum, using stratum as priority, so you might
have one each at stratum 8, 9, 10, and 11. If the stratum 8 went
offline temporarily, everyone would switch to the stratum 9.
That is the hard way, though. More recent versions of ntpd support
"Orphan Mode"  which automatically organizes all your ntpds into
agreement on a random order of priority, so that again any failures or
isolation should result in every ntpd switching to the same secondary
(etc) source. I would suggest "tos orphan 8" if you go that route.
The elevated stratum avoids trouble when a ntpd configured for this
private network gains connectivity to "normal" ntpds synchronized
eventually to a real stratum 1 external reference, and as long as you
stay under the limit of 15, causes no pain for the isolated setup.
More information about the questions