[asterisk-dev] Zaptel Interrupt Issues

[Eric "ManxPower" Wieling]

I'll bet his Zaptel has been patched by the Sangoma Wanpipe stuff.

Matthew Fredrickson wrote:
> Bob wrote:
>> The newer channelized DMA schemes that are used in zaptel drivers are
>> handing one chunksize of data directly from the hardware to the copy_to_user
>> -- I believe. In my testing anyhow, I have turned off most of the other
>> processing in zaptel (EC). The only other processing that I see going on
>> there is the table lookups for the 711 codec.
> 
> That is incorrect, unless you are using a version of zaptel that I am 
> not using.  The way zaptel works is that when a driver has received 
> ZT_CHUNKSIZE worth of DMA data, it calls zt_receive() which puts the 
> data into the ringbuffers within zaptel.
> 
> Something similar happens in the transmit direction as well.
> 
>> I have placed a flag bit in the ISR's when testing, and attached that bit to
>> a logic analyzer. The logic analyzer is also attached to the chipset and
>> running a dissasembler. Interrupt latencies are impressively low. Not only
>> have I never seen an ISR being missed, I have never seen one not complete in
>> the first %10 of the duty cycle. This is true even for quad T1 cards.
>>
>> I've written pattern generators / pattern detectors and put them in-line
>> with the copy_to/from_user in zaptel.c and I have never seen a data bit lost
>> in the kernel. I've done likewise with patlooptest, chan_zap, and other
>> ztmonitor like apps. The data is definitely being lost right in between
>> these two.
> 
> Perhaps you are seeing an issue that is not related to what I have seen.
> 
> It sounds more and more like you are using a patched version of zaptel.
> 
>> It would be very handy for the receiving code in chan_zap or in zaptel to
>> know that is was receiving contiguous chunks from the other side, and be
>> able to back up one, if it did not. 
>>
>> In data type transfers (PRI, BRI, FAX) there will be data loss of this type.
>> We've gotten very proficient at minimizing this, but statistics bear out
>> that it can not be eliminated with the current state of zaptel.
>>
>> -----Original Message-----
>> From: asterisk-dev-bounces at lists.digium.com
>> [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Matthew
>> Fredrickson
>> Sent: Tuesday, October 02, 2007 9:12 AM
>> To: Asterisk Developers Mailing List
>> Subject: Re: [asterisk-dev] Zaptel Interrupt Issues
>>
>> Bob wrote:
>>> I have not.
>>> The way that I see it is that zaptel is very real time. I believe the
>>> problem is that user space is not. There is no way of ensuring the
>>> reader/writer of a zap device is woke up 1000 times / second.
>>>
>>> The **RIGHT** way to address this problem would be to use some sort of a
>>> ring buffer that allows the application to catch up like the network
>> devices
>>> do.
>>>
>>> The easy way out is to schedule the readers/writers at a rate that they
>> will
>>> miss less often. There are no guarantees this way, but I have found that
>> if
>>> the kernel threads take more than a couple of ms before scheduling the
>> user
>>> time, the machine is about to start smoking anyhow. On the other hand, md
>>> and eth devices can easily take 1/2 ms to return. Chan_zap will never have
>>> the same priority as the networking bottom half routines.
>> By the time that chan_zap (and userland) sees the data, it *has* been 
>> buffered, quite a bit actually.  There is a configurable ring buffer 
>> within zaptel for each channel which takes the data given every 
>> millisecond.  The chunksize changes only change the pseudo TDM rate at 
>> which interrupts occur, and hence also changes the DMA buffer size used 
>> by the hardware drivers.  The reason you are seeing better performance 
>> with larger chunksizes is that the DMA buffer is bigger, hence it is 
>> more resilient to non-friendly drivers which disable interrupts for 
>> longer than (what should be) allowable periods of time (1-2ms).
>>
>> The data miss that I am referring to is that of the actual transfer of 
>> data itself, not necessarily the upper layers (such as chan_zap and 
>> zaptel after buffering).
>>
>>
>>
>> _______________________________________________
>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>    http://lists.digium.com/mailman/listinfo/asterisk-dev
> 
>