[ntp:questions] A faster settling NTP

unruh unruh at wormhole.physics.ubc.ca
Wed Dec 23 20:07:12 UTC 2009


On 2009-12-23, David J Taylor <david-taylor at blueyonder.delete-this-bit.and-this-part.co.uk.invalid> wrote:
>
> "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.

Sorry out of ideas then.

>
>
>>> 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?

??? The code is NOT available on ntpd. It would require a large coding
job to impliment the chrony algorithm into ntpd and if you knew that
your one year worth of work would never ever make it into ntpd, why
would you do it? To properly integrate it you have to know ntpd
intimately, know chrony ( or at least the algorithm) intmately, and do
the coding job. 
Note that I have run tests with chrony vs ntpd showing that on my test
system, chrony out performed ntpd significantly. The response was "If yo
ulike chrony so much use it, and don't bother us". The response from
David was that he was not interested until chrony had been tested in as
wide a set of circumstances as ntpd had been. 


>
>> 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 

The code is open license
 "Permission to use, copy, modify, and distribute this software and   *
* its documentation for any purpose with or without fee is hereby     *
* granted" 

It is a bit of a mess because there are several authors claimed, and the
legal position of their code is unclear from the documentation ( did
they transfer copyright? Did they license their code to ntpd with an
open license, were they employees of Mills so he automatically had the
copyright of their work, etc) but the chances of your being sued (
copyright is simply a license to sue) are pretty remote I think.

I have no interest whatsoever in Windows, nor, I suspect,  do most of the people involved with
chrony development. It is hard then to put in the time to do it. 

> 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.

chrony has refclock drivers, and ntpd can be altered (and has been) to deliver all of
its refclock drivers to chrony. So refclock is not a problem. The
problem is getting basic chrony to run  on windows. 

>
> 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.

The basic ntp algorithm is the problem. It is not simply that one has to
kludge on an additions "startup" algorithm. ntpd does much worse than
chrony even in long time running because of its poor response to change
( like temperature changes). The algorithm ( some combination of the
clock filter algorithm and the basic Markovian feedback loop) is simply
an extremely slowly responding algorithm all the time. It is most
obvious on startup but is there always. For people to hang a kludge onto
ntpd at startup, because that is what bothers you most, is not a job
most would want to do. You are of course free to do it yourself, but
like most of us, you do not have the depth of knowledge of ntpd, or
windows, or do not have the coding skills needed.  
Once upon a time, Richard Curnow, the author of chrony, had an interest
in porting it to Windows. Unfortunately other aspects of life caught up
with him (children, jobs,...) and his interest now is very small.




More information about the questions mailing list