On Mar 23, 16:38 UTC, Chuck Swiger <cswi...@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 next source. 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" [1] 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. Cheers, Dave Hart [1] http://www.eecis.udel.edu/~mills/ntp/html/assoc.html#orphan _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
