[linux-audio-user] Is everyone sick of interrupts yet?

[Mark Knecht]

On Tue, 2004-09-28 at 17:05, Lee Revell wrote:

> Correct.  I have measured the delay, is it a matter of a few
> nanoseconds.  

I don't mean to be argumentative but it cannot be. A single PCI clock
cycle is 30nS @33MHz. It takes dozens of PCI cycles for the chipset to
ensure access to the bus (removing PCI grant and waiting until all
devices are off, then sending a PCI address, getting a target hit
response and starting the read. At that point you can read a single
register, or possibly multiple registers if the chip supports it. This
is not a few nanosecond. A few micro seconds to read a single Interrutp
register in a PCI chip to see if it's involved, but not nanoseconds.
Most North Bridges cannot access the PCI bus for fewer than about 15
clocks by the time you look at their bus operations. We do this stuff
all the time in our PCI 1394 drivers looking at IO's/Sec. PCI-Express
maybe, but not PCI.

If you're talking about the speed reading the PCI itself, then I'd buy
that this is much shorter as it's in the chipset. However, the processor
still has to cross the front side bus. There are latencies that arise
there dependign on what the processoris doing physically. Certainly this
time is much shorter though.

> Way too small to be an issue _if_ the irq handling system
> is properly designed for low latency, as is the case with OSX and Linux
> 2.6 with the VP patches.  The 2.4 low latency kernel is more of a hack.

I'm not a programmer. I couldn't comment on that.
> 
> I have also measured the delay when the USB irq handler is shared with
> the sound card.  With Ingo's latency tracer you can see the actual flow
> of control when the USB irq interrupts the soundcard irq.  It's very
> small, something like 50-100 usecs.  To keep this in perspective when
> using jack at 32 frames, 48KHZ, you have 333 usecs to respond to the
> interrupt.

These numbers are much more believable to me.

> 
> Lee
>