Date: Fri, 12 Feb 2010 11:16:37 -0800 From: "Kevin Oberman" <oberman@es.net> To: Jeremy Chadwick <freebsd@jdc.parodius.com> Cc: freebsd-stable@freebsd.org Subject: Re: ntpd struggling to keep up - how to fix? Message-ID: <20100212191637.653011CC09@ptavv.es.net> In-Reply-To: Your message of "Fri, 12 Feb 2010 05:11:17 PST." <20100212131117.GA51905@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Fri, 12 Feb 2010 05:11:17 -0800 > From: Jeremy Chadwick <freebsd@jdc.parodius.com> > Sender: owner-freebsd-stable@freebsd.org > > On Fri, Feb 12, 2010 at 01:29:47PM +0100, Torfinn Ingolfsen wrote: > > On Thu, 11 Feb 2010 11:25:15 -0800 > > Jeremy Chadwick <freebsd@jdc.parodius.com> 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 > <repeat indefinitely> > > 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: Why "(and only one!)"? I have never seen a problem with 'iburst' on all servers (assuming they are Internet connected". 'iburst' only makes a difference on the initial query and, if the server you have marked as 'iburst' is unreachable, it will really slow down synchronization. I am unaware of any issues with multiple servers being marked 'iburst' and typically configure 7 ntp servers for a system, all tagged as 'iburst'. Never sen any issue with this. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100212191637.653011CC09>