5 Mar
2004
5 Mar
'04
10:11 a.m.
Hi all,
This has been discussed briefly before:
http://www.music.columbia.edu/pipermail/linux-audio-user/2003-March/002834.…
It used to be possible (in the 2.0 kernel series) to the rotate priority of
IRQs on the two controllers. This sounds really good as on my laptop the
soundcard is welded to IRQ5 (very low priority) and everything else is on
IRQ10 (higher, c.f. http://myweb.cableone.net/eviltwin69/Arcana.html sec
2.4), so I can only run the card with big buffers.
The tool used to do the rotation was irqtune:
http://cae.best.vwh.net/irqtune/
I'm downloaded it, hacked it to work with 2.4, but it doesnt seem to do
anything (no errors, but no action either AFAICT). I'm wondering if somene
here knows enough about the kernel to have a clue why its not doing
anything. I can mail a patch to anyone whos interested, but as I said it
doesnt work at the moment.
I'm replacing this laptop soon, so its mostly academic interest, but it
might have been of use to someone.
Possibly something similar can be done with APIC, but it didn't seem to
work very well on this machine last time I tried.
- Steve
5 Mar
5 Mar
12:14 p.m.
On Fri, Mar 05, 2004 at 03:06:27PM +0000, Steve Harris wrote:
It used to be possible (in the 2.0 kernel series) to
the rotate priority of
IRQs on the two controllers. This sounds really good as on my laptop the
soundcard is welded to IRQ5 (very low priority) and everything else is on
IRQ10 (higher, c.f. http://myweb.cableone.net/eviltwin69/Arcana.html sec
2.4), so I can only run the card with big buffers.
This really mattered? I'm honestly DEEPLY surprised, and a bit sceptical.
IRQ priority will only matter AT ALL if you are in a constant state of
interrupt, or your IRQ handlers are painfully slow, neither of which should
be true.
DMA ATA mitigates IRQ storms a LOT, and you shouldn't be flooding the net
while you play low-latency audio. Those are the two biggest sources of
IRQs.
Curious to see how it changes with a new laptop..
1:36 p.m.
On Fri, Mar 05, 2004 at 09:09:31AM -0800, Tim Hockin wrote:
On Fri, Mar 05, 2004 at 03:06:27PM +0000, Steve Harris
wrote:
Heres /proc/interrupts after ~3 hours of uptime.
CPU0
0: 12578480 XT-PIC timer
1: 22347 XT-PIC keyboard
2: 0 XT-PIC cascade
5: 0 XT-PIC Maestro3
8: 1 XT-PIC rtc
10: 58915 XT-PIC usb-uhci, ohci1394, eth0, Texas
Instruments PCI4451 PC card Cardbus Controller, Texas Instruments PCI4451
PC card Cardbus Controller (#2)
11: 774663 XT-PIC nvidia
12: 28909 XT-PIC PS/2 Mouse
14: 16635 XT-PIC ide0
NMI: 0
ERR: 0
Everything beats the soundcard, including the video drivers.
- Steve
It used to be possible (in the 2.0 kernel series)
to the rotate priority of
IRQs on the two controllers. This sounds really good as on my laptop the
soundcard is welded to IRQ5 (very low priority) and everything else is on
IRQ10 (higher, c.f. http://myweb.cableone.net/eviltwin69/Arcana.html sec
2.4), so I can only run the card with big buffers.
This really mattered? I'm honestly DEEPLY surprised, and a bit sceptical.
IRQ priority will only matter AT ALL if you are in a constant state of
interrupt, or your IRQ handlers are painfully slow, neither of which should
be true.
2:08 p.m.
On Fri, Mar 05, 2004 at 06:30:58PM +0000, Steve Harris wrote:
It shows that your soundcard had ZERO interrupts. I have trouble believing
that over the course of THREE HOURS it tried and tried and could not get a
single interrupt through. Is that what you're saying?
This does not show a particularly high interrupt load, either. It does show
that you get about 70 video interrupts per second (ask nvidia!) and it shows
that you seem to have the timer at 1024 HZ (lowlatency patch?).
This really
mattered? I'm honestly DEEPLY surprised, and a bit sceptical.
IRQ priority will only matter AT ALL if you are in a constant state of
interrupt, or your IRQ handlers are painfully slow, neither of which should
be true.
Heres /proc/interrupts after ~3 hours of uptime.
CPU0
0: 12578480 XT-PIC timer
1: 22347 XT-PIC keyboard
2: 0 XT-PIC cascade
5: 0 XT-PIC Maestro3
8: 1 XT-PIC rtc
10: 58915 XT-PIC usb-uhci, ohci1394, eth0, Texas
Instruments PCI4451 PC card Cardbus Controller, Texas Instruments PCI4451
PC card Cardbus Controller (#2)
11: 774663 XT-PIC nvidia
12: 28909 XT-PIC PS/2 Mouse
14: 16635 XT-PIC ide0
NMI: 0
ERR: 0
Everything beats the soundcard, including the video drivers.
3:40 p.m.
On Fri, Mar 05, 2004 at 11:03:46 -0800, Tim Hockin wrote:
No, I hadn't used the ALSA modules :) The interrupts get through unless
I use < 2048 samples / period, if I do ALSA reports lost interrupts
constantly.
CPU0
0: 12578480 XT-PIC timer
1: 22347 XT-PIC keyboard
2: 0 XT-PIC cascade
5: 0 XT-PIC Maestro3
8: 1 XT-PIC rtc
10: 58915 XT-PIC usb-uhci, ohci1394, eth0, Texas
Instruments PCI4451 PC card Cardbus Controller, Texas Instruments PCI4451
PC card Cardbus Controller (#2)
11: 774663 XT-PIC nvidia
12: 28909 XT-PIC PS/2 Mouse
14: 16635 XT-PIC ide0
NMI: 0
ERR: 0
Everything beats the soundcard, including the video drivers.
It shows that your soundcard had ZERO interrupts. I have trouble believing
that over the course of THREE HOURS it tried and tried and could not get a
single interrupt through. Is that what you're saying? This does not show a particularly high interrupt load,
either. It does show
that you get about 70 video interrupts per second (ask nvidia!) and it shows
that you seem to have the timer at 1024 HZ (lowlatency patch?).
You get one per screen refresh dont you?
- Steve
4:59 p.m.
On Fri, Mar 05, 2004 at 08:35:06PM +0000, Steve Harris wrote:
Not on my system :) Many systems don't even have an IRQ for video. What
would the video IRQ need every refresh? You're not punping data there
constantly unless the screen is changing..
No, I hadn't used the ALSA modules :) The
interrupts get through unless
I use < 2048 samples / period, if I do ALSA reports lost interrupts
constantly.
hrrmm...I doubt if it is due to IRQ priorities. I mean, really, any modern
CPU can handles 10s or 100s of thousands of IRQs per second..
This does not
show a particularly high interrupt load, either. It does show
that you get about 70 video interrupts per second (ask nvidia!) and it shows
that you seem to have the timer at 1024 HZ (lowlatency patch?).
You get one per screen refresh dont you?
5:25 p.m.
On Fri, Mar 05, 2004 at 01:54:00 -0800, Tim Hockin wrote:
Not on my system :) Many systems don't even have an IRQ for video. What
would the video IRQ need every refresh? You're not punping data there
constantly unless the screen is changing..
Heh, shows what I know about video :)
- Steve
On Fri, Mar 05, 2004 at 08:35:06PM +0000, Steve Harris
wrote:
Hm... ok. I dont think its a s/w problem FWIW, other people I know with
the same machine (dell i8100) have the same problem.
No, I hadn't used the ALSA modules :) The
interrupts get through unless
I use < 2048 samples / period, if I do ALSA reports lost interrupts
constantly.
hrrmm...I doubt if it is due to IRQ priorities. I mean, really, any modern
CPU can handles 10s or 100s of thousands of IRQs per second.. This does not show a particularly high interrupt load,
either. It does show
that you get about 70 video interrupts per second (ask nvidia!) and it shows
that you seem to have the timer at 1024 HZ (lowlatency patch?).
You get one per screen refresh dont you?
5:55 p.m.
On Fri, Mar 05, 2004 at 10:19:47PM +0000, Steve Harris wrote:
Interesting problem - not sure how I'd attack it...
hrrmm...I
doubt if it is due to IRQ priorities. I mean, really, any modern
CPU can handles 10s or 100s of thousands of IRQs per second..
Hm... ok. I dont think its a s/w problem FWIW, other people I know with
the same machine (dell i8100) have the same problem.
6 Mar
6 Mar
6:19 a.m.
On Fri, Mar 05, 2004 at 02:50:09 -0800, Tim Hockin wrote:
On Fri, Mar 05, 2004 at 10:19:47PM +0000, Steve Harris
wrote:
Interesting problem - not sure how I'd attack it...
No, me niether, thats why I lived with it for 2 years, it could be that
theres something wring with the card or driver ofcourse, but I still think
its interrupt related.
- Steve
hrrmm...I
doubt if it is due to IRQ priorities. I mean, really, any modern
CPU can handles 10s or 100s of thousands of IRQs per second..
Hm... ok. I dont think its a s/w problem FWIW, other people I know with
the same machine (dell i8100) have the same problem. 
12:14 a.m.
On Friday 05 March 2004 16:03, Tim Hockin wrote:
On Fri, Mar 05, 2004 at 06:30:58PM +0000, Steve Harris
wrote:
It shows that your soundcard had ZERO interrupts. I have trouble believing
that over the course of THREE HOURS it tried and tried and could not get a
single interrupt through. Is that what you're saying?
The soundcard having zero interrupts seems strange to me..
unless he didnt use it at all?
This
really mattered? I'm honestly DEEPLY surprised, and a bit
sceptical. IRQ priority will only matter AT ALL if you are in a
constant state of interrupt, or your IRQ handlers are painfully slow,
neither of which should be true.
Heres /proc/interrupts after ~3 hours of uptime.
CPU0
0: 12578480 XT-PIC timer
1: 22347 XT-PIC keyboard
2: 0 XT-PIC cascade
5: 0 XT-PIC Maestro3
8: 1 XT-PIC rtc
10: 58915 XT-PIC usb-uhci, ohci1394, eth0, Texas
Instruments PCI4451 PC card Cardbus Controller, Texas Instruments PCI4451
PC card Cardbus Controller (#2)
11: 774663 XT-PIC nvidia
12: 28909 XT-PIC PS/2 Mouse
14: 16635 XT-PIC ide0
NMI: 0
ERR: 0
Everything beats the soundcard, including the video drivers. This does not show a particularly high interrupt load,
either. It does
show that you get about 70 video interrupts per second (ask nvidia!)
That's probably the vblank interrupt, used to sync the contents
of the screen to avoid "paging" effect.. (though doesnt seem
like xfree honors it hehe).. so i guess that can be considered normal too..
reduz
7362
days inactive
7363
days old
linux-audio-dev@lists.linuxaudio.org
9 comments
3 participants
participants (3)
-
Juan Linietsky -
Steve Harris -
Tim Hockin