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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tuesday 28 September 2004 09:57 am, Mark Knecht wrote:
> Mark Knecht wrote:
> > brad stafford wrote:
> >> I just tonight switched from the Planet CCRMA RH9 to FC1. The install
> >> was purely from the CDROMs dated 4/25/2004.
> >>
> >> I've seen all the latest posts about interrupts and did the required
> >> reading on the internet. I really managed to get RH9 cleaned up but in
> >> FC1 I'm seeing something a little different. I have a Delta 1010 and I'm
> >> running an AMD Barton 2.6 with 5 PCI slots. The question is what the
> >> heck are IRQ 16 and 22? I moved the sound and ethernet cards around to
> >> get them to 16 and 22 as they used to be eth0 on 21 and ICE1712 on 22. I
> >> have ACPI turned off as a service but don't have a "disable" option in
> >> the BIOS. I did turn off USB support in the BIOS.
> >>
> >> Is 16 like the equivalent of IRQ 3 since it's following 15?
> >>
> >> [brad@mars brad]$ cat /proc/interrupts
> >>            CPU0
> >>   0:      81690    IO-APIC-edge  timer
> >>   1:         75    IO-APIC-edge  keyboard
> >>   2:          0          XT-PIC  cascade
> >>   8:          1    IO-APIC-edge  rtc
> >>   9:          0   IO-APIC-level  acpi
> >>  12:        836    IO-APIC-edge  PS/2 Mouse
> >>  14:      10789    IO-APIC-edge  ide0
> >>  15:        735    IO-APIC-edge  ide1
> >>  16:          0   IO-APIC-level  ICE1712
> >>  22:         21   IO-APIC-level  eth0
> >> NMI:          0
> >> LOC:      81633
> >> ERR:          0
> >> MIS:          0
> >>
> >> I'm getting 5.8 msec latency in JACK with 128 frames/period at 44100 and
> >> 2 periods/buffer. A huge improvement over the 46.1 msec using RH9 with
> >> capabilities.
> >>
> >> Thanks, Brad.
> >
> > Brad,
> >    First I see no reason for you to change anything. If there's no
> > problem to fix, then why make a problem?
> >
> >    Interrupts, in your case, are based on the APIC model. You machine
> > has an APIC (Advanced Programmable Interrupt Controller) as well as one
> > or more IO-APIC chips, so it supports more than the old style 15
> > interrupts. This is not a problem. It should be an advantage, if
> > everything is set up correctly.
> >
> >    My input would be to go with the flow. If one of these days you find
> > that you are getting worse performance, be it xruns or something else,
> > then come back and let's look at the setup of the machine. Until then,
> > be happy. It looks like the results are quite good, right?!?
> >
> > Cheers,
> > Mark
>
> One last little sickening detail I forgot to add before. Sorry for doing
> it now.
>
> In the older 'compatibility model' we knew the 'prioity of the interrupt
> from the interrupt number: 0,1,8,9,10,11,12,13,14,15,3,4,5,6,7. It was
> hardwired.
>
> In the newer 'APIC' model all we know is the interrupt number, not the
> priority. There is a secondary routing table that maps the interrupt
> priority using a vector. The table is visible in dmesg on my machines.
> It probably is on yours also. The meaning of the table is obscure and
> has been covered here before. The 'unfortunate' aspect of the table is
> that there are no generally avaialble tools to allow a system
> administrator to modify the vectors and hence change the priorities of a
> given hardware device. Not sure that matters to most people. I would be
> happier having that capability and hope it will appear one day.
>
> Sorry for chiming in again.
>
> - Mark
Aieeee! And we almost got away clean too! :)

R~
-- 
The Road of Life is paved with Squirrels that couldn't make a decision!

[Index of Archives]     [Linux Sound]     [ALSA Users]     [Pulse Audio]     [ALSA Devel]     [Sox Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux