Asterisk and X [was: Re: [Asterisk-Users] zaptel PRI drivers]

Peter Svensson psvasterisk at psv.nu
Mon Mar 21 14:13:21 MST 2005


On Mon, 21 Mar 2005, Tom wrote:

> Quoting Peter Svensson <psvasterisk at psv.nu>:
> > Also, you may not notice if you miss a ms worth of audio data, but the
> > digital signalling on a pri will. Ideally this should not be a problem but
> > with standard kernels it will be.
> 
> This is what I have suspected all along is that the signaling and timing
> constraints on the PRI are such that you basically need asterisk running as a
> real-time process.  The whole point of the thread (in my mind) is if there is
> anyway to cause X to not run as such a real-time process so as to allow
> asterisk the proper access to the hardware that it needs?  and why can I run X
> (as in Xvnc which starts x servers) without any problem? but not a real x
> server?

There are three deadlines that need to be met for an Asterisk+zaptel stack
to work. The pci card needs access to the pci bus soon enough that the
buffers on the card are not overrun. The kernel driver needs to handle the
interrupts fast enough. The user level program (Asterisk) needs to process
the data fast enough.

The user level latencies can be improved by running the Asterisk process
as a real time process in linux. This will make sure that other user level
threads will yield control to Asterisk as soon as an Asterisk thread 
becomes ready to run. The user level latencies are always affected by the 
kernel level latencies.

The kernel level latency is harder to improve. Various drivers hog the cpu 
for quite some time. The most problematic drivers are graphics drivers and 
the console-over-serial driver. Some problems may occur with some disk 
drivers. There is a patch by Ingo Mjolner to reduce the latency 
significantly by making almost all parts of the kernel preemptable. 
Latencies well below the required 1ms are easily achievable. This is still 
experimental.

The pci bus access can be important depending on which card you have.  
Access to the pci bus is granted to one device at a time and for a limited 
amount of time. Tuning the allowed length of time various devices can hold 
the bus is an art, or at least no easy. High performance disk controllers 
etc are known to sometimes hold the bus for a very long time to improve 
their performance since setting up a transfer takes time. Search for "pci 
latency" for more information. 

Peter





More information about the asterisk-users mailing list