[asterisk-dev] Zaptel Interrupt Issues

[Bob]

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.

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.

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