I am. My system is a Duron 1200 with an Asus A7V266 board. I have an Athlon XP 2200 that I was planning on upgrading to. I am using the onboard IDE channels; the only cards in the server are video, ethernet, and two X100P's. No IRQ sharing. Three drives in RAID5; two of the drives are master/slave on one channel, the other shares a channel with a CD drive.Unless I read the manual correctly, it is not possible to have the configuration you specify without shared interrupts on this motherboard (Asus A7V266E):
I'll run the same tests you did and report back with the results.
Slot1: uses INTD, which is shared with the RAID, USB and slot 5 Slot2: uses INTA, Shared with AGP, onboard audio and onboard LAN Slot3: Uses INTB, Shared with AGP Slot4: Uses INTC, The only unshared slot Slot5: Uses INTD, Shared with slot 1, RAID and USB
Looking at the manuals for several other MOBO's, similar results situation seem to exist. My guess is that Slot1 contains one of your X100P's, so when the RAID is enabled, interrupt response time goes into the toilet. The point is, as long as motherboard manufacturers are going to take the easy (lazy?) way out, and share slot interrupts with each other and with other hardware, you are pretty much stuck with not putting your RAID on the same box as the X100P.
Something which seems never to be considered about echo is the nature of the true echo path. It obviously includes the delay over the analog wire, if there is one, plus the sum of all the packet delays on the network. What is forgotten is that it also includes the delay through the CPU, which, in turn includes the delay through the cancellation process. If the delay is always constant, cancellation becomes much more straightforward. For any real world echo canceller to work, it must be able to adapt to variable delays. The problem is, that if the delay adaptation response is too fast, cancellation becomes unstable, if it is too slow, cancellation is not effective.
Now, look at the problem the T100P suffers as part of the echo cancellation stream. Each time it needs service, the time to be serviced changes based on random fluctuations in interrupt service time, even if the interrupt is given highest priority (i.e., a low interrupt number). Typically, this fluctuation is not too bad, at least in terms of the requirements of echo cancellation. Now, put a shared interrupt on the T100P. Even worse, you assign it to share with a disk controller, which by definition should be given a low priority (that's why the IDE interrupts are always 14 and 15!) You have now just put horrific delay fluctuation in the cancellers path. Everything gets priority, including the disk if you are unlucky. These wild, and large, fluctuations in delay will kill any echo canceller, no matter how good it is - the exception of course being an independed canceller that processes the echo before it even gets to the X100P and the asterisk box.
Similar logic applies to the network card, since it also lies in the cancellation stream and it's interrupt response time can significantly affect path delay.
The solution? Well, I'm guessing here, but you might be able to get a big improvement by using the one unshared interrupt for the X100P, use a PCI video card to free up two of the shared slots and put the second X100P in slot 3. Finally, put your lan (if it's not onboard) into slot2. Finally, and this may be the most important thing, don't let the motherboard automatically assign interrupts to IntA-IntD. Go into the BIOS and force it to assign the highest priorities available to the T100P and the net card. Also, disable any unused hardware you're not using which may have an interrupt assigned (eg, the USB controller). For the ASUS at least, the priorities assigned to the interrupts are listed in a table in the user manual (p32).
Stephen R. Besch _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
