[Asterisk-Users] Re: RAID affecting X100P performance...

[Stephen R. Besch]

> 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.
> 
> I'll run the same tests you did and report back with the results.
> 
Unless I read the manual correctly, it is not possible to have the 
configuration you specify without shared interrupts on this motherboard 
(Asus A7V266E):

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