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

[Mark Robinson]

Thanks Shaun.
On Sep 15, 2012 1:10 AM, "Shaun Ruffell" <sruffell at digium.com> wrote:

> 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
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>                http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20120917/061723e0/attachment.htm>