[ntp:questions] Re: NTP sync on a standalone network (Windows 2k)
david at djwhome.demon.co.uk
Sat Aug 19 11:09:00 UTC 2006
In article <44e63895$0$32471$626a54ce at news.free.fr>,
Alexandre Carrausse <alex_s_p_a_m at carrausse.com> wrote:
> "Hal Murray" <hmurray at suespammers.org> wrote in message
> news:_L2dnc1lD-lW5HjZnZ2dnUVZ_v6dnZ2d at megapath.net...
> > 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
> > 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
> > 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.
More information about the questions