[asterisk-dev] Re: Kernel modules => mainline kernel

[Paul Cadach]

Latest versions of TE4xxP allows to daisy-chain timing from single source to 
other cards. And IMHO it should use single interrupt per all ports joined by 
this daisy-chain.


WBR,
Paul.

----- Original Message ----- 
From: "Andrew Kohlsmith" <akohlsmith-asterisk at benshaw.com>
To: <asterisk-dev at lists.digium.com>
Sent: Tuesday, February 13, 2007 4:02 AM
Subject: Re: [asterisk-dev] Re: Kernel modules => mainline kernel


> On Tuesday 13 February 2007 3:00 am, Oron Peled wrote:
>> Q: What is the interrupt rate in this situation?
>> A: Assume a favorable condition: All PRI with one interrupt
>>    per port (with analog lines we would need many more cards).
>
> Let's assume a realistic situation: a quad PRI card with one interrupt per 
> 4
> ports.
>
>>    Number of required cards =~ 1000 / 30 = 34 (assume we have such a PC 
>> ;-)
>>    Number of interrupts = 34 * 1000/sec = 34,000/sec (without counting
>>    the matching context switches on the transmit path).
>
> 1000 / (30 * 4) = 8.3 = 9000 interrupts/sec.
>
> If we can use NFAS on each quad card, that gets us 8.1 cards, and if
> Zaptel/libpri allows us to NFAS multiple cards (I don't see why it 
> wouldn't),
> we would have 8 cards, not 9.
>
> I've long, long been wondering if it's possible to slave additional Zaptel
> cards off of one card, but I haven't the real need for it to go about
> actually implementing a test.  That would certainly eliminate some of your
> arguments here.
>
>> For anyone interested, during kernel 2.2 everybody were talking about
>> zero-copy. Then came the reality check. Zero copy only helped Gigabit
>> ethernet and above. However, the NAPI api that enabled drivers to
>> dynamically switch to polling instead of interrupt per-packet was a
>> major win for many 100Mb drivers (the results were applied to kernel 
>> 2.4).
>
> Yes, and it shot latency right to hell by saving all these interrupts. 
> While
> it might be a solution if we used the high-resolution timers in the later
> kernels, I don't think it would be feasible any other way.
>
> -A.
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>