Asterisk Timing Interfaces
-------------------------------------

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. Included with Asterisk
are the following timing modules:

res_timing_pthread.so
res_timing_dahdi.so
res_timing_timerfd.so (Beginning with Asterisk 1.6.2)

res_timing_pthread uses the POSIX pthreads library in order to provide timing. Since the
code uses a commonly-implemented set of functions, res_timing_pthread 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 userspace thread is required for every timer,
res_timing_pthread is also the least efficient of the timing sources and has been known
to lose its effectiveness in a heavily-loaded environment.

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.

res_timing_timerfd uses a timing mechanism provided directly by the 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's a
relatively new feature on Linux, meaning that its availability is not widespread.

What Asterisk does with the Timing Interfaces
---------------------------------------------
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: res_timing_timerfd.so, res_timing_dahdi.so,
res_timing_pthread.so.

At startup, Asterisk will first test the highest-priority timing interface which has been loaded. If the
test fails, then Asterisk will attempt to test the next-highest priority timing interface. The tests
will continue until a working timing interface is found. This timing interface will be used for the duration
of the Asterisk process.

Customizations
---------------------------------------------
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 using DAHDI to drive your hardware. There are multiple routes you can take to tweak Asterisk's
behavior.

1. Don't build the timing modules you know you will not use. You can disable the compilation of any of the timing
modules using menuselect. The modules are listed in the "Resource Modules" section.

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.

3. Reprioritize the timing modules. If you want to have the timing modules loaded but have a different preference
for order than Asterisk, then you can modify the code directly to achieve your goal. In each of the timing modules,
there is a static ast_timing_interface structure defined. By changing the value of the "priority" in this structure,
you can modify Asterisk's timing module preference. A higher number for a priority means that Asterisk will use that
module before it will try using a timing module with a lower priority.

Important Notes
----------------------------------------------
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.