On Tue, 26 Feb 2002, Matt Thomas wrote:

> At 06:52 PM 2/26/2002 -0800, cgd@broadcom.com wrote:
> >At Wed, 27 Feb 2002 02:14:44 +0000 (UTC), "Rafal Boni" wrote:
> > > The following patch fixes it, but I'm still not sure what the right
> > > thing to do is if the interrupt is so delayed that we'll miss the next
> > > one -- I currently simply schedule the next clock interrupt the fixed
> > > time from *now* to avoid complexity in figuring out how far we'd fallen
> > > behind and adding in the right fugde factor.
> >
> >I think i've seen the following different methods used, at least:
> >
> >* figure out how many ticks should were missed, and call the
> >appropriate interrupt-delivery function that many times.  (i.e.,
> >bursty tick delivery when you have missed ticks.)
>
> PowerPC uses this method.

This is also the approach used by the mipsco port, which has a cycle
counter implemented in the support chipset (R4000 style, even though it
is a R3000 processor)
If implemeted correctly you can survive several seconds without clock
interrupt, microtime() will still be accurate, and you won't get any
clock slippage.

Take a look at sys/arch/mipco/obio/rambo.c for the driver.

TCOUNT references can be changed to the count register, and TBREAK to the
compare register.

-- 
Wayne Knowles			NetBSD/mipsco port maintainer
wdk@netbsd.org			http://www.netbsd.org