Petri Kaukasoina wrote:
> David Woolley <[EMAIL PROTECTED]> 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.
_______________________________________________
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
