[ntp:questions] Alternative algorithms

Unruh unruh-spam at physics.ubc.ca
Sun Feb 15 06:16:50 UTC 2009


mills at udel.edu (David Mills) writes:

>Bill,

>a. You apparently haven't seen the data reported in Chapter 6 of my book.

Yes I have, but why is it relevant?

>b. You apparently haven't seen primary servers pogo.udel.edu and
>rackety.udel.edu.

??  Not sure what you are trying to say.

>c. You apparently haven't seen seen secondary servers baldwin.udel.edu
>and bridgeport.udel.edu, which for grins also run Autokey.

And again I have no idea what it is that you are trying to say. What is
special about any other these that has anything to do with chrony.


>Do that and make your claim again.

Which claim? I made a number of statements (including that I did not write
chrony). Which one are you arguing with and claiming that these servers
contradict the statement.

I stated that on the test that I ran, chrony was a factor of 2-3 better
than ntpd as measured by the offsets with respect to a Garmin 18 GPS clock.
I stand by those tests.


>Do that and make your claim again.

Do what? Fly to delaware to look at those machines?
Use them as ntp servers? 



>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