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

Tzafrir Cohen tzafrir.cohen at xorcom.com
Tue Feb 13 05:26:42 MST 2007


On Tue, Feb 13, 2007 at 07:02:17AM -0500, Andrew Kohlsmith wrote:
> 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.

Still not grand. 

And how will you connect analog channels to your PBX? why? connect an
external channel bank through PRI, right? And why not add an extra
local interface? Is it due to the high load of interrupts generated?

You here that sort of recommendation as an argument on why one should
not install three TDM400P cards.

> 
> 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.

But if your main usage is PRI => VoIP, the extra 10ms would not be that
critical. Chances are you have longer delays anyway.

-- 
               Tzafrir Cohen       
icq#16849755                    jabber:tzafrir at jabber.org
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com       
http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir


More information about the asterisk-dev mailing list