Kernel time-keeping adjustments - how to tune?

[John]

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 at starfire.MN.ORG