From owner-freebsd-stable@FreeBSD.ORG Fri May 11 05:02:48 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 1D63416A402 for ; Fri, 11 May 2007 05:02:48 +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 D30D013C45A for ; Fri, 11 May 2007 05:02:47 +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 l4B50t0u079854; Thu, 10 May 2007 23:00:55 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 10 May 2007 23:00:58 -0600 (MDT) Message-Id: <20070510.230058.-2001109480.imp@bsdimp.com> To: freebsd-stable@FreeBSD.ORG, olli@lurza.secnetix.de From: "M. Warner Losh" In-Reply-To: <200705091640.l49GeW9q055050@lurza.secnetix.de> References: <8EA8AB80-786A-431C-BFFD-6E244D3E25E8@goldmark.org> <200705091640.l49GeW9q055050@lurza.secnetix.de> 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 23:00:55 -0600 (MDT) Cc: 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 05:02:48 -0000 In message: <200705091640.l49GeW9q055050@lurza.secnetix.de> Oliver Fromme writes: : Martin's Problem with ntpd is not a precision problem. : His problem is that his ntpd does not synchronize at all. : Adding more servers certainly won't solve that problem. There are two causes to not synchronizing at all. One of them is really crappy hardware. It has been known to happen. One of the things I do for the commerical ntp servers that my company sells is to run ntpd on it for a while and monitor the error. If it gets above 150ppm, we RMA the board as defective, as the boards we buy are usually closer to 30ppm off. This may be the problem if powerd is running and you are using a source of time that's based on frequency of the processor. Since powerd is always jerking it around, you will never measure a stable frequency and you will never converge. The other time you won't converge is on heavily conjested links. In this case the jitter to the remote system is so large, and the traffic patterns so heavy that ntp's assumption that the round trip time is basically symmetric breaks down. When it is badly asymmetric, you won't get convergence either. Well, there is a third cause of noy synchronizing, but he's not developing a ntpd reference clock driver... Warner