From owner-freebsd-questions@FreeBSD.ORG Mon Jan 17 21:12:49 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 B251416A4CF for ; Mon, 17 Jan 2005 21:12:49 +0000 (GMT) Received: from dexter.starfire.mn.org (starfire.skypoint.net [66.93.17.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB2C543D31 for ; Mon, 17 Jan 2005 21:12:48 +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 j0HLCkt29400; Mon, 17 Jan 2005 15:12:46 -0600 (CST) (envelope-from john) Date: Mon, 17 Jan 2005 15:12:46 -0600 From: John To: Kevin Kinsey Message-ID: <20050117151246.G29259@starfire.mn.org> References: <20050117144715.A29157@starfire.mn.org> <41EC2892.2050802@daleco.biz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <41EC2892.2050802@daleco.biz>; from kdk@daleco.biz on Mon, Jan 17, 2005 at 03:05:22PM -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 21:12:49 -0000 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. > Kevin Kinsey -- John Lind john@starfire.MN.ORG