[Asterisk-Users] Re: RAID affecting X100P performance...
Andrew Kohlsmith wrote: On Friday 30 July 2004 19:51, Mike Benoit wrote: Tuning these [PCI latencies] should allow you to give your TDM cards long burst lengths, and make your IDE devices very premptable... I would have figured you want very short burst lengths to prevent any one device from hogging the PCI bus and delaying your VOIP data. IIRC the VOIP traffic is very short anyway (1000 interrupts a second, 8 bit PCM data or 64 bytes of actual VOIP data (sampled at 8000Hz, that's 8 8 bit samples every interrupt) each way... I think. Yes, but by lowering the available time that another device can tie up the PCI bus, you increase the chances that your TDM cards get their interrupts handled very quickly. And since you know that your TDM card interupts are very short (but very frequent), you want a way to prioritize them. So shorten the burst lengths everything else is allowed, and allow your TDM card to tie up the bus whenever it wants. Working with the 2.6 kernel and some of the new stuff by Ingo Molnar, you can actually get interrupt priorities, and the possibility of allowing specific RT threads preempting lower priority interrupts. Basically, to give Asterisk ideal conditions to to echo cancel, you want to make sure that: 1) PCI bus is given to TDM card as soon as possible when it wants to raise an interrupt. 2) Make sure you OS can handle the interrupt soon enough. Use #1 to tune PCI latencies (yes, an IDE or Network event can tie up your PCI bus for many usec, delaying your TDM interrupts). For #2, you have to live with linux-2.4 being good enough, but if your willing to live on the edge, do check out some of the new recent work that's going on around 2.6, mainly driven by the pro-audio users. On a 600Mhz Eden, users are reporting 42us latencies on RT user-space threads. Basically working out to the almost theoretical minimum hardware capabilities. Again - none of these will guarantee asterisk echo-cancel/dropouts will be fixed, but the all work towards giving asterisk the best conditions for it to do what it is trying to do. ___ 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
[Asterisk-Users] Re: RAID affecting X100P performance...
Andrew Kohlsmith wrote: On Friday 30 July 2004 19:51, Mike Benoit wrote: Tuning these [PCI latencies] should allow you to give your TDM cards long burst lengths, and make your IDE devices very premptable... I would have figured you want very short burst lengths to prevent any one device from hogging the PCI bus and delaying your VOIP data. IIRC the VOIP traffic is very short anyway (1000 interrupts a second, 8 bit PCM data or 64 bytes of actual VOIP data (sampled at 8000Hz, that's 8 8 bit samples every interrupt) each way... I think. Yes, but by lowering the available time that another device can tie up the PCI bus, you increase the chances that your TDM cards get their interrupts handled very quickly. And since you know that your TDM card interupts are very short (but very frequent), you want a way to prioritize them. So shorten the burst lengths everything else is allowed, and allow your TDM card to tie up the bus whenever it wants. Working with the 2.6 kernel and some of the new stuff by Ingo Molnar, you can actually get interrupt priorities, and the possibility of allowing specific RT threads preempting lower priority interrupts. Basically, to give Asterisk ideal conditions to to echo cancel, you want to make sure that: 1) PCI bus is given to TDM card as soon as possible when it wants to raise an interrupt. 2) Make sure you OS can handle the interrupt soon enough. Use #1 to tune PCI latencies (yes, an IDE or Network event can tie up your PCI bus for many usec, delaying your TDM interrupts). For #2, you have to live with linux-2.4 being good enough, but if your willing to live on the edge, do check out some of the new recent work that's going on around 2.6, mainly driven by the pro-audio users. On a 600Mhz Eden, users are reporting 42us latencies on RT user-space threads. Basically working out to the almost theoretical minimum hardware capabilities. Again - none of these will guarantee asterisk echo-cancel/dropouts will be fixed, but the all work towards giving asterisk the best conditions for it to do what it is trying to do. ___ 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 ___ 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
Re: [Asterisk-Users] Re: RAID affecting X100P performance...
On Friday 30 July 2004 20:26, Aidan Van Dyk wrote: Yes, but by lowering the available time that another device can tie up the PCI bus, you increase the chances that your TDM cards get their interrupts handled very quickly. And since you know that your TDM card interupts are very short (but very frequent), you want a way to prioritize them. So shorten the burst lengths everything else is allowed, and allow your TDM card to tie up the bus whenever it wants. Yup I read the article and I understand what he's doing now. Nice little bit of information to have onhand. Regards, Andrew ___ 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
[Asterisk-Users] Re: RAID affecting X100P performance...
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 ___ 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
[Asterisk-Users] Re: RAID affecting X100P performance...
Scott Laird wrote: In the context of Asterisk, where disk I/O is either logging or voicemail, buying a 3ware card and a pair of IDE drives seems like a decent business decision. I agree. Even more to the point, when using T100P's which need high quality, fast service from the CPU and the host bus, I would recommend putting your RAID in a separate box. Any cheap MOBO with a raid card, software raid, onboard raid controller, etc., should suffice since the only thing it will be doing is RAID and the maximum I/O rate will be 10MB per second or so, limited by the ethernet speed. If you use internet for a voice channel, make sure that you use a separate NIC to talk to the RAID, and assign it a lower interrupt priority than those used by the telephony hardware. 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
