svn commit: r219700 - head/sys/x86/x86

[Peter Jeremy]

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
FreeBSD.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-head/attachments/20110325/af8ed844/attachment.pgp