Date: Tue, 18 Jan 2005 00:34:42 -0600 From: Kevin Kinsey <kdk@daleco.biz> To: John <john@starfire.mn.org> Cc: freebsd-questions@freebsd.org Subject: Re: Kernel time-keeping adjustments - how to tune? Message-ID: <41ECAE02.2070507@daleco.biz> In-Reply-To: <20050117151246.G29259@starfire.mn.org> References: <20050117144715.A29157@starfire.mn.org> <41EC2892.2050802@daleco.biz> <20050117151246.G29259@starfire.mn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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... > > I dunno; my first guess would be sysctl(8), but I don't see that every knob is mentioned. I've experienced a "racing" clock on some mobos (but mostly older ones<?>) with 5.X --- I don't remember it with 4.X, but I've set up many more 5.X boxes now. Setting the kern.timecounter.hardware sysctl to i8254 fixed a "racing" situation for me. After that, things settled down a bit, and finally ntpd could sync up with its master. It was quite unsettling, because my secretary's time records and emails were coming to me anywhere from 4 hours to 3 days in the future until we figured out what was going on. So, just a thought, but you might try, as root: # sysctl kern.timecounter.hardware=i8254 YMMV, of course. If it makes things worse, you'd go back to TSC in a similar manner. If it helps, add this line: kern.timecounter.hardware=i8254 to /etc/sysctl.conf. Kevin Kinsey
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41ECAE02.2070507>