Thanks Shaun. On Sep 15, 2012 1:10 AM, "Shaun Ruffell" <[email protected]> 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 >
-- _____________________________________________________________________ -- 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
