[Asterisk-Users] How many X100P's in a system..

Robert Hajime Lanning lanning+asterisk at monsoonwind.com
Thu May 22 17:23:18 MST 2003


<quote who="Steven Critchfield">
> On Thu, 2003-05-22 at 17:18, asterisk at sasami.anime.net wrote:
>> On Thu, 22 May 2003, Robert Hajime Lanning wrote:
>> > I would expect, one of the issues would be latency.  Shared IRQs
>> introduce
>> > additional latency for service on that IRQ.
>>
>> When you have multiple cards in a system, shared IRQs are often more
>> efficient than single ones. Since you can service multiple cards in a
>> single
>> interrupt.
>>
>> It would thus be an advantage for a busy system with multiple x100p's.
>> That is, if the x100p actually supported irq sharing to pci spec.
>>
>> I dont think a few hundred extra cycles out of 1billion+/sec (eg most
>> modern systems) is going to incur any noticeable latency in any case.
>
> It would seem in this case, that if the X100Ps could stack on a IRQ,
> then only 1 card needs generate interupts, and the rest of the cards
> could get serviced at the same time.
>
> Just a thought, I'll probably be told why I am wrong by someone with
> knowledge of how this would fail.
> --
> Steven Critchfield  <critch at basesys.com>

Well I guess it comes down to, "If all cards need service at the time
of the interrupt, then there could be savings" .vs "If only one card needs
service at the time of the interrupt, then ALL cards on that interrupt
will still need to be polled.  The CPU/Kernel does not know who triggered
the interrupt."

Just depends on how much latency (for polling all the cards) is viable.
With the TDM backplane implemented as a kernel module, how long do you want
to spend servicing interrupts.  (Linux is not pre-emptive, yet.)

Interrupt routines need to do just what is required to keep proper kernel
state, then return ASAP.  Interrupts are suppressed while in an interrupt
handler.

Shared IRQs are just bad.  Just the PC hardware does not have enough IRQs
to handle all the devices we want to connect to them, nowadays.

-- 
END OF LINE



More information about the asterisk-users mailing list