[ntp:questions] A faster settling NTP

unruh unruh at wormhole.physics.ubc.ca
Wed Dec 23 05:33:22 UTC 2009


On 2009-12-22, David J Taylor <david-taylor at blueyonder.delete-this-bit.and-this-part.co.uk.invalid> wrote:
> "Richard B. Gilbert" <rgilbert88 at comcast.net> wrote in message 
> news:xrOdnUgQK7Mhs6zWnZ2dnUVZ_uSdnZ2d at giganews.com...
> []
>> Anyone who thinks he can boot up, get the correct time to within 
>> microseconds and shut down again is living in a dream world!
>>
>> Windows is a poor choice of O/S for the job.  Try Linux or Solaris. 
>> Either will run on the X86 architecture.
>
> But Linux and Solaris will not run all the programs and device drivers I 
> need to run!  The OS is a given and is not going to change.  The 
> engineering challenge is: given a particular OS, do the best timekeeping 
> job you can.

That is fine. Just as there are crucial programs which do not run on
Linux, there are crucial programs which do not run on windows. 

>
> Where did I say I needed microseconds?  In fact settling to within one 
> millisecond would be fine for /my/ applications.

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 am already down to the level of seeing exactly what Bill was saying 
> could be done better with chrony than with NTP - the settling time to a 
> given accuracy, so I think that addressing the algorithm rather than the 
> choice of hardware is the most important issue here.
>
> 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. 
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. 



>
> Cheers,
> David 
>




More information about the questions mailing list