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 >
