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
[EMAIL PROTECTED] D-52064 Aachen Fax 0241/911879
_______________________________________________
--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
