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

[Kai Militzer]

Hello Peter,

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 

I did not write, that I had 24 simultaneous calls. I just said, that all 
tests for the card did not detect any error, but changing the card fixed 
the problem of CRC errors with chan_ss7. Chan_ss7 uses the full 
bandwidth of *one* channel for signaling all the time. Patlooptest does 
not seem to use the full bandwidth

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

This sounds reasonable, but the error happend with the faulty card in 
three different systems. A new card does not have this error. So this 
explanation must be wrong.


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

Are you saying that the digium cards are general a bad quality?

Regards,
Kai

-- 
Kai Militzer                 WESTEND GmbH  |  Internet-Business-Provider
Technik                      CISCO Systems Partner - Authorized Reseller
                              Lütticher Straße 10      Tel 0241/701333-14
km at westend.com               D-52064 Aachen              Fax 0241/911879