28 Sep
2004
28 Sep
'04
11:09 p.m.
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