--- Mark Knecht <mknecht(a)controlnet.com> wrote: My recolector is awful faulty but I seem to recall Clemens Ladisch having written something for APIC interupt ordering. Is my condition even worse than I'm aware of? ron __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail

Mark Knecht wrote: What I tried to explain was that the priority is not determined by the interrupt number but by the interrupt vector number. Well, let's see if my explanation isn't too muddy this time :-) The routing of interrupts from the hardware to the driver happens on three levels. First, there are the (PCI) interrupt lines, which are the input pins of the interrupt controller chip. These are usually called PIRQA/B/C... The only way to choose the interrupt line for the sound card is to put it into another PCI slot. The interrupt line of integrated devices is usually fixed. The interrupt controller (PIC or I/O-APIC) has a number of hardware interrupts (PIC 16, I/O-APIC 24? or more). Each interrupt line is mapped to one interrupt. In PIC mode, the routing of interrupt line to interrupt number can be chosen by software (but is done by the BIOS in practice). In I/O-APIC mode, the routing of interrupt lines to interrupts is fixed: each PCI interrupt line gets one of the interrupts above 15. These are the interrupt numbers shown in /proc/interrupts. The interrupts are mapped to interrupt vectors. Intel CPUs have 256 of them, but some are used for other purposes than hardware interrupts. The interrupt vector numbers are chosen by the Linux kernel, and are fairly well hidden, but you can find them in the dmesg output if I/O-APIC is enabled. When the I/O-APIC is not enabled, interrupt priority is determined by the interrupt number (0 1 8 9 10 11 12 13 14 15 3 4 5 6 7). When the I/O-APIC is enabled, interrupt priority is determined by the interrupt vector number (lower vectors numbers have higher priority). (My patch to change vector numbers doesn't work with current kernels.) Regards, Clemens

Last Friday 16 July 2004 18:08, Mark Knecht was like: Slight side issue, while you guys are on the subject. I have my soundcard (an onboard i8x0) sharing an interrupt (IRQ 11) with eth0 and usb-uhci. Would this be likely to give rise to xruns in a similar way? I'd kind of resigned myself to this situation until such time as I upgrade my hardware. Could any of the things you're discussing be applied to move eth0 and usb-uhci to a lower priority, or is it just a question of physically moving the ethernet card? It seems like some dumb corner cutting exercise, as the box was clearly only ever intended for office use. If you find this problem remotely interesting, I'd value any suggestions. cheers tim hall

On Sat, 2004-07-17 at 06:33, Malcolm Baldridge wrote: It may take a few tries to get everything where you want it though. In addition to the time to determine interrupt source there is another problem with shared interrupts - don't use any USB devices or run your network while trying to record. Jan

Speaking of disagreements, I've seen two groups of thought on using 'hdparm' to speed up a hard drive. What is the final verdict? chaz ----- Original Message ----- From: "Clemens Ladisch" <clemens(a)ladisch.de> To: "A list for linux audio users" <linux-audio-user(a)music.columbia.edu> Sent: Friday, July 16, 2004 12:06 PM Subject: Re: [linux-audio-user] APIC is bad?

Quoting tim hall <tech(a)glastonburymusic.org.uk>uk>: If your kernel does not choose an appropriate Bus Mastering tuning parametre for the hard disk drive, it is vital you tune the IDE drivers to at least use Bus Mastering DMA and to release IRQs earlier with -u1. As for whether it's worthwhile or not to setup -m16 (as 99% of the modern HDDs support), that is more debatable. At the very least, the following will tune your IDE driver to make use of Bus Mastering DMA, early-release of IRQs, and to ensure 32-bit I/O access [a nebulously and under-documented function]: hdparm -u1 -c1 -d1 /dev/hda Where we leave the realm of easily verifiable results is whether or not to extend the above hdparm command to: hdparm -u1 -c1 -d1 -m16 /dev/hda I don't see any (large) improvements in hdparm -t -T /dev/hda benchmarks, for example. I've seen throughput benchmarks slightly improve with low -m settings, like -m1 and -m8 Since this is a multi-sector transfer unit setting, it's conceivable that a large blast of contiguous sector reads/writes could hold off further device channel commands and thereby "block" other read/writes queued up behind the drive. It's possible. But keep in mind that 16 sectors sounds like alot, but in UDMA-100 time, that's 0.08ms of time on the wire per transfer unit. Even assuming the drive has to wait for the sectors to arrive or empty out of cache, and lets assume the drive's a slow dog, 20Mbytes/second, that's still only 0.4ms of time per atomic transfer unit. If you're "on the borderline" with xruns, you might gain something by tuning your IDE driver with a smaller or larger -m setting. Try -m1, -m4, -m8, or -m16. Finally, this may sound weird and voodoo, but make sure your IDE cables aren't too twisted or molested. Cable CRC errors do happen and they cause abrupt transfer speed aberrations. If you install smartmontools (S.M.A.R.T. drive logging/diagnostic tool), you can inquire of cabling CRC errors and note whether or not you seem to be getting alot of them in your system. I have yet to meet a post-440FX (Pentium era) chipset whose Linux IDE driver 'sperformance was not radically improved with a massive reduction in CPU utilisation during heavy disk I/O when the IDE driver was tuned with -c1 -u1 -d1 versus one which was NOT tuned. -c1 may not provide any tangible benefit, but -d1 definitely does, and -u1 gets you released from IRQ-hold-off states within the driver a bit earlier. Modern kernels built with specific IDE chipset support are doing a better job of configuring these with good defaults. Verify it with: hdparm -v /dev/hda If anyone tells you -d0 is a better tuning, I would be extremely skeptical. There are some wickedly buggy chipsets out there, but most of the really vile ones aren't in systems you're likely to use for a DAW. By the way, all of the above only applies to IDE drives. SCSI drives don't need any of this hand-waving. =MB= -- A focus on Quality.

Quoting Joe Button <linux-audio-user(a)joebutton.co.uk>uk>: I should hope not. The tuning shouldn't be seen as a "feature" per se, but rather a dim reflection of the miserable state of affairs that is/was IDE. Chipset timing issues, legacy polled-mode nonsense have been a thing of the past even for parallel IDE, but the Linux IDE driver and accompanying mindset reflects a conservative (paranoid?) focus which was probably quite justified given the very real risks of severe data loss. hdparm works fine with SCSI, but you are constrained in what you can change. Write-protection and things like driver read-ahead and maybe write caching (on the drive controller). That's about it. It's possible the SATA Linux drivers don't support the ioctls hdparm uses. Make sure your hdparm is a recent version. Tuning driver read-ahead and write-caching are still reasonable functions for system administrators to control. The rest of the IDE stuff shouldn't apply to SATA unless the standards committees have done a real botched job of things. =MB= -- A focus on Quality.

Tim, You do have to be careful with it. You can fry your drive. {At least you can get it hot enough that it starts beeping at you. I imagine frying would be the next step.} ... This message has been brought to you in part by a grant from Columba.

Florin Andrei wrote: As per Clemens' note this is complicated. I'm not sure I understand your feedback about 'suffers from more overlapping'. Could you post the output of /proc/interrupts for the same machine configuration with IO-APIC and old style interrupts? One other 'misdirection' you may run into here is that many motherboards will tie together the interrupt line from multiple PCI slots to a single wire and run that line to the interrupt controller. This was very common with the older style interrupts and would show up as two or more devices sharing an interrupt. The only way around this with the older machines was to move boards around. With the newer IO-APIC machines the interrupt controllers have more inputs and there is generally less reason for motherboard designers to tie these together, but I have heard that they are still tied together on certain motherboards. (I don't know if this is true...I've just heard it.) Therefore it might still happen that someone (you?) would see shared interrupts because fo the way the motherboard is designed. The info is often in the motherboard manual, or at least it alway is for Via-based motherboards. I have one non-audio nForce2 box but it's running in traditional mode: mark@gandalf mark $ cat /proc/interrupts CPU0 0: 112390402 XT-PIC timer 1: 126469 XT-PIC keyboard 2: 0 XT-PIC cascade 5: 1336833 XT-PIC NVidia nForce2, eth0 8: 2 XT-PIC rtc 9: 0 XT-PIC acpi 10: 68038461 XT-PIC ohci1394, ehci_hcd, usb-ohci, usb-ohci, nvidia 11: 2188451 XT-PIC ide2 12: 10755041 XT-PIC PS/2 Mouse 14: 3 XT-PIC ide0 NMI: 0 ERR: 0 As always, I think this is an interesting topic being that I'm a PC hardware guy. I cannot imagine why too many musicians would want to go through all of this though! Good luck! - Mark

Florin Andrei wrote: You could try to move the SB card to a PCI slot using one of the free interrupts (18, 22). The slot <-> interrupt assignment should be listed in your motherboard manual. (In the usual routing scheme, the next higher-numbered slot should use interrupt 18.) HTH Clemens