23 Mar
2003
23 Mar
'03
11:54 a.m.
Ron,
OK, most import item - if it works, then have a beer and make some
music! There is no reason to get overly concerned about this stuff if
the machine does it's job.
I think your machine is using the newer 'APIC' and 'IO-APIC' type
interrupt controllers. I actually got brave and joined the kernel
developer's reflector to ask some questions about this as I was not sure
(and am still not) about IRQ priorities in this hardware configuration.
To be clear, this is hardware that is part of a newer PC architecture
and is NOT the same as most machines out there in the world. (I.e. -
it's been around for a year now, but it's new, and likely to work well
for most PC uses, but less sure about audio applications.) Don't get
worried, as I know a number of people using it on Pro Tools and doing
fine, although many of them had problems getting it to work well in the
beginning.
Also, I do not have a machine with this hardware to do any testing
on, so I cannot be sure about any of this. We'll just have to figure it
out.
My rudimentary understanding of this configuration is that the
hardware priority is lowest to highest, except for the normal,
out-of-order issue about IRQs 3-7. Since those are apparently not
assigned on your box, I hope they don't matter.
This would imply, in your case, that one or your SCSI controllers
trumps your RME, and both trump the ICE1712, which I presume is an
on-board sound chip. (16 is before 17 is before 18 is before 19)
I do not 'think' that this will be a big problem as SCSI controllers
are normally pretty well designed and have good buffering.
I'm a bit more concerned about the mouse at IRQ 12 trumping all of
them. This _has_ been a problem on the normal IRQ setup and _could_ be a
problem for you. (I'm just guessing.)
To test this, I'd suggest starting jack using the RME with a buffer
size of 64 and verbose logging, but no recording. I'd then try moving
the mouse around violently. Lots of mouse movement will cause lots of
mouse interrupts, and you'll get an idea how the system is handling all
this interactive load.
If that works, then I'd do the same thing with Ardour doing playback,
but not recording, and see how mouse movements effect it, and then
finally the same while doing recording and playback.
Also, remember that as PC's get fast and faster, and if the interrupt
handler's are written better and better, then it could get to the point
that IRQ order no longer makes a difference. I don't think we're there
yet, but I do think we're getting closer.
Drop me a note if you need some more specific info.
Cheers,
Mark
On Sun, 2003-03-23 at 07:00, R Parker wrote:
Hi,
What do you make of my IRQs, they're not consistent
with what you're describing. Is this some newer bios
aipc feature?
The pci cards begin at 16 with two scsi controlers
sharing interupt 16, at 18 we see a third scsi
controler that isn't the same as the one on 16. It's
just the same driver.
There's an NVIDIA graphics card in an AGP slot, soon
to be replaced with a radeon. Is the NVIDIA the "LOC"
entry?
The scsi HDD controlers, interupt 16, are a lower
interupt than the rme9652 so I'm assuming they recieve
priority over the audio card. I'm guessing two HDD
controlers requesting CPU time slices aren't the most
optimal scenario.
I am comfortable running jackd with larger buffers
because I use an external digital consol and monitor
inputs for studio and control rooms from the consols
inputs. So latency isn't as big an issue for me as it
might be for engineers that don't have external
consols. Reguardless, I'd like to tune this box to its
optimal performance capability.
If the AGP interupt can't be reordered, then I assume
the correct strategy is to use "setpci" or the bios to
adjust latency. Make sense? I'd probably opt for using
"setpci" because it enables resetting latency on the
fly--I intend to do some video work.
I'd be curious to know other people's opinions of my
irq ordering.
bash-2.05b# cat /proc/interrupts
CPU0 CPU1
0: 3729010 3949857 IO-APIC-edge timer
1: 8714 9043 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
12: 206994 212633 IO-APIC-edge PS/2 Mouse
16: 212646 216114 IO-APIC-level sym53c8xx,
gdth
17: 1234920 1245793 IO-APIC-level rme9652
18: 3721 4640 IO-APIC-level sym53c8xx
19: 364290 368882 IO-APIC-level ICE1712,
eth0
NMI: 0 0
LOC: 7678904 7678970
ERR: 0
MIS: 0
ron
--- Mark Knecht <markknecht(a)attbi.com> wrote:
On Sun, 2003-03-23 at 01:59, Jaakko Prättälä
wrote:
__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com What could I do if I can't set irq's in
my bios?
Jaakko,
Hi. First, what machine are you running and what
BIOS does the
machine have? Phoenix? Award? Usually you can set
IRQ's, but often the
settings are hard to find. In my machine it's under
Advanced->PCI
Configuration. Even though I have this feature, I
still recommend that
you should:
1) Remove all of your cards EXCEPT graphics, boot
and look at interrupt
settings. Write them down or save a file somewhere.
2) If you have on-board devices, like sound or LAN,
then you should
attempt (through BIOS if available) to put them on
low-priority
interrupts. (3,4,5,6,7)
3) Add a card, such as your HDSP that drives the
multi-face, on maybe
PCI slot 3, boot the machine, and look at what
interrupt each device is
on. If you get 9 or 10 for the HDSP, then you're in
pretty good shape.
If you do not, then again, set the PCI slot to IRQ 9
if available, or
try a different slot with just the HDSP and no other
cards. (Always
graphics installed, obviously!)
4) Go through this process, adding a single card,
booting, and looking
at which IRQ each card has, until you get your
important sound card/s on
the best IRQs. Again, IRQ order is:
0,1,8,9,10,11,12,13,14,15,3,4,5,6,7
2 does not exist. (Or it's called 'cascade'.)
0,1 & 8 are not available.
9 is best, followed by 10, etc.
10 is as good as 9 if 9 is not used, or only used by
acpi support.
Networking works fine on 3-7.
I hope this helps. Feel free to write directly if
you have other
questions.
Cheers,
Mark
3) NOTE: On my machine, BIOS seems to move the USB
interrupts around as
I chan