From owner-freebsd-questions@FreeBSD.ORG Mon Jan 17 23:56:38 2005 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 150B216A4E2 for ; Mon, 17 Jan 2005 23:56:38 +0000 (GMT) Received: from dexter.starfire.mn.org (starfire.skypoint.net [66.93.17.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49A9343D2D for ; Mon, 17 Jan 2005 23:56:37 +0000 (GMT) (envelope-from john@dexter.starfire.mn.org) Received: (from john@localhost) by dexter.starfire.mn.org (8.11.3/8.11.3) id j0HNuYX30261; Mon, 17 Jan 2005 17:56:34 -0600 (CST) (envelope-from john) Date: Mon, 17 Jan 2005 17:56:34 -0600 From: John To: Kevin Kinsey Message-ID: <20050117175634.A30253@starfire.mn.org> References: <20050117144715.A29157@starfire.mn.org> <41EC2892.2050802@daleco.biz> <20050117151246.G29259@starfire.mn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20050117151246.G29259@starfire.mn.org>; from john@starfire.mn.org on Mon, Jan 17, 2005 at 03:12:46PM -0600 cc: freebsd-questions@freebsd.org Subject: Re: Kernel time-keeping adjustments - how to tune? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2005 23:56:38 -0000 On Mon, Jan 17, 2005 at 03:12:46PM -0600, John wrote: > On Mon, Jan 17, 2005 at 03:05:22PM -0600, Kevin Kinsey wrote: > > John wrote: > > > > >OK - on my FreeBSD 5.3-STABLE system, as I have documented (cf: > > >message thread Re: ntpd problems since upgrading to 5.3), ntpd > > >won't run, even with an identical configuation to the 5.2.1 system > > >next to it. Furthermore, when I run adjkerntz -a, it totally whacks > > >the system's ability to keep time - it races forward at quite a > > >high rate. ntpdate runs, and sets the time correctly. > > > > > >At one point, something managed to get the timekeeping parameters > > >pretty near normal - less than a second of drift per hour (much > > >better than the 40% rate it is now - it gains about 24 seconds PER > > >MINUTE). Then I ran adjkerntz -a again, just to see if it really > > >was the culprit. It does seem that it is adjkerntz that is causing > > >(or triggering) the problem, but now I can't get the system back > > >to a decent time-keeping rate. Whatever it was I stumbled across > > >before, I'm not finding it again now. > > > > > >Now, it doesn't appear that adjkerntz itself has changed in YEARS, > > >so it must be some change in the system call operation, parameters, > > >or data structures that is causing this. > > > > > >So - since I don't seem to be able to stumble across what I did > > >right before to get the timekeeping somewhat near normal, I am > > >wondering if there's a manual way to reach them. > > > > I read through the cited thread, and don't see any replies; > > nor do I see enough explanation to give you any magic > > beans. Of course, I'm no one's fairy godmother... > > LOL! No - I don't expect you to be - that'd take ALL the challenge > out of it! > > > > the clock on my 5.3-STABLE system is RACING. > > > It is going at almost twice as fast as real time. > > > > > > Hmm, that might mean something. What do you get from: > > > > sysctl -a | grep timecounter > > I don't know what all this means, but here it is... > kern.timecounter.stepwarnings: 0 > kern.timecounter.nbinuptime: 37254938 > kern.timecounter.nnanouptime: 0 > kern.timecounter.nmicrouptime: 3040 > kern.timecounter.nbintime: 19671985 > kern.timecounter.nnanotime: 2982761 > kern.timecounter.nmicrotime: 16689224 > kern.timecounter.ngetbinuptime: 0 > kern.timecounter.ngetnanouptime: 318046 > kern.timecounter.ngetmicrouptime: 14256461 > kern.timecounter.ngetbintime: 0 > kern.timecounter.ngetnanotime: 0 > kern.timecounter.ngetmicrotime: 3461614 > kern.timecounter.nsetclock: 87 > kern.timecounter.hardware: TSC > kern.timecounter.choice: TSC(800) i8254(0) dummy(-1000000) > kern.timecounter.tick: 1 > > Are these all documented somewhere? I'm sure they must be, but > I don't know where to look... > > > ?? > > > > IANAE, but I wonder if ntpd is going to be able to sync > > Well, maybe you will be soon. An "expert" is anyone who makes > three consecutive correct guesses on the same topic... :) > > > up until the local clock runs realistically.... > > Well, I thought of that, too, and during the period between when I > had it running decently and before I decided to try (all too > successfully) to recreate the problem with adjkerntz, I did > try ntpd again, but with the same results. It simply acted like > it could not see the server. Rebooting got the basic time-keeping parameters back in order. I'll try to do some work tomorrow night to figure out what is wrong with adjkerntz and why it is causing my clock to race. -- John Lind john@starfire.MN.ORG