3

Timing is very important for certain kinds of applications in Asterisk. If DAHDI is the timing source, the dahdi_test command can be used to check the timing provided by the DAHDI kernel module. If dahdi_test returns exclusively measurements above 99.975%, the DAHDI timing source is generally considered good.

Since Asterisk 1.6, new timing sources have become available, such as pthread and timerfd, which are useful in systems that do not or cannot use DAHDI hardware for timing, as they represent an improvement over the dahdi_dummy module. Obviously, if DAHDI timing is not being used, dahdi_test will not be useful to test the timing source; but the accuracy of any timing source seems to be measurable with the Asterisk CLI timing test command:

localhost*CLI> timing test
Attempting to test a timer with 50 ticks per second.
Using the 'timerfd' timing module for this test.
It has been 1000 milliseconds, and we got 50 timer ticks

My concern is that timing 50 ticks seems to be a considerably less stressful test than dahdi_test's 8192 samples in 8000 ms, particularly since just about every system I've tried it on, virtual or otherwise, can handle it.

I can ask timing test to ramp it up to what I think are dahdi_test's standards:

localhost*CLI> timing test 1024
Attempting to test a timer with 1024 ticks per second.
Using the 'timerfd' timing module for this test.
It has been 1000 milliseconds, and we got 1024 timer ticks

This will indeed break down a bit depending on the system I'm using, usually with a decrease in timer ticks. But I'm not sure whether this is useful to stress it to this level.

Is there authoritative guidance on using and interpreting the timing test command to insure that a given Asterisk system has a timing source that will work well?

2 Answers 2

1

I realize this is an old question, but for anyone else who comes along from google: it is my understanding that if your motherboard has a high-frequency timing source built-in (many do), and as long as it's enabled in the BIOS settings, the Linux kernel will know about it, and timerfd should perform just as well as anything else.

I have excellent performance with timerfd using Asterisk on CentOS 6.5, inside VMware ESXi 5.5, hardware version 10 (with latency sensitivity set to High in the virtual machine configuration), and vmware-tools-esx-nox RPMs installed. So, that's without a "real", physical HF timing source. Asterisk used to be terrible on older versions of vmware, but virtualization in general has come a long way.

0

If you're looking for a canonical source of information about all things Asterisk, then the wiki at http://www.voip-info.org/ is about as close as it comes, in my experience. Digium also has their own forums, but not necessarily the trove of information that you can find at voip-info.org.

As for the timing test command on the Asterisk command line, I wouldn't really call that a meaningful test for much beyond ensuring that your DAHDI device is operating. If there's a fault on the card, it might show something, but on our perfectly working Asterisk switch which happens to be routing about 8000 calls per day, running 'timing test' with any value over 1000 returns nothing more than 1001 timer ticks (even requesting 2048 ticks, for example). Listening to a call in progress while doing so does not result in any degradation of voice quality, so I would not call this any kind of stress test.

In our experience, any working Digium card with hardware echo cancellation will handle the load, but where Asterisk falls down is when it's stressed with SIP calls and registrations. We've found that many versions of Asterisk simply are not stable enough for production use, even supposedly "release" versions. One way to test for this condition is with the SIPp load tester, the details for configuration and installation can be found here: http://www.loho.co.uk/blog/2011/08/sip-load-testing-with-sipp/.

However, we would highly recommend either using Debian-Stable and its Asterisk binary package, or the exact same version they use (found here: http://packages.debian.org/wheezy/asterisk). We've had good success with this on several PBXes, some of which have had fairly high load (although not as high as our main server - they're usually deployed at customer sites).

3
  • This doesn't really directly address the question, I don't think. I'm looking for guidance on evaluating the timing source specifically, for applications that demand it, such as conferencing. Without a good timing source, audio quality in these applications will suffer even if loads aren't high.
    – Mattie
    Jul 2, 2013 at 17:55
  • Well if you're looking for a DAHDI timing stress test, it's pretty clear the console command 'timing test' doesn't do anything worthwhile. There's a few places on the web that will help you troubleshoot bad 'dahdi_test' results, like here: cadvision.com/blanchas/Asterisk/DahdiPerformanceTesting.html
    – Ernie
    Jul 2, 2013 at 18:15
  • I'm not trying to test DAHDI. I'm trying to test alternate timing sources, like pthread or timerfd, which should both be better than the dahdi source in a DAHDI-hardware-less system. I'll make sure this is clear in my question.
    – Mattie
    Jul 2, 2013 at 18:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .