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

[Tom]

Peter,
Thank you for your thorough and useful explanation of the various latencies
involved.  This is exactly what I was looking for as far as where the problems
are, and maybe a way to fix them.  I built a new kernel with Ingo's patch and
it is in testing now, if it is reliable enough, we may roll it out to at least
a couple of beta testers to try to stress the system and see if we can use this
solution.  Once again thank you for your help and insight
Tom Christensen

Quoting Peter Svensson <psvasterisk at psv.nu>:

> 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
>
>
> _______________________________________________
> Asterisk-Users mailing list
> Asterisk-Users at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
>