[asterisk-dev] Zaptel Interrupt Issues

[Matthew Fredrickson]

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


-- 
Matthew Fredrickson
Software/Firmware Engineer
Digium, Inc.