[ntp:questions] Alternative algorithms

David Mills mills at udel.edu
Sun Feb 15 03:14:20 UTC 2009


Bill,

a. You apparently haven't seen the data reported in Chapter 6 of my book.
b. You apparently haven't seen primary servers pogo.udel.edu and 
rackety.udel.edu.
c. You apparently haven't seen seen secondary servers baldwin.udel.edu 
and bridgeport.udel.edu, which for grins also run Autokey.

Do that and make your claim again.

Dave


Unruh wrote:

>"Richard B. Gilbert" <rgilbert88 at comcast.net> writes:
>
>  
>
>>There has been a good deal of discussion concerning the performance of ntpd.
>>    
>>
>
>  
>
>>It would be more to the point to demonstrate the superiority of some 
>>other than "Markovian" algorithm by writing a competing product and 
>>demonstrating that it works "better" in some sense.
>>    
>>
>
>  
>
>>At the present time, the only alternative I know of is something called 
>>"chrony" which I have never used.
>>    
>>
>
>And I demonstrated that chrony does better than ntpd by a factor of 2-3 as
>measured by the variance of the offsets for a set of computers connected to
>a GPS refcolck server via a local ethernet lan, and via an ADSL connection
>( where I used another local GPS clock to determine the offset of that
>computer which was disciplined by chrony and by ntpd using the above
>server, and offset measured by a local GPS receiver). 
>
>
>
>  
>
>>Ntpd works well with a hardware reference clock.
>>    
>>
>
>chrony does not work at all with hardware reference clocks. 
>
>  
>
>>Ntpd works slightly less well using internet servers as time sources.
>>    
>>
>
>As stated chrony works better by about a factor of 2-3.
>
>It also converges far faster on a cold start (eg if the clock is out by say
>25ms, it will be out by 0ms within about 15min assuming a poll interval of
>6. ntp will take more like 5 hours. )
>
>
>
>  
>
>>Ntpd's performance is noticeably better using internet sources during 
>>the hours when the internet is relatively lightly loaded.
>>    
>>
>
>  
>
>>If you can improve the performance without breaking something else, 
>>please demonstrate.  It would be nice if the improved product did not 
>>require more resources than ntpd currently does.
>>    
>>
>
>The size of chrony is slightly smaller ( but then again it does not have
>the refclock code). The other resources are very similar. 
>
>I did not write chrony  (Richard Curnoe did) but I have thought about
>adding shm refclock support to it. Have not managed to do so yet however. 
>This would allow one to use almost any refclock since it would be
>relatively easy to write an shm refclock driver. 
>
>The other problem is that at present chrony runs only on Linux (although
>there seem claims that it has been ported to BSD as well, but I have no
>idea whether it actually works there) It does not work on Windows and the
>port would be a pretty major undertaking. 
>
>
>
>
>
>_______________________________________________
>questions mailing list
>questions at lists.ntp.org
>https://lists.ntp.org/mailman/listinfo/questions
>  
>




More information about the questions mailing list