ntpd struggling to keep up - how to fix?

Fri Feb 12 19:38:57 UTC 2010

On Fri, Feb 12, 2010 at 11:16:37AM -0800, Kevin Oberman wrote:
> > Date: Fri, 12 Feb 2010 05:11:17 -0800
> > From: Jeremy Chadwick <freebsd at jdc.parodius.com>
> > Sender: owner-freebsd-stable at 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 at 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 at 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.

iburst sends 8 packets (vs. the default of 1) with an interval delay of
2 seconds (assuming calldelay isn't set).

There's some sort of "rule" in the NTP community where more than 20
requests per hour is considered rude or worthy of blocking.  This was
discussed on the timekeepers list a while back.  The original thread
(AFAIR) was originally about rules/regulations for vendors (such as
router manufacturers who pick defaults, etc.), but I'm willing to bet
the concepts apply universally:

http://fortytwo.ch/mailman/pipermail/timekeepers/2006/002299.html

Relevant discussion pieces below, (*) marked as worth reading, and (!!!)
are highly relevant:

http://fortytwo.ch/mailman/pipermail/timekeepers/2006/002321.html
http://fortytwo.ch/mailman/pipermail/timekeepers/2006/002323.html
http://fortytwo.ch/mailman/pipermail/timekeepers/2006/002325.html
http://fortytwo.ch/mailman/pipermail/timekeepers/2006/002326.html
http://fortytwo.ch/mailman/pipermail/timekeepers/2006/002327.html (*)
http://fortytwo.ch/mailman/pipermail/timekeepers/2006/002329.html (*)
http://fortytwo.ch/mailman/pipermail/timekeepers/2006/002330.html (*)
http://fortytwo.ch/mailman/pipermail/timekeepers/2006/002331.html (!!!)
http://fortytwo.ch/mailman/pipermail/timekeepers/2006/002332.html (!!!)
http://fortytwo.ch/mailman/pipermail/timekeepers/2006/002335.html (!!!)

Using iburst on a LAN (e.g. box1 syncs from box2, and box2 syncs from
stratum 1/2/3 servers; box1 uses iburst, while box2 does not) is
highly recommended.

Also worth noting is that those who provide public NTP servers
apparently keep usage stats per client/IP on how many queries they
send over a period of time, and *will* blacklist you.  How to deal with
abusers is an interesting topic to read there.

When it comes to NTP: tread lightly.  :-)

-- 
| Jeremy Chadwick                                   jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |