On Mon, Sep 06, 1999 at 05:19:02PM -0400, Bill Sommerfeld wrote:
> So, I tried bringing up NTP with the kernel PLL support (options NTP)
> on my pc164, and was horrified to see a ~560ppm frequency error in the
> system's clock.  NTP can only really deal with about a 500ppm error,
> so this really blows accurate timekeeping out the window.
> 
> It turned out that this was due to an MI software bug.
> 
> On alpha, hz=1024; this does not divide evenly into 1000000; as a
> result, you lose 576us per second if you just increment the clock by
> (1000000/hz) us per hardclock interrupt.
> 
> The non-NTP path has a pair of variables (tickfix and tickfixinterval)
> which allow this error to be corrected.

I have used a "sub-tick" counter to fix this on custom hardware projects.
You add a constant value to a sub-tick counter and only when this counter
overflows, you increment the tick counter.  This can be easily implemented
in assembly language where you may only need two add instructions (first
add without carry to sub-tick, then add 0 with carry to tick counter).

If the interrupt frequency is 1024 Hz and the tick counter should run at
1000 Hz, just set up a 16-bit sub-tick counter and add 1000/1024*65536 or
64000 to it every interrupt time.  When the sub-tick counter wraps, add
one to tick.

  -jm