[asterisk-dev] Zaptel Interrupt Issues

[Matthew Fredrickson]

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

> 
> -----Original Message-----
> From: asterisk-dev-bounces at lists.digium.com
> [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Paul Hewlett
> Sent: Tuesday, October 02, 2007 3:21 AM
> To: asterisk-dev at lists.digium.com
> Subject: Re: [asterisk-dev] Zaptel Interrupt Issues
> 
> On Tuesday 02 October 2007 08:30:50 Bob wrote:
>> I have a theory about zaptel interrupt issues.
> 
>> My theory is that user land code is not being scheduled every 1 ms under
>> high load. The data drops are most prominent on systems with high network
>> traffic or RAIDs that can occupy the CPU for more than 1ms without letting
>> go. The simple solution was to expand the time to 2, 4, 8 ms respose time
>> of the user application.
>>
>> Feedback?
> 
> Have you tried Ingo Molnar's RT patches to the kernel and applied different 
> priorities to both the IRQ on which the card sits and to asterisk?
> 
> Paul
> 
> 


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