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 <[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