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

David Woolley forums at david-woolley.me.uk
Sat Jan 26 12:09:51 UTC 2008


Petri Kaukasoina wrote:
> David Woolley  <david at ex.djwhome.demon.co.uk.invalid> wrote:

>> That has quite a lot of similarity with what ntpd itself does if it is 
>> cold started with iburst.  The only big difference is that it uses 900, 

> 
> Hmm, I can't see that. I put in only one good time source with iburst,
> deleted the drift file and started ntpd. The time offset just keeps growing
> and the frequency changes in very small steps. Now, after 30 minutes time is
> already 25 ms off and the frequency is only 1.5 ppm (the correct value would
> be about 25 ppm).

Looking at the comments in the 4.2.0 source code, it looks like you may 
be right; yet another reason why ntpd doesn't handle startup transients 
well!

If this is still true in the latest version ("< max" means offset < 128ms):

  *      State   < max   > max                   Comments
  *      ====================================================
  *      NSET    FREQ    FREQ                    no ntp.drift

  *      FREQ    SYNC    if (mu < 900) FREQ      calculate frequency
  *                      else if (allow) TSET
  *                      else FREQ
  *

Worse than is obvious here, it only sets the time on the first sample if 
it is out by more than 128ms.  More obvious, unless the frequency error 
is so high that the time changes by more than  128ms between the first 
two good samples, it will use the slow PLL method of calibrating the 
frequency.  Even then, unless the offset is more than 128ms both the for 
first sample, and after every subsequent sample, it will compute the 
frequency based on the final absolute value of clock offset, not the 
difference between the first and last readings; this might not be too 
important, because it looks to me to require the intial offset to be 
very close to 128ms (low  probability) or the frequency error to be 
quite high (percentage error in frequency calculation relatively low) 
for it to complete the frequency calibration.

What I was expecting was for it to unconditionally do both frequency and 
phase calibration, in the absence of the drift file.  I presume that 
chrony does a correction on the first couple of samples and then refines it.

Incidentally, the "else FREQ" doesn't seem to match the code and looks 
like it would prevent it ever getting out of the calibration under some 
conditions.

It looks like I need to fetch the latest source, although it looks, from 
your observations, as though it is still far from what I would consider 
right.




More information about the questions mailing list