Re: AW: AW: asterisk 1.11 and chan_misdn

"Birger Harzenetter" <[email protected]>
Newsgroups gmane.linux.isdn.i4l.user
Message-ID <[email protected]>
On Mon, 03 Jun 2013 12:29:15 +0200, Hirschmüller,_Sven  
<Sven.Hirschmueller-Xt/TTPqwsUlWk0Htik3J/[email protected]> wrote:

> Sorry i forgot to add that i'am speaking for misdn_v1 only.

As that was replaced by v2 almost 5 years ago that was indeed not what I  
expected.

> Last time i tried to compile the mISDN sources, as the ones from the  
> kernel tree where outdated or incomplete, i needed to hack the sources  
> and makefile to remove deprecated kernel lock calls as well as checks to  
> outdated header files. (Please don't nail me for the versions.) I also

Or use the fork by Digium or irroot. They both work with at least halfway  
recent kernels.

> I didn't tried to build chan_lcr and mISDNv2 as they missed some  
> features in the past. (Don't know if that changed.)

Which ones?
(Trying to keep the comparison up to date which it may not really be ATM)

> As said DHADI is a performance pig .. the IRQ quote is so high that many  
> mainboards have problems to handle that and you often get the helpful  
> answer from the support crew .. try another PCI slot. Running multiple  
> cards at once can be really difficult. The cards hate IRQ-Share and we  
> hunt a random crash of the system in the moment and i'am afraid that is  
> simply a bug of the cards driver if the system IRQ-Load is reaching the  
> boards capacity.

True stories, but you can reduce the number of IRQs for at least some  
hardware drivers by the use of a module parameter.
But the number of IRQs is not really the issue. The amount of CPU time  
spent in the interrupt handler is.
As every programmer should know it is essential to keep the time spent in  
an interrupt handler as low as any possible and to use other techniques  
like re-scheduling or callbacks if you need more time.
Unfortunately DAHDI has all audio processing DSP routines (echo cancelling  
and conference mixing) done in the interrupt handler. That should be a  
definite no-go IMHO and can indeed cause a lot of trouble.

   Greetings,
     WIMPy
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.