<html>
<head>
<base href="https://wiki.asterisk.org/wiki">
<link rel="stylesheet" href="/wiki/s/en/2171/18/9/_/styles/combined.css?spaceKey=AST&forWysiwyg=true" type="text/css">
</head>
<body style="background: white;" bgcolor="white" class="email-body">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
<h2><a href="https://wiki.asterisk.org/wiki/display/AST/Timing+Interfaces">Timing Interfaces</a></h2>
<h4>Page <b>edited</b> by <a href="https://wiki.asterisk.org/wiki/display/~seanbright">Sean Bright</a>
</h4>
<div id="versionComment">
<b>Comment:</b>
add res_timing_kqueue and some historical context for dahdi_dummy. also some formatting.<br />
</div>
<br/>
<h4>Changes (22)</h4>
<div id="page-diffs">
<table class="diff" cellpadding="0" cellspacing="0">
<tr><td class="diff-unchanged" >h1. Asterisk Timing Interfaces <br> <br></td></tr>
<tr><td class="diff-unchanged" >In the past, if internal timing were desired for an Asterisk system, then the only source acceptable was from DAHDI. Beginning with Asterisk 1.6.1, a new timing API was introduced which allows for various timing modules to be used. <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">Included with Asterisk are the following timing modules: <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">Asterisk includes the following timing modules: <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-changed-lines" ><span class="diff-changed-words"><span class="diff-added-chars"style="background-color: #dfd;">{{</span>res_timing_pthread.so<span class="diff-added-chars"style="background-color: #dfd;">}}</span></span> <br></td></tr>
<tr><td class="diff-changed-lines" ><span class="diff-changed-words"><span class="diff-added-chars"style="background-color: #dfd;">{{</span>res_timing_dahdi.so<span class="diff-added-chars"style="background-color: #dfd;">}}</span></span> <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">res_timing_timerfd.so (Beginning with Asterisk 1.6.2) <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">{{res_timing_timerfd.so}} --- _as of Asterisk 1.6.2_ <br>{{res_timing_kqueue.so}} --- _as of Asterisk 11_ <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-changed-lines" ><span class="diff-changed-words"><span class="diff-added-chars"style="background-color: #dfd;">{{</span>res_timing_pthread<span class="diff-added-chars"style="background-color: #dfd;">}}</span></span> uses the POSIX pthreads library in order to provide timing. Since the code uses a commonly-implemented set of functions, <span class="diff-changed-words"><span class="diff-added-chars"style="background-color: #dfd;">{{</span>res_timing_pthread<span class="diff-added-chars"style="background-color: #dfd;">}}</span></span> is portable to many types of systems. In fact, this is the only timing source currently usable on a non-Linux system. Due to the fact that a single userspace thread is used to provide timing for all users of the timer, <span class="diff-changed-words"><span class="diff-added-chars"style="background-color: #dfd;">{{</span>res_timing_pthread<span class="diff-added-chars"style="background-color: #dfd;">}}</span></span> is also the least efficient of the timing sources and has been known to lose <span class="diff-added-words"style="background-color: #dfd;">its effectiveness in a heavily-loaded environment.</span> <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">its effectiveness in a heavily-loaded environment. <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">res_timing_dahdi uses timing mechanisms provided by DAHDI. This method of timing was previously the only means by which Asterisk could receive timing. It has the benefit of being efficient, and if a system is already going to use DAHDI hardware, then it makes good sense to use this timing source. If, however, there is no need for DAHDI other than as a timing source, this timing source may seem unattractive. For people who are upgrading from 1.4 and are used to the old ztdummy timing interface, res_timing_dahdi provides the interface to dahdi_dummy, which is ztdummy's replacement. <br>{info}dahdi_dummy is no longer required in DAHDI-linux versions 2.3.0+. If the dahdi kernel module is loaded, it will be able to provide timing regardless of the span configuration.{info} <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">{{res_timing_dahdi}} uses timing mechanisms provided by DAHDI. This method of timing was previously the only means by which Asterisk could receive timing. It has the benefit of being efficient, and if a system is already going to use DAHDI hardware, then it makes good sense to use this timing source. If, however, there is no need for DAHDI other than as a timing source, this timing source may seem unattractive. For users who are upgrading from Asterisk 1.4 and are used to the {{ztdummy}} timing interface, {{res_timing_dahdi}} provides the interface to DAHDI via the {{dahdi}} kernel module. <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">res_timing_timerfd uses a timing mechanism provided directly by the Linux kernel. This timing interface is only available on Linux systems using a kernel version at least 2.6.25 and a glibc version at least 2.8. This interface has the benefit of being very efficient, but at the time this is being written, it is a relatively new feature on Linux, meaning that its availability is not widespread. <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">{info:title=Historical Note} <br>At the time of Asterisk 1.4's release, Zaptel (now DAHDI) was used to provide timing to Asterisk, either by utilizing telephony hardware installed in the computer or via {{ztdummy}} (a kernel module) when no hardware was available. <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">When DAHDI was first released, the {{ztdummy}} kernel module was renamed to {{dahdi_dummy}}. As of DAHDI Linux 2.3.0 the {{dahdi_dummy}} module has been removed and its functionality moved into the main {{dahdi}} kernel module. As long as the {{dahdi}} module is loaded, it will provide timing to Asterisk either through installed telephony hardware or utilizing the kernel timing facilities when separate hardware is not available. <br>{info} <br> <br>{{res_timing_timerfd}} uses a timing mechanism provided directly by the Linux kernel. This timing interface is only available on Linux systems using a kernel version at least 2.6.25 and a glibc version at least 2.8. This interface has the benefit of being very efficient, but at the time this is being written, it is a relatively new feature on Linux, meaning that its availability is not widespread. <br> <br>{{res_timing_kqueue}} uses the [Kqueue|http://www.freebsd.org/cgi/man.cgi?query=kqueue&sektion=2] event notification system introduced with FreeBSD 4.1. It can be used on operating systems that support Kqueue, such as OpenBSD and Mac OS X. Because Kqueue is not available on Linux, this module will not compile or be available there. <br> <br></td></tr>
<tr><td class="diff-unchanged" >h3. What Asterisk does with the Timing Interfaces <br> <br></td></tr>
<tr><td class="diff-changed-lines" >By default, Asterisk will build and load all of the timing interfaces. These <span class="diff-deleted-words"style="color:#999;background-color:#fdd;text-decoration:line-through;"> </span> timing interfaces are "ordered" based on a hard-coded priority number defined in each of the modules. As of the time of this writing, the preferences for the <span class="diff-added-words"style="background-color: #dfd;">modules is the following: {{res_timing_timerfd.so}}, {{res_timing_kqueue.so}} (where available), {{res_timing_dahdi.so}}, {{res_timing_pthread.so}}.</span> <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">modules is the following: res_timing_timerfd.so, res_timing_dahdi.so, res_timing_pthread.so. <br></td></tr>
<tr><td class="diff-unchanged" > <br>The only functionality that requires internal timing is IAX2 trunking. It may also be used when generating audio for playback, such as from a file. Even though internal timing is not a requirement for most Asterisk functionality, it may be advantageous to use it since the alternative is to use timing based on incoming frames of audio. If there are no incoming frames or if the incoming frames of audio are from an unreliable or jittery source, then the corresponding outgoing audio will also be unreliable, or even worse, nonexistent. Using internal timing prevents such unreliability. <br></td></tr>
<tr><td class="diff-snipped" >...<br></td></tr>
<tr><td class="diff-unchanged" >Alternatively, you may have been directed to this document due to an error you are currently experiencing with Asterisk. If you receive an error message regarding timing not working correctly, then you can use one of the following suggestions to disable a faulty timing module. <br> <br></td></tr>
<tr><td class="diff-changed-lines" ><span class="diff-deleted-words"style="color:#999;background-color:#fdd;text-decoration:line-through;">*1.*</span> <span class="diff-added-words"style="background-color: #dfd;">#</span> Don't build the timing modules you know you will not use. You can disable the compilation of any of the timing modules using <span class="diff-changed-words"><span class="diff-added-chars"style="background-color: #dfd;">{{</span>menuselect<span class="diff-added-chars"style="background-color: #dfd;">}}</span>.</span> The modules are listed in the "Resource Modules" section. <span class="diff-added-words"style="background-color: #dfd;"> </span> Note that if you have already built Asterisk and have received an error about a timing module not working properly, it is not sufficient to disable it from being built. You will need to remove the module from your modules directory (by default, <span class="diff-changed-words"><span class="diff-added-chars"style="background-color: #dfd;">{{</span>/usr/lib/asterisk/modules<span class="diff-added-chars"style="background-color: #dfd;">}}</span>)</span> to make sure that it does not get loaded again. <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;"># Build, but do not load the timing modules you know you will not use. You can edit {{modules.conf}} using {{noload}} directives to disable the loading of specific timing modules by default. Based on the note in the section above, you may realize that your Asterisk setup does not require internal timing at all. If this is the case, you can safely {{noload}} all timing modules. <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">*2.* Build, but do not load the timing modules you know you will not use. You can edit modules.conf using "noload" lines to disable the loading of specific timing modules by default. Based on the note in the section above, you may realize that your Asterisk setup does not require internal timing at all. If this is the case, you can safely noload all timing modules. <br> <br></td></tr>
<tr><td class="diff-unchanged" >{note:Important Notes} <br></td></tr>
<tr><td class="diff-changed-lines" >Some confusion has arisen regarding the fact that non-DAHDI timing interfaces <span class="diff-added-words"style="background-color: #dfd;">are available now. One common misconception which has arisen is that since timing can be provided elsewhere, DAHDI is no longer required for using the MeetMe application. Unfortunately, this is not the case. In addition to providing timing, DAHDI also provides a conferencing engine which the MeetMe application requires.</span> <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">are available now. One common misconception which has arisen is that since <br>timing can be provided elsewhere, DAHDI is no longer required for using the <br>MeetMe application. Unfortunately, this is not the case. In addition to <br>providing timing, DAHDI also provides a conferencing engine which the MeetMe <br>application requires. <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-changed-lines" >Starting with Asterisk 1.6.2, however, there <span class="diff-deleted-words"style="color:#999;background-color:#fdd;text-decoration:line-through;">will be</span> <span class="diff-added-words"style="background-color: #dfd;">is</span> a new application, <span class="diff-added-words"style="background-color: #dfd;">ConfBridge, which is capable of conference bridging without the use of DAHDI's built-in mixing engine.</span> <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">ConfBridge, which will be capable of conference bridging without the use <br>of DAHDI's built-in mixing engine. <br></td></tr>
<tr><td class="diff-unchanged" >{note} <br></td></tr>
</table>
</div> <h4>Full Content</h4>
<div class="notificationGreySide">
<h1><a name="TimingInterfaces-AsteriskTimingInterfaces"></a>Asterisk Timing Interfaces</h1>
<p>In the past, if internal timing were desired for an Asterisk system, then the only source acceptable was from DAHDI. Beginning with Asterisk 1.6.1, a new timing API was introduced which allows for various timing modules to be used.<br/>
Asterisk includes the following timing modules:</p>
<p><tt>res_timing_pthread.so</tt><br/>
<tt>res_timing_dahdi.so</tt><br/>
<tt>res_timing_timerfd.so</tt> — <em>as of Asterisk 1.6.2</em><br/>
<tt>res_timing_kqueue.so</tt> — <em>as of Asterisk 11</em></p>
<p><tt>res_timing_pthread</tt> uses the POSIX pthreads library in order to provide timing. Since the code uses a commonly-implemented set of functions, <tt>res_timing_pthread</tt> is portable to many types of systems. In fact, this is the only timing source currently usable on a non-Linux system. Due to the fact that a single userspace thread is used to provide timing for all users of the timer, <tt>res_timing_pthread</tt> is also the least efficient of the timing sources and has been known to lose its effectiveness in a heavily-loaded environment. </p>
<p><tt>res_timing_dahdi</tt> uses timing mechanisms provided by DAHDI. This method of timing was previously the only means by which Asterisk could receive timing. It has the benefit of being efficient, and if a system is already going to use DAHDI hardware, then it makes good sense to use this timing source. If, however, there is no need for DAHDI other than as a timing source, this timing source may seem unattractive. For users who are upgrading from Asterisk 1.4 and are used to the <tt>ztdummy</tt> timing interface, <tt>res_timing_dahdi</tt> provides the interface to DAHDI via the <tt>dahdi</tt> kernel module.</p>
<div class='panelMacro'><table class='infoMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/wiki/images/icons/emoticons/information.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td><b>Historical Note</b><br />At the time of Asterisk 1.4's release, Zaptel (now DAHDI) was used to provide timing to Asterisk, either by utilizing telephony hardware installed in the computer or via <tt>ztdummy</tt> (a kernel module) when no hardware was available.
<p>When DAHDI was first released, the <tt>ztdummy</tt> kernel module was renamed to <tt>dahdi_dummy</tt>. As of DAHDI Linux 2.3.0 the <tt>dahdi_dummy</tt> module has been removed and its functionality moved into the main <tt>dahdi</tt> kernel module. As long as the <tt>dahdi</tt> module is loaded, it will provide timing to Asterisk either through installed telephony hardware or utilizing the kernel timing facilities when separate hardware is not available.</p></td></tr></table></div>
<p><tt>res_timing_timerfd</tt> uses a timing mechanism provided directly by the Linux kernel. This timing interface is only available on Linux systems using a kernel version at least 2.6.25 and a glibc version at least 2.8. This interface has the benefit of being very efficient, but at the time this is being written, it is a relatively new feature on Linux, meaning that its availability is not widespread. </p>
<p><tt>res_timing_kqueue</tt> uses the <a href="http://www.freebsd.org/cgi/man.cgi?query=kqueue&sektion=2" class="external-link" rel="nofollow">Kqueue</a> event notification system introduced with FreeBSD 4.1. It can be used on operating systems that support Kqueue, such as OpenBSD and Mac OS X. Because Kqueue is not available on Linux, this module will not compile or be available there.</p>
<h3><a name="TimingInterfaces-WhatAsteriskdoeswiththeTimingInterfaces"></a>What Asterisk does with the Timing Interfaces</h3>
<p>By default, Asterisk will build and load all of the timing interfaces. These timing interfaces are "ordered" based on a hard-coded priority number defined in each of the modules. As of the time of this writing, the preferences for the modules is the following: <tt>res_timing_timerfd.so</tt>, <tt>res_timing_kqueue.so</tt> (where available), <tt>res_timing_dahdi.so</tt>, <tt>res_timing_pthread.so</tt>. </p>
<p>The only functionality that requires internal timing is IAX2 trunking. It may also be used when generating audio for playback, such as from a file. Even though internal timing is not a requirement for most Asterisk functionality, it may be advantageous to use it since the alternative is to use timing based on incoming frames of audio. If there are no incoming frames or if the incoming frames of audio are from an unreliable or jittery source, then the corresponding outgoing audio will also be unreliable, or even worse, nonexistent. Using internal timing prevents such unreliability.</p>
<h3><a name="TimingInterfaces-Customizations%2FTroubleshooting"></a>Customizations/Troubleshooting</h3>
<p>Now that you know Asterisk's default preferences for timing modules, you may decide that you have a different preference. Maybe you're on a timerfd-capable system but you would prefer to get your timing from DAHDI since you already are <br/>
using DAHDI to drive your hardware. </p>
<p>Alternatively, you may have been directed to this document due to an error you are currently experiencing with Asterisk. If you receive an error message regarding timing not working correctly, then you can use one of the following suggestions to disable a faulty timing module. </p>
<ol>
<li>Don't build the timing modules you know you will not use. You can disable the compilation of any of the timing modules using <tt>menuselect</tt>. The modules are listed in the "Resource Modules" section. Note that if you have already built Asterisk and have received an error about a timing module not working properly, it is not sufficient to disable it from being built. You will need to remove the module from your modules directory (by default, <tt>/usr/lib/asterisk/modules</tt>) to make sure that it does not get loaded again.</li>
<li>Build, but do not load the timing modules you know you will not use. You can edit <tt>modules.conf</tt> using <tt>noload</tt> directives to disable the loading of specific timing modules by default. Based on the note in the section above, you may realize that your Asterisk setup does not require internal timing at all. If this is the case, you can safely <tt>noload</tt> all timing modules.</li>
</ol>
<div class='panelMacro'><table class='noteMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/wiki/images/icons/emoticons/warning.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td>Some confusion has arisen regarding the fact that non-DAHDI timing interfaces are available now. One common misconception which has arisen is that since timing can be provided elsewhere, DAHDI is no longer required for using the MeetMe application. Unfortunately, this is not the case. In addition to providing timing, DAHDI also provides a conferencing engine which the MeetMe application requires.
<p>Starting with Asterisk 1.6.2, however, there is a new application, ConfBridge, which is capable of conference bridging without the use of DAHDI's built-in mixing engine.</p></td></tr></table></div>
</div>
<div id="commentsSection" class="wiki-content pageSection">
<div style="float: right;" class="grey">
<a href="https://wiki.asterisk.org/wiki/users/removespacenotification.action?spaceKey=AST">Stop watching space</a>
<span style="padding: 0px 5px;">|</span>
<a href="https://wiki.asterisk.org/wiki/users/editmyemailsettings.action">Change email notification preferences</a>
</div>
<a href="https://wiki.asterisk.org/wiki/display/AST/Timing+Interfaces">View Online</a>
|
<a href="https://wiki.asterisk.org/wiki/pages/diffpagesbyversion.action?pageId=4260065&revisedVersion=3&originalVersion=2">View Changes</a>
|
<a href="https://wiki.asterisk.org/wiki/display/AST/Timing+Interfaces?showComments=true&showCommentArea=true#addcomment">Add Comment</a>
</div>
</div>
</div>
</div>
</div>
</body>
</html>