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