Kernel time-keeping adjustments - how to tune?

[Kevin Kinsey]

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