Subject: Re: [linux-audio-user] Is everyone sick of interrupts yet?
From: Mark Knecht (mknecht_AT_controlnet.com)
Date: Wed Sep 29 2004 - 16:55:02 EEST
Lee Revell wrote:
> On Tue, 2004-09-28 at 20:52, Mark Knecht wrote:
>
>>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.
>
>
> Oops, sorry, I meant microseconds. I was actually looking at a trace
> when I wrote this, and Ingo's tracer prints milliseconds, and I screwed
> up the conversion. It looks like 2-3 usecs to determine where the
> interrupt came from if two devices share an irq.
>
> Lee
>
>
Thanks Lee. That's very compatible with my back-of-the-envelope
calculations. However, I believe that number assumes that the leading
interrupt device is not interrupting and you only had to determine that
the real interrupt came from the sound card. Assuming a shared
interrupt, and assuming that a USB controller is the first and the sound
card is the second device, what delay is encountered by the sound card
when both devices interrupt at the same time?
I understand that there is probably a few microseconds extra delay as
the system determines that there are two interrupt devices pending. How
long is it, however, before the UCB interrupt handler does all it's work
and hands off to the sound card interrupt handler (or sound card driver)
so that it can get started?
I grant you that this will should not amount to 500uS worth of delay,
but then we need to add in the possibilities of other, higher priority
interrupts coming along during that window and further delaying the
sound card getting it's work don before the Jack frame runs out.
For me this is not a mere curiosity. Yesterday I brought up FC2 and
then, with much help from Steve Harris and Fernando, got a new Planet
kernel installed. No sooner than I had started Jack I then started using
my USB mouse and getting huge xruns. Since USB is shared with the sound
chip I think it's an example of what we ae talking about here.
to be clear I do not think the results are completely valid as the
machine has not yet been optimized, it's running KDE, arts is trying to
start at odd times, etc., but clearly there was a relationship between
my mouse and my xruns.
(Some xruns were on the order of 100-500mS!! This cannot be truly
real...I hope)
Thanks much,
Mark
This archive was generated by hypermail 2b28 : Wed Sep 29 2004 - 16:58:10 EEST