[asterisk-users] Asterisk on VM with NO DAHDI hardware

[Shaun Ruffell]

On Fri, Sep 14, 2012 at 09:42:23PM -0400, Mark Robinson wrote:
> I did some research on this subject and still do not understand.
> Why we use modules if asterisk can obtain timing directly from
> kernel?

Probably longer than it needs to be but...

Asterisk needs timing information via a kernel file descriptor
that can be passed into to the poll() [1] or select() system calls.
This allows Asterisk to sleep while waiting for either a network
packet to come in or one of several time intervals to expire in the
same system call which is very efficient.

DAHDI historically provided this service via /dev/dahdi/timer.
DAHDI was a good choice to provide a timing service since Asterisk
typically wanted VOIP traffic synchronized with any telephony
hardware installed. If there was not telephony hardware DAHDI could
use internal kernel interfaces to find the best source of timing for
Asterisk (generic kernel timers, Real-Time Clock, High Resolution
timers, etc..).

Using DAHDI was (and is) a natural choice but updating kernels can
be more difficult since DAHDI must be recompiled every time the
kernel is updated. This unnecessarily increases the administration
burden when there is not any telephony hardware to synchronize with.

To reduce the dependency on DAHDI, res_timing_pthread was created in
Asterisk version 1.6.1 [2]. This implementation could provide timing
via file descriptors without requiring DAHDI to be installed. It
uses a pipe()[3] and a thread. The thread will sleep for a period of
time and then write to one end of the pipe when the timer fires.
res_timing_pthread is more system intensive--creates a thread that
must be scheduled, the scheduling of that thread determines the
timeliness of the timer firing, and the extra system calls required
to accomplish the same task--and I believe it is advisable to avoid
res_timing_pthread unless you have no other choice.

It was not until kernel version 2.6.25 that Linux provided a
standard interface for configuring timers that signaled via file
descriptors, the timerfd interface [4]. Now Asterisk had a standard
kernel interface which provided essentially the same service that
DAHDI's /dev/dahdi/timer did without needing to install DAHDI or
creating a separate thread which wrote to a pipe and
res_timing_timerfd was first release in Asterisk 1.6.2 [5]. The
problem is that timerfd_create() is not available on all platforms
Asterisk must support. Also, if you have telephony hardware
installed it is still generally best to synchronize to the clock on
the telephony hardware to minimize audio problems caused by
mismatches in clock rates. But if available and you don't have any
other dependency on DAHDI (app_meetme, app_page, etc...), timerfd
should be your first choice for timing source.

So given these different methods of obtaining timing, Asterisk
needed a way to abstract them so that other parts of the system had
a standard way to get a file descriptor which could be configured to
fire at certain intervals. That is why the timing interface [6] and
various timing modules were created. It allows the Asterisk
administrator to use the timing source that works best for them.

That's why, to the best of my knowledge, Asterisk uses modules even
though it can now obtain timing directly from the kernel.

Cheers,
Shaun

[1] http://linux.die.net/man/2/poll
[2] http://svnview.digium.com/svn/asterisk?view=revision&revision=122928
[3] http://linux.die.net/man/2/pipe
[4] http://linux.die.net/man/2/timerfd_create
[5] http://svnview.digium.com/svn/asterisk?view=revision&revision=157820
[6] http://svnview.digium.com/svn/asterisk?view=revision&revision=122062 

-- 
Shaun Ruffell
Digium, Inc. | Linux Kernel Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: www.digium.com & www.asterisk.org