Rafal Boni wrote:
> So I finally got some time to try and figure out why the clock on my sgi
> was always being stepped by ntpd and have a fix for the problem.  
> 
> The problem (as suggested by Jason a while ago and pounded into my head
> when browsing through a copy of See Mips Run) is that rather than sched-
> uling the next clock interrupt a fixed interval from *when the last one
> was supposed to occurr*, we scheduled the next clock interrupt a fixed
> interval from *when we serviced* the current one.

I think this will actually make your time slow down as well.

The way I've done this in the past is to try to keep the stride
even from when it should occur.  If the time from when it should
tick to the ISR is too long the handler may have to patch things
up to ensure that the compare is not written behind the count.

You also need to know exactly how fast the clock is going.  For
instance some SGI systems had 133.0 and some had 133.3333Mhz
for the same processor (in this case R4600).

jeffs