Date: Thu, 28 Dec 1995 06:27:03 -0500 From: Gene Stark <gene@starkhome.cs.sunysb.edu> To: bde@zeta.org.au Cc: peter@haywire.dialix.com, current@freebsd.org Subject: Re: Tick, tock, adjust the clock Message-ID: <199512281127.GAA20008@starkhome.cs.sunysb.edu> In-Reply-To: <199512281036.VAA25874@godzilla.zeta.org.au> (message from Bruce Evans on Thu, 28 Dec 1995 21:36:29 %2B1100)
next in thread | previous in thread | raw e-mail | index | archive | help
>Note that this method doesn't work on 586's. The tick length is now given >by the macro CPU_THISTICKLEN(tick) instead of plain `tick', and on 586's >the `tick' arg to the macro is ignored. A similar effect can be obtained >by adjusting `i586_ctr_rate' instead of `tick', but it would be better in >all cases to adjust the 8254 clock's maximum count so that clock interrupts >occur every 10000 +- 0.5 ideal ticks. Then `tick' wouldn't need to be >adjusted. Awhile back when we communicated about this, you suggested the same thing. I spent awhile trying kernels that had been compiled with modified values for the constant that controls the 8254 clock count (I have forgotten what it was called), but after a number of tries I was only able to make the problem worse, rather than better. When what seemed to be the correct direction of change (smaller value to make the clock tick faster, larger value to make the clock tick slower) didn't work, I tried an offset in the opposite direction. The results seemed very counterintuitive to me at the time, making me think there must be some other adjustment mechanism at work that I wasn't seeing. After spending a bunch of time on it, I found that adjusting `tick' made it work, so I did that. The other bugs you just mentioned are one-time things that shouldn't affect the ability of xntpd to sync up the time. - Gene
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512281127.GAA20008>