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. The accuracy of these timing sources 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?