AW: AW: AW: asterisk 1.11 and chan_misdn

Hi Guy,

sorry for hijacking the thread but i guess that may be interesting for others also.

>>
>> 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 you saw my experiences are quite aged but in that time we had following issues.

1) Lcr had high latency in audio transmission that made the use of FAX machines difficult.
2) Attempts to establish a ISDN-PPP dial in connections via "app_pipe" didn't succeed. (Guess No. 1 was the problem as we got trillions of corrupted packages.)
3) Hold/Retrieve didn't worked reliable not to say crashed reliable .)
4) Bearer-Capabilities couldn't be set.
5) Key-Pad/DTMF hick-ups.
6) Stability issues (most likely gone.)
7) Caller-ID, Called-Party-No got mixed up.

I guess that were the most problematic ones and we needed to get PPP dial in connections via asterisk running. (Not needed anymore on our side.)

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

Yes i can support that statement. Our system load with Digium hardware is 2.0 even though the CPU, IO, Sys and Mem (iowait is 0.0) allocation is 0.01%..with about 5k IRQs. the joke is that the same setup with openvox cards runs with 0.01% load. Who understands linux load indication :) The only idea i had is that tons of crunching power is used in the IRQ handlers. 

Still i want to be fair .. the Digium stuff worked out of the box, the building of the driver is very smooth. You can see that they invested quite some time in the makefile and configure scripts and the handling of the cards is quite easy. It's really nearly plug and pray. As long as you stays with Digium hw and don't want to use multiple cards at once. The openvox version of the driver quite regularly misses to initialise one of the cards (guess thats a udev issue) and crashes always if you try to unload it. I come to live with that as the mISDN stuff did that also. I also need to hack it to set a second card installed to different nt/te settings then the first one.

I would like to run a new test with mISDNv2 and lcr but i guess my colleagues and boss will shoot me if i suggest another test run with mISDN as we had so many problems to get them running in the past.

G.
Sven