From owner-freebsd-stable@FreeBSD.ORG Wed May 9 17:22:30 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 07B7216A400 for ; Wed, 9 May 2007 17:22:30 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id 7673013C45B for ; Wed, 9 May 2007 17:22:29 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (obmtuh@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id l49HMMiO056862; Wed, 9 May 2007 19:22:28 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id l49HMMkf056861; Wed, 9 May 2007 19:22:22 +0200 (CEST) (envelope-from olli) Date: Wed, 9 May 2007 19:22:22 +0200 (CEST) Message-Id: <200705091722.l49HMMkf056861@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, Martin Dieringer In-Reply-To: <20070508164234.L839@thinkpad.dieringer.dyndns.org> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Wed, 09 May 2007 19:22:28 +0200 (CEST) Cc: Subject: Re: clock problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, Martin Dieringer List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2007 17:22:30 -0000 Martin Dieringer wrote: > # ntpq -p > remote refid st t when poll reach delay offset jitter > ============================================================================== > *time 192.53.103.108 2 u 19 64 77 91.454 301.926 860.104 > > and the clock is "only" 3 seconds late now... The delay, offset and jitter values are in milliseconds, so your current offset is about 0.3 ms. When you keep ntpd running, the offset should be reduced slowly. > > ntpd calculates the drift of the local clock. During times > > when it cannot reach the server, it corrects the local > > clock using the recorded drift. > > ok this sounds beautiful, but what if the drift is irregular? Normal quartz-controlled hardware clocks don't have an irregular drift. PC clocks aren't well-known for their precision, but the drift should be fairly constant. If your drift is noticeably irregular, then there is some- thing very wrong with your machine. I'm afraid that ntpd won't work very well under such circumstances. In that case you'll have to find out the cause of the problem and fix it, or help a FreeBSD to fix it (by providing the necessary pieces of information). > > > But 2 minutes is also too much > > > > ntpd should be able to handle that without problems. > > yes maybe, sometimes... Well, I agree that 2 minutes per day is much. Normally the maximum drift that can be corrected by "slewing" the clock is about 45 seconds per day (500 ppm). However, if the offset is larger than a certain limit, ntpd will step the clock anyway, so even a drift of 2 minutes should be correctable. (I think the limit is 128 ms, and the step will occur if the limit is exceeded for at least 15 minutes. But I'd have to look at the source code to be sure; the manual pages are sometimes not up- to-date with regard to such details.) > > > I have to redialup every 24h which normally works fine. > > > > How are you redialling? If you get a new dynamic IP > > address, it might be necessary to restart ntpd. > > MYADDR: > > !bg /etc/rc.d/ntpd restart > > great! 8-( > as "restart" does not work because the pid seems to be wrong and > usually there are 5 or so ntpd's running... ? Hu? There should be exactly one ntpd process running. You should clean up (kill all of them, remove any bogus PID file if there's one left, then restart ntpd). > btw, this is on the other machine which is now 2 minutes off again, > maybe 1 hour after correct setting: > > # ntpq -p > remote refid st t when poll reach delay offset jitter > ============================================================================== > chronos.zedat.f .PPS. 1 u 457 512 377 366.965 37369.6 8640.85 > > log: > 8 May 16:11:08 ntpd[57617]: synchronized to 130.133.1.10, stratum=1 > 8 May 16:11:08 ntpd[57617]: time reset +0.651381 s > 8 May 16:11:08 ntpd[57617]: kernel time sync disabled 2041 > 8 May 16:12:22 ntpd[57617]: synchronized to 130.133.1.10, stratum=1 > 8 May 16:13:30 ntpd[57617]: no servers reachable > > now: 16:57 A jitter of 8 seconds is really a lot. Is your uplink that bad? Of course, that adds to the problem that you already have because of (supposedly) irregular drift. If you have multiple machines behind the same uplink, it might be a good idea to configure one of them as an NTP server (preferably the one which has the smallest drift), and let all your other machines use that machine as the NTP time source. So at least all your own machines are synchronized with each other, and you separate the problem of the drift from the problem of a bad uplink. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "One of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs." -- Robert Firth