[ntp:questions] chrony and ntp comparison-- ADSL hookup
David L. Mills
mills at udel.edu
Fri Feb 22 19:19:30 UTC 2008
You hint that it is now the responibility of the NTP crew to rebut your
claims. Please see the great detail in Chapter 6 of my book, which
reports on the resulrs of hundreds of experiments with onboard
oscillators, PPS signals, LANs and various Internet paths all over the
globe. Included are wedge scattergrams, CDF funtions and time and
frequency plots, some covering thousands of hours.
I've said many times that you are not comparing chrony and NTP on a
level field. If you crank the NTP time constant comparable to yours, I
strongly expect the two will perform in very similar fashion. In your
particular LAN the Allan intercept, or when the phase noise about equals
the flicker noise, could be somewhat lower than assumed as default by
NTP, but the default depends on a number of considerations other than to
minimize the risetime.
The only scientific question of interest here is whether a
linear-regression loop is better or worse than a phase-lock loop. Let's
not waste time on issues other than that. You can test that by changing
probably only a couple lines in your code. Be sure the risetime and
overshoot characteristics are similar.
> "Richard B. Gilbert" <rgilbert88 at comcast.net> writes:
>>>"David J Taylor" <david-taylor at blueyonder.neither-this-bit.nor-this-bit.co.uk> writes:
>>>>>>- the default for min and max poll are 6 and 10 (IIRC), and not 4
>>>>>And so? Exactly how is this supposed to make a difference?
>>>>It means that your tests are not carried out on an "out of the box"
>>>>configuration, and therefore perhaps less useful than they might otherwise
>>>>be. It's possible that some servers would see min/maxpoll of 4 and 7 as
>>>And no "out of box" test is possible. Neither ntp ( althoug it is much
>>>closer) or chrony are set up to do so.
>>>Right now I do not care what servers find abusive. I am using my own
>>>server, so I decide what is abusive. I am not advocating these parameters,
>>>I am using them to test ntp and chrony. ALL of the tests indicate that
>>>chrony disciplines the clock about a factor of 2-3 better than does ntp.
>>Testing ntpd and chrony using a local server or servers is not a very
>>realistic test of "real world" performance!
>>Try configuring both with the same set of four to ten internet servers.
>> Set up a stratum 1 server using GPS or a cesium clock as a reference
>>to serve as a standard to measure with. Collect statistics for a month
>>Then tell us what you learned.
> You are starting to sound like the cigarette people when it was pointed out
> that smoking might cause cancer.
> I was trying to test the algorithms NOT the programs as a whole.
> I am not advocating that the world rush out and abandon NTP and alkl run
> chonry. Too many problems. Chrony does not do refclocks. chrony does not
> handle leap seconds. chrony runs only on Linux ( well a bit on a few others
> but not many). However where chrony does run it "beats the pants off" ntp.
> This suggests that the algorithm in chrony is a better clock discipline
> algorithm than ntp's. Has this been tested extensively? No. Is it a
> foolproof conclusion? No. But ALL the evidence at present is that chrony's
> algorithm beats ntp's. If you believe that there are conditions under which
> ntp's would beat chrony's it now becomes your duty to suggest why and
> where. "You have not done enough tests" is the response of someone with a
> completely closed mind.
> I really do not care what you believe about ntp since you have zero data to
> back up your position. I am not claiming that ntp fails. It is a robust,
> well tested algorithm. It works and is certainly "good enough" for almost
> everyone who uses it. I am asking if it is the best we can do. My data
> suggests it is not.
> Note the my latest test was NOT using a local server. It was a remoTE
> stratum 1 server, over an ADSL hookup with a 16ms delay.
> It had 100 times the mean delay and 10 times or more the variance in that
> delay of the "local" test.
> And exactly what would you expect to find if I ran it for a month rather
> than a day? Would you really expect something about the chrony algorithm to
> show up in a month? What? I suspect you have no idea whatsoever as to
> what the chrony algorithm is so you could not if you wanted to.
> And I used a GPS PPS as the reference source on the ADSL client to measure
> the clock offset with.
More information about the questions