From owner-freebsd-stable@FreeBSD.ORG Fri May 11 04:56:55 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4080C16A406 for ; Fri, 11 May 2007 04:56:55 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 016E313C4CC for ; Fri, 11 May 2007 04:56:54 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l4B4ueDb079816; Thu, 10 May 2007 22:56:40 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 10 May 2007 22:56:43 -0600 (MDT) Message-Id: <20070510.225643.-713548429.imp@bsdimp.com> To: peterjeremy@optushome.com.au From: "M. Warner Losh" In-Reply-To: <20070508191617.GH838@turion.vk2pj.dyndns.org> References: <200705081248.l48CmvBO083216@lurza.secnetix.de> <20070508151525.Y839@thinkpad.dieringer.dyndns.org> <20070508191617.GH838@turion.vk2pj.dyndns.org> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 10 May 2007 22:56:41 -0600 (MDT) Cc: freebsd-stable@freebsd.org, martin.dieringer@gmx.de Subject: Re: clock problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2007 04:56:55 -0000 In message: <20070508191617.GH838@turion.vk2pj.dyndns.org> Peter Jeremy writes: : There seems to be a bug in ntpd where the PLL can saturate at : +/-500ppm and will not recover. This problem seems too occur mostly : where the reference servers have lots of jitter (ie a fairly congested : link to them). Yes. This is a rather interesting misfeature of ntpd. Its rails are at +/- 500ppm, and when it hits the rail it assumes that things are too bad to continue and it stops. Most PC clocks have a frequency error on the order of 10-150ppm, so it doesn't take a whole lot of jitter from a conjectsted remote network to exceed the limits... Warner