Subject: Re: alpha: NTP with "options NTP" should now work...
To: Jukka Marin <jmarin@pyy.jmp.fi>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: port-alpha
Date: 09/06/1999 23:00:30
In message <19990907084513.A27366@pyy.jmp.fi>Jukka Marin writes
>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.


Yeah.  CGD imporved the standfard BSD `fat tick' (on on one tick each
second, add in the 1024 * 576 usecs) with an approximation of 
Euclid's GCD algorithm, to find more places to add vewer fatter ticks,
without carrying residual usecs. The names of the variables got changed.

Dave Mill's ntp code re-used the old BSD kernel variable names,
but  acutally kept track of residual (sub)microseconds.

Maybe somone garbage-collected the "fixtick" code. not realizing NTP
stil used it. I'm sure someone tested NTP on an Alpha.

>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.

This micro-optimization isnt worth it if you dont have explicit carry
bits.  besides, Mill's nanosecond-resolution timekeeping code
(nanokernel) makes it moot.