[ntp:questions] NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)

Unruh unruh-spam at physics.ubc.ca
Tue Jan 22 18:32:30 UTC 2008


"David L. Mills" <mills at udel.edu> writes:


>In principle, comparing ntpd and chrony or any other vehicle is 
>meaninful only if using the same hardware, operating system and poll 
>interval. I assume chrony has done its homework and optimized the time 
>constant for the given poll interval. I am on a limb here, because 
>nobody has confirmed that chrony does in fact discipline the clock using 
>  some sort of feedback loop sensitive to both time and frequency 
>offset. If in fact it does not, then why are we having this discussion?

It does. And the comparison is on exactly the same machine, running exactly
the same operating system. The ONLY change is that chrony was replaced by
ntp on that system. Now the date is not the same. Unfortunately I cannot
run both ntp and chrony on the same system at the same time.




>Dave

>Unruh wrote:

>> david at ex.djwhome.demon.co.uk.invalid (David Woolley) writes:
>> 
>> 
>>>In article <eI8lj.17461$yQ1.5617 at edtnps89>,
>>>Unruh <unruh-spam at physics.ubc.ca> wrote:
>> 
>> 
>>>>No, the offset is the value reported in loopstats.
>> 
>> 
>>>Same thing.  If chrony is reporting the same measurements, neither set of
>>>measurements is particularly valid.  You need to measure the actual
>> 
>> 
>> I am sorry but I do not understand what you are saying. The best estimate
>> of the time error of the clock is the measurement that you make of that
>> error. Now, you might argue that if the drift never changed, and the clock
>> never changed then one could get a better estimate by averaging the
>> measurements. But the hypothesis that the time reported by the ntp process
>> is the true time plus random uncorrelated errors is simply wrong, as
>> looking at the plot of the offsets will rapidly convince you. The offsets
>> oscillate with a period on the order of an hour or so. Chrony does this.
>> ntp does this. The errors are NOT gaussian uncorrelated random errors. 
>> 
>> Thus most of that error budget is in such correlated errors, and ntp does
>> NOT do many orders of magnitude better ( even with uncorrelated random
>> errors you would need to average 100 samples-- collected over 10 hours at
>> poll 7 to get one order of magnitude, and by then the drift errors would have
>> gotten you.)
>> 
>> Anyway, I am comparing like with like in the two programs. Chrony is much
>> "better" in offsets, which implies that at least half of the error in ntp
>> is internal error. Ie, it is errors which do NOT average out. ( and I do
>> not believe that chrony's errors are the minimal uncorrelated random errors
>> either.)
>> 
>> 
>>>offsets, using something that has a repeatability a couple of orders
>> 
>> 
>> Of course that is the best way. Unfortunately I do not have that. I might
>> extend the line running the main server to also give me the "true" offsets
>> for the machine. However one can also get an estimate of the errors by
>> looking at the measured offsets using the ntp exchange. 
>> 
>> 
>>>of magnitude better.  Certainly for ntpd, offset should be much larger
>>>than the error, when locked.  Is the server running ntpd?
>> 
>> 
>> I do not believe this. 
>> Yes, the server is running ntp and its offset errors are of the order of 3usec-- again correlated as you can see from the "string" graph near the bottom of the page.
>> 
>> For example, if I take a 10 element running average and subtract it from
>> the raw output of ntp for the server , the standard deviation goes from
>> 3usec to .5usec. Ie, the errors are highly correlated. Averaging may be
>> able to  "get
>> rid" of that .5usec, but not the rest of the standard deviation (3usec)
>> which is some sort of highly correlated noise. IF the errors were really
>> uncorrelated random errors then subtracting off the running average would
>> make no ( well, little) difference to the standard deviation.( it would
>> decrease it by something like sqrt(N-1/N) where N is the length of the
>> running average)
>> 
>> Ie, it is simply not true that the measured offsets  reported by ntp, or chrony,
>> are simply some independent gaussian random process around the "true time". 
>> 
>> 
>> 
>> 
>>>Anyway, as I said, arguing by proxy is difficult and I'm rather hoping that
>>>Dave Mills will take over.  Certainly it is Dave Mills you have to 
>>>convince if ntpd is going to change.
>> 
>> 
>> I do not know if I am trying to "convince". I am trying to report the
>> outcomes of some experiments. Now if one (Mills) wants ntp to behave
>> differently than the experiments show it does, then I guess he will change
>> it. If not, then not. 
>> 
>> All I say is that the experiments I have carried out show that ntp is slow
>> to converge if it starts of badly, and leaves the offset scatter larger
>> than chrony does. It does have a smaller scatter in the rate. 
>> 
>> One of the great advantages of two different people-- Mills and Curnoe--
>> trying to impliment the same ideas in different ways is that one can learn
>> by studying the difference between their results. 
>> 




More information about the questions mailing list