David Gatwood wrote:

> The big advantage to this scheme is that, with the exception of the few
> milliseconds needed to increment a simple counter, interrupts are never
> disabled, which means interrupts never get lost, although clock interrupts
> can get queued up for a while in the worst case.  The only significant
> disadvantage is that there might be a slight drop in i/o performance,
> since most I/O would now be handled in a thread (albeit a high priority
> kernel thread).

Well, there are a few points:
1. Make this an option so that machines like the Quadras where we can 
put the clock interrupt at a better level aren't forced to take the I/O 
performance hit for this fix.

2. If there are machines which use the esp SCSI driver but don't allow 
us to change interrupt levels, then I'm not entirely sure this will 
work. The reason is the pdma code must run with interrupts disabled. It 
basically reads from a hunk of RAM over and over expecting the 
occasional bus error to be issued when the pdma fifo over/underflows. If 
this were handled in a thread that could be interrupted, then a random 
interrupt handler might get the bus error. Basically, the hardware 
requires some seriously hacky code to be fast. Unfortunately, it is the 
disk code that causes the most problems with drift, so I'm not sure what 
you can do in this case.

3. I'm not sure if this will be a win on DMA machines. The way I'm 
planning to do the DMA SCSI, the interrupt handlers will do very little 
besides occasionally updating the DMA engine or clearing the SCSI 
interrupts. There will be no "work" to do besides run through the SCSI 
state machine at the end of the transfer. The ethernet driver, though, 
could probably defer the copying of inbound data into mbufs until a 
thread, however. Though, an even better solution would be to DMA 
directly into the mbufs, but I can't think of how to do this without 
taking an interrupt per-packet (though, we may already be doing that!)

Overall, though, I would imagine this would improve the clock drift 
situation. Still, it would be great if we could find a high resolution 
free running counter somewhere. :(

-- 
----------------------------------------------
  Michael Zucca - mrz5149@acm.org
----------------------------------------------
  "I'm too old to use Emacs." -- Rod MacDonald
----------------------------------------------