[email protected] (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" <[email protected]> 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 >>[email protected] >>https://lists.ntp.org/mailman/listinfo/questions >> >> _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
