[asterisk-dev] Zaptel Interrupt Issues
Bob
bob_co at cox.net
Tue Oct 2 10:17:54 CDT 2007
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.
-----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
--
Paul Hewlett Technical Director
Global Call Center Solutions Ltd, 2nd Floor, Milnerton Mall
Cnr Loxton & Koeberg Roads, 7435 Milnerton
www.gccs.co.za
Tel: +27 86 111 3433 Fax: +27 86 111 3520 Cel: +27 76 072 7906
VOIP: 087 750 7474
_______________________________________________
--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
More information about the asterisk-dev
mailing list