[asterisk-ss7] Strange interrupt issue with zaptel and chan_ss7

[Michael D Schelin]

We had timing slips when receiving faxes. In Linux we adjusted the 
priority levels for the devices like the cards and the Hard Drive. 
Problem solved.

P.B. wrote:
> The card does not behave any different if all channels are idle or if 
> all channels are used - In fact the card can not even tell the 
> difference. The driver reads and writes audio samples on free and on 
> used channels no matter what. The difference between no calls and 24 
> simultaneous calls is the processor load of the system. With the 
> processor load also interrupt latency increases - not linearly though. 
> So depending on the cards buffer, if the card is not being serviced in 
> time, frame slips occur and audio and/or hdlc frames are lost.
> If another interrupt is being handled (keyboard, harddisk, ethernet) it 
> will be serviced and will further increase interrupt latency, sometimes 
> to the point where a buffer overrun (slip) occurs.
> 
> The strange behavior between P4 and AMD could be because of slightly 
> different bus timings on the PCI bus and a faulty card which barely made 
> the pci specs.
> 
> m.f.G.
> Peter
> 
> Kai Militzer wrote:
>> Hello everyone,
>>
>> I solved my problem, so I tought I give you an update.
>>
>>> Then finaly I came across the behavior that puzzles me. Asterisk was 
>>> running with two instances over the crosslink and the console screen 
>>> was blanked on the console. So I wanted to press Shift to unblank it, 
>>> but accidently pressed the CapsLock key. When the screen was 
>>> unblanked and I  started to type, I realized, that CapLock was on. I 
>>> pressed it again and in this moment, I got a CRC16 error. I thought 
>>> that was strange and pressed it again twice, and there it was again, 
>>> Packets from the zaptel driver to chan_ss7 got lost. The same 
>>> behavior happens, when I press ScollLock or NumLock. The Keyboard 
>>> runs on interrupt 1 and the TE205P on IRQ11, so there shouldn't be 
>>> any impact when the keyboard uses this interrupt.
>>
>> I got the card interchanged with a new one from my distributor. With 
>> the new card, the problem does not exsists. So the reason for the 
>> strange behavior was a faulty hardware. That's OK, things like that 
>> can happen, but what I cannot understand is, that the tests shipped 
>> with the zaptel source did not detect it.
>>
>> If I understand correctly patlooptest should reveal problems with bad 
>> cards, but it went through without problems on my faulty card. I think 
>> the problem is, that the error I had only surfaced, when a channel in 
>> the span was completely used (i.e. the complete bandwith of 64kbit is 
>> used by the signaling channel for SS7). I think that patlooptest does 
>> not use the full bandwith of a channel and therefore does not detect 
>> the error and it tests only one (the first) channel of a span. As I am 
>> not a developer and my C knowledge tends to zero, I am not sure, if my 
>> claim is right. But if it is, zaptel IMHO needs a test, that uses the 
>> full bandwith of more than one channel to detect faulty cards.
>>
>>
>> Best regards,
>> Kai
>>
> 
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
> 
> asterisk-ss7 mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-ss7
> 
>