<p>Thanks Shaun.</p>
<div class="gmail_quote">On Sep 15, 2012 1:10 AM, "Shaun Ruffell" <<a href="mailto:sruffell@digium.com">sruffell@digium.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, Sep 14, 2012 at 09:42:23PM -0400, Mark Robinson wrote:<br>
> I did some research on this subject and still do not understand.<br>
> Why we use modules if asterisk can obtain timing directly from<br>
> kernel?<br>
<br>
Probably longer than it needs to be but...<br>
<br>
Asterisk needs timing information via a kernel file descriptor<br>
that can be passed into to the poll() [1] or select() system calls.<br>
This allows Asterisk to sleep while waiting for either a network<br>
packet to come in or one of several time intervals to expire in the<br>
same system call which is very efficient.<br>
<br>
DAHDI historically provided this service via /dev/dahdi/timer.<br>
DAHDI was a good choice to provide a timing service since Asterisk<br>
typically wanted VOIP traffic synchronized with any telephony<br>
hardware installed. If there was not telephony hardware DAHDI could<br>
use internal kernel interfaces to find the best source of timing for<br>
Asterisk (generic kernel timers, Real-Time Clock, High Resolution<br>
timers, etc..).<br>
<br>
Using DAHDI was (and is) a natural choice but updating kernels can<br>
be more difficult since DAHDI must be recompiled every time the<br>
kernel is updated. This unnecessarily increases the administration<br>
burden when there is not any telephony hardware to synchronize with.<br>
<br>
To reduce the dependency on DAHDI, res_timing_pthread was created in<br>
Asterisk version 1.6.1 [2]. This implementation could provide timing<br>
via file descriptors without requiring DAHDI to be installed. It<br>
uses a pipe()[3] and a thread. The thread will sleep for a period of<br>
time and then write to one end of the pipe when the timer fires.<br>
res_timing_pthread is more system intensive--creates a thread that<br>
must be scheduled, the scheduling of that thread determines the<br>
timeliness of the timer firing, and the extra system calls required<br>
to accomplish the same task--and I believe it is advisable to avoid<br>
res_timing_pthread unless you have no other choice.<br>
<br>
It was not until kernel version 2.6.25 that Linux provided a<br>
standard interface for configuring timers that signaled via file<br>
descriptors, the timerfd interface [4]. Now Asterisk had a standard<br>
kernel interface which provided essentially the same service that<br>
DAHDI's /dev/dahdi/timer did without needing to install DAHDI or<br>
creating a separate thread which wrote to a pipe and<br>
res_timing_timerfd was first release in Asterisk 1.6.2 [5]. The<br>
problem is that timerfd_create() is not available on all platforms<br>
Asterisk must support. Also, if you have telephony hardware<br>
installed it is still generally best to synchronize to the clock on<br>
the telephony hardware to minimize audio problems caused by<br>
mismatches in clock rates. But if available and you don't have any<br>
other dependency on DAHDI (app_meetme, app_page, etc...), timerfd<br>
should be your first choice for timing source.<br>
<br>
So given these different methods of obtaining timing, Asterisk<br>
needed a way to abstract them so that other parts of the system had<br>
a standard way to get a file descriptor which could be configured to<br>
fire at certain intervals. That is why the timing interface [6] and<br>
various timing modules were created. It allows the Asterisk<br>
administrator to use the timing source that works best for them.<br>
<br>
That's why, to the best of my knowledge, Asterisk uses modules even<br>
though it can now obtain timing directly from the kernel.<br>
<br>
Cheers,<br>
Shaun<br>
<br>
[1] <a href="http://linux.die.net/man/2/poll" target="_blank">http://linux.die.net/man/2/poll</a><br>
[2] <a href="http://svnview.digium.com/svn/asterisk?view=revision&revision=122928" target="_blank">http://svnview.digium.com/svn/asterisk?view=revision&revision=122928</a><br>
[3] <a href="http://linux.die.net/man/2/pipe" target="_blank">http://linux.die.net/man/2/pipe</a><br>
[4] <a href="http://linux.die.net/man/2/timerfd_create" target="_blank">http://linux.die.net/man/2/timerfd_create</a><br>
[5] <a href="http://svnview.digium.com/svn/asterisk?view=revision&revision=157820" target="_blank">http://svnview.digium.com/svn/asterisk?view=revision&revision=157820</a><br>
[6] <a href="http://svnview.digium.com/svn/asterisk?view=revision&revision=122062" target="_blank">http://svnview.digium.com/svn/asterisk?view=revision&revision=122062</a><br>
<br>
--<br>
Shaun Ruffell<br>
Digium, Inc. | Linux Kernel Developer<br>
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA<br>
Check us out at: <a href="http://www.digium.com" target="_blank">www.digium.com</a> & <a href="http://www.asterisk.org" target="_blank">www.asterisk.org</a><br>
<br>
--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
New to Asterisk? Join us for a live introductory webinar every Thurs:<br>
<a href="http://www.asterisk.org/hello" target="_blank">http://www.asterisk.org/hello</a><br>
<br>
asterisk-users mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-users" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br>
</blockquote></div>