From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 25 15:35:54 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F077116A4DF for ; Tue, 25 Jul 2006 15:35:54 +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 8B69B43D46 for ; Tue, 25 Jul 2006 15:35:54 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k6PFYBYV019001; Tue, 25 Jul 2006 09:34:11 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 25 Jul 2006 09:34:29 -0600 (MDT) Message-Id: <20060725.093429.-1648696470.imp@bsdimp.com> To: scheidell@secnap.net From: "M. Warner Losh" In-Reply-To: References: 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]); Tue, 25 Jul 2006 09:34:12 -0600 (MDT) Cc: freebsd-hackers@freebsd.org Subject: Re: FBSD 5.5 and software timers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2006 15:35:55 -0000 In message: "Michael Scheidell" writes: : > -----Original Message----- : > From: Peter Jeremy [mailto:peterjeremy@optushome.com.au] : > Sent: Tuesday, July 25, 2006 4:00 AM : > To: Michael Scheidell : > Cc: freebsd-hackers@freebsd.org : > Subject: Re: FBSD 5.5 and software timers : > : > : > Basically, when you ask for a 200msec delay, the kernel : > sleeps until an absolute time. It looks like the handling of : > absolute time sleeps across time steps was changed. : > Unfortunately, both approaches are equally valid in different : > circumstances. : I agree : > : > >It fails within 1 second of getting these types of log : > entries: Jul 23 : > >15:03:42 audit18 ntpd[473]: time reset -2.497234 s Jul 23 16:03:56 : > >audit18 ntpd[473]: time reset +1.532401 s : > : > Rather than focussing on the changed sleep handling, I : > suggest you concentrate on fixing your clock: Your system : > clock should not be stepping. : > : Except: 20 different machines. Some IBM 300's with 2.0Ghz P4,s, 305 and : 306's with 2.8P4, some DELL 750's and 850's with 2.8p4 with HTT enabled. : : Even the 5.4 machines shows the bifurcating -1, +2, -2, +1 time resets, : but timers work more like I want them to. : : > I presume the servers are all stable (ie not stepping) and : > have a reasonably low delay. If so, I suspect your ntpd PLL : > has locked up. I've seen problems with some versions of ntpd : : 20 different machines? That would strongly imply a poor choice of upstream server. Followed closely by all the machines have the same timekeeping hardware that's misbehaving. Try different kern.timecounter.hardware settings to see if the problem goes away. Warner