On 2011-Mar-25 21:02:03 +1100, Bruce Evans <b...@optusnet.com.au> wrote: >On Thu, 24 Mar 2011, Warner Losh wrote: >> ntpd requires that the time counter be within 128ppm of true. If the time >> counter guess is off by more than that, you lose: ntpd won't work.
I suspect Warner may be confusing the frequency tolerance with the time tolerance here. RFC5905 gives a lock range of +/-500ppm and +/-128msec and the FreeBSD ntpd implements those ranges. The actual timecounter needs to be well within the lock range to prevent the PLL saturating during transient events - I thought the timecounter limit was +/-300ppm but RFC1305 talks about a +/-100ppm limit in order to support an adjustment skew of +/-300ppm. >Is ntpd really that broken? What does it do if the drift file has the >correct compensation to within 128 ppm? RFC1305 includes a fairly detailed description of why the various limits were chosen in its appendices (though this wasn't transferred over to RFC5905). The drift file specifies the PLL frequency offset, capped at +/-500ppm. If the actual drift is outside that value then the PLL will remain stuck at the limit and ntpd will regularly step the time. >I use an old version of ntpd in which I've observed a positive feedback >loop when -x is used to prevent steps and the slew wants to be more than >128 ppm due to a transient. Some versions of ntpd appear to have a bug where, in an environment with significant jitter in peer/server time, the PLL can saturate at +/-500ppm and not recover. This is definitely true of the ntpd in Tru64 5.1 and (from memory) was true of ntpd in some versions of FreeBSD. -- Peter Jeremy
pgpXe0SBlHmxE.pgp
Description: PGP signature
