[ntp:questions] A faster settling NTP

David J Taylor david-taylor at blueyonder.delete-this-bit.and-this-part.co.uk.invalid
Wed Dec 23 09:16:39 UTC 2009

"unruh" <unruh at wormhole.physics.ubc.ca> wrote in message 
news:slrnhj3at2.i10.unruh at wormhole.physics.ubc.ca...
> ntp will eventually settle to within a millisecond.
> You can help by running it with the -g option, and apparently without a
> ntp.drift file (It a) steps to within 1/8 of a sec, and tries to
> raplidly determine the drift.)

I checked and I do have the -g option set.  I have not seen faster 
settling without a drift file, although I have seen the behaviour which 
others have reported of a very occasional ever-increasing drift which can 
only be cured by restarting without a drift file.

>> How about a dual-algorithm NTP?
> It is a massive coding job. chorny is not exactly a two line program.
> And David Mills, who controls the algorithm of ntpd, does not have any
> interest in implimenting any other algorithm, at least at this time.

The code is available - so why not demonstrate that the algorithm can be 
improved in a private version?

> Probably more userful would be porting chrony to windows. That is also a
> big job. The biggest problem is to impliment the kernel microsecond or
> nanosecond time control that the Linux/BSd kernels have, and then the
> equivalent of the adjtimex routines to interface with those timing
> routines.
> Windows uses only the time interrupt ( originally 18 times a sec, now up
> to 1000 times a sec) and does not divide the kernel time finer than
> that. Linux/BSD divide the time into usec or nsec using things like
> hpet, the cpu instruction counter,... to give the fine resolution. After
> that one needs to impliment the select call with its fineness etc. Ie,
> one has to try to make the Windows kernel act like a linux kernel.
> Once those things are set, the porting is probably not too bad. Note
> that the Meinberg implimentation of ntpd on windows had similar
> problems as far as I can see.

As you hint, a lot of this work has already been done for Windows, both 
for the slow clock (before Windows Vista) and for the faster-clock (Vista 
and Windows-7).  One  could perhaps ask for permission to borrow that 
code.  Even better, Dave Hart's DLL now allows the PPS driver to get more 
accurate kernel mode timestamps, once we are talking about porting 
ref-clock drivers as well, but that's quite a long way down the line.

It would seem to me to be far less effort simply to provide an enhanced 
fast-convergence option to the existing NTP code, test that privately, and 
propose it as an option users can take or not, according to their own 
needs.  That code already accepts many ref-clocks, and is already ported 
to multiple operating systems.


More information about the questions mailing list