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

David L. Mills mills at udel.edu
Sat Jan 26 21:41:13 UTC 2008


David,

I don't know your version, but the TSET state was removed some time ago 
and your comments are different from the current source. It's really 
hard to test the discipline under all conceivable conditions. Now and 
then somebody cooks up a case considered very unlikely, like Solaris 
adjtime() behavior with large offsets and force-slew mode, so the code 
does get tweaked from time to time.

Dave

David Woolley wrote:

> 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