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

Aidan Van Dyk aidan at highrise.ca
Fri Jul 30 17:26:36 MST 2004


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. 



More information about the asterisk-users mailing list