Date: Fri, 25 Mar 2011 22:36:49 +1100 From: Peter Jeremy <peterjeremy@acm.org> To: Bruce Evans <brde@optusnet.com.au> Cc: src-committers@freebsd.org, John Baldwin <jhb@freebsd.org>, svn-src-all@freebsd.org, Warner Losh <imp@bsdimp.com>, svn-src-head@freebsd.org, Jung-uk Kim <jkim@freebsd.org> Subject: Re: svn commit: r219700 - head/sys/x86/x86 Message-ID: <20110325113649.GC55950@server.vk2pj.dyndns.org> In-Reply-To: <20110325203713.K956@besplex.bde.org> References: <201103161644.p2GGi8ug098283@svn.freebsd.org> <20110317200156.GB65858@server.vk2pj.dyndns.org> <201103171706.12993.jkim@FreeBSD.org> <201103230834.19151.jhb@freebsd.org> <4D8BD180.1060600@bsdimp.com> <20110325203713.K956@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--opJtzjQTFsWo+cga Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-Mar-25 21:02:03 +1100, Bruce Evans <brde@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 ti= me=20 >> 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. --=20 Peter Jeremy --opJtzjQTFsWo+cga Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEARECAAYFAk2MflEACgkQ/opHv/APuIclWwCcD0/cRBOE1HyqgMn38fGzyLNy nUoAoL9qzVFfYvs7At6Rrju37eqgLlVv =C47F -----END PGP SIGNATURE----- --opJtzjQTFsWo+cga--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110325113649.GC55950>