From owner-freebsd-stable@FreeBSD.ORG Fri Feb 12 13:11:19 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3707B1065679 for ; Fri, 12 Feb 2010 13:11:19 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by mx1.freebsd.org (Postfix) with ESMTP id 1C8808FC1E for ; Fri, 12 Feb 2010 13:11:18 +0000 (UTC) Received: from omta16.emeryville.ca.mail.comcast.net ([76.96.30.72]) by qmta14.emeryville.ca.mail.comcast.net with comcast id h13H1d0021ZMdJ4AE1BKe8; Fri, 12 Feb 2010 13:11:19 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta16.emeryville.ca.mail.comcast.net with comcast id h1DQ1d0033S48mS8c1DQgr; Fri, 12 Feb 2010 13:13:24 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 6B07C1E301A; Fri, 12 Feb 2010 05:11:17 -0800 (PST) Date: Fri, 12 Feb 2010 05:11:17 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100212131117.GA51905@icarus.home.lan> References: <20100211190652.6a66c618.torfinn.ingolfsen@broadpark.no> <20100211192515.GB13854@icarus.home.lan> <20100212132947.eb2af3d0.torfinn.ingolfsen@broadpark.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100212132947.eb2af3d0.torfinn.ingolfsen@broadpark.no> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: ntpd struggling to keep up - how to fix? 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, 12 Feb 2010 13:11:19 -0000 On Fri, Feb 12, 2010 at 01:29:47PM +0100, Torfinn Ingolfsen wrote: > On Thu, 11 Feb 2010 11:25:15 -0800 > Jeremy Chadwick wrote: > > > > > Your machine has a rapidly drifting clock, usually an indicator of a > > hardware problem (crystal gone bad is a common one -- seen this at work > > quite a few times), or possibly a bad time counter source chosen by the > > kernel. Can you please provide the output of: > > > > sysctl kern.timecounter > > Here it is: > root@kg-f2# sysctl kern.timecounter > kern.timecounter.tick: 1 > kern.timecounter.choice: TSC(-100) HPET(900) ACPI-safe(850) i8254(0) dummy(-1000000) > kern.timecounter.hardware: HPET > kern.timecounter.stepwarnings: 0 > kern.timecounter.tc.i8254.mask: 65535 > kern.timecounter.tc.i8254.counter: 52444 > kern.timecounter.tc.i8254.frequency: 1193182 > kern.timecounter.tc.i8254.quality: 0 > kern.timecounter.tc.ACPI-safe.mask: 4294967295 > kern.timecounter.tc.ACPI-safe.counter: 3252982815 > kern.timecounter.tc.ACPI-safe.frequency: 3579545 > kern.timecounter.tc.ACPI-safe.quality: 850 > kern.timecounter.tc.HPET.mask: 4294967295 > kern.timecounter.tc.HPET.counter: 3443625641 > kern.timecounter.tc.HPET.frequency: 14318180 > kern.timecounter.tc.HPET.quality: 900 > kern.timecounter.tc.TSC.mask: 4294967295 > kern.timecounter.tc.TSC.counter: 1276479615 > kern.timecounter.tc.TSC.frequency: 2819782573 > kern.timecounter.tc.TSC.quality: -100 > kern.timecounter.smp_tsc: 0 > kern.timecounter.invariant_tsc: 1 Please try doing this: - stop ntpd - rm /var/db/ntpd.drift - sysctl kern.timecounter.hardware=ACPI-safe - start ntpd Then see if your clock drifts. If it stops, great -- you can put that sysctl assignment line in /etc/sysctl.conf and consider it a done deal. I highly recommend putting some comments around it though so in the future you don't go "What's this? Silly!" and delete it. ;-) I'll also point out that it's common on FreeBSD[1] to see messages like the following (or at least it was circa 2006 -- I believe ntpd has been updated since then, but I've no indication said quirk was fixed/addressed): Dec 19 00:22:26 icarus ntpd[624]: kernel time sync enabled 2001 Dec 19 01:47:48 icarus ntpd[624]: kernel time sync enabled 6001 Dec 19 02:04:52 icarus ntpd[624]: kernel time sync enabled 2001 You can add the following to your ntp.conf to fix that problem: # maxpoll 9 is used to work around PLL/FLL flipping, which happens at # exactly 1024 seconds (the default maxpoll value). Another FreeBSD # user recommended using 9 instead: # http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031512.html # server some.ntp.server maxpoll 9 I recommend using the "iburst" directive on one (and only one!) server lines in your config, otherwise ntpd will usually 'settle' for about 10-15 minutes before bothering to try and update the clock the first time around. Example config: server clock.develooper.com maxpoll 9 iburst server ntp.nblug.org maxpoll 9 server tick.mtnlion.com maxpoll 9 server dewey.lib.ci.phoenix.az.us maxpoll 9 server ntp-1.cso.uiuc.edu maxpoll 9 server tick.jrc.us maxpoll 9 Finally, you should really consider adding some stratum 2 sources to your list, *in addition* to the stratum 3 server you're already using. ntpd can happily work with multiple servers, and will pick the best one as well as average them out vs. drift. It's pretty smart, honestly. We can talk about stratum 3 vs. 2 vs. 1 and use "ntpdc -c peers" to find out what those NTP servers sync with, if you'd like. [1]: http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031512.html -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |