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
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
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?