svn commit: r219700 - head/sys/x86/x86
peterjeremy at acm.org
Fri Mar 25 11:36:58 UTC 2011
On 2011-Mar-25 21:02:03 +1100, Bruce Evans <brde at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-head/attachments/20110325/af8ed844/attachment.pgp
More information about the svn-src-head