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

Unruh unruh-spam at physics.ubc.ca
Tue Jan 22 02:14:22 UTC 2008


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