In article <[EMAIL PROTECTED]>, Alexandre Carrausse <[EMAIL PROTECTED]> wrote: > "Hal Murray" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > Using a single system as the master seems like a reasonable approach > > to me. It's simple so you can understand it. Just fixup the time
Definitely. Peering was never intended to be use for unsychronised networks. It was not designed for creating a consensus time out of nothing. For a start, local clocks are normally clocks of last resort, so you would have to prefer them, but even then, the whole system would almost certainly wander in frequency and could end up with some machines exceeding the 500ppm maximum correctable frequency offset. > > by hand when it drifts too far off. > That's my plan. Today my system is 9 minutes below the real time. I can't > add 9 minutes in one go otherwise everything would crash. But I could add > one minute every morning during nine days and it would be fine. The smoothest way of doing this is to stop the master server's ntpd temporarily, load a large number in the correct sense into its ntp.drift and restart it. When it intersects true time, repeat the process, but put the measured static frequency error into ntp.drift. The large number should be less than 500.0 and it should also be less than 500 minus the largest value in ntp.drift, of the same sign, for any of the other clients. This ensures that no machine will need to exceed a 500ppm correction to retain lock. I'd suggest using 450, rather than 500. If you can get away with less, it will be even better. Assuming that the NT port supports remote configuration, I would suggest enabling that when you first stop the master server. You can then fudge the correction, to trim the frequency, without having to stop the server again. > > adjtimex is the utility to tweak the clock frequency. > Seems interesting in the long run. > The only data I have found looks like code to be compiled for Unix. Anything > ready for Windows? You can achieve the same by setting ntp.drift manually and restarting, or by fudging the local clock frequency, remotely. _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
