I was reading one of the forum posts on this site and it mentions that the output of dahdi_test, the worst should not be less than 9.97 or there will be issues. My results are below:
chrt -f 99 dahdi_test -v -c 20
Opened pseudo dahdi interface, measuring accuracy…
8192 samples in 8193.199 system clock sample intervals (100.015%)
8192 samples in 8192.504 system clock sample intervals (100.006%)
8192 samples in 8192.936 system clock sample intervals (100.011%)
8192 samples in 8192.729 system clock sample intervals (100.009%)
8192 samples in 8193.216 system clock sample intervals (100.015%)
8192 samples in 8184.712 system clock sample intervals (99.911%)
8192 samples in 8192.584 system clock sample intervals (100.007%)
8192 samples in 8192.520 system clock sample intervals (100.006%)
8192 samples in 8184.776 system clock sample intervals (99.912%)
…
— Results after 20 passes —
Best: 99.995 – Worst: 99.911 – Average: 99.978743, Difference: 99.995769
I am using no Digium hardware. I have dahdi installed with ztdummy as the timing source. This is on a physical machine. How can improve my timing?
I realize this is more of an Asterisk related question but I am running FreePBX and I did find reference to these timing benchmarks else where on the forums so I was hoping someone might have an idea.
If so have you considered giving up DAHDI+dummy totally and going with app_confbridge as your conference module? (FreePBX uses it if it’s available and app_meetme is not) Note that IAX2 also no longer requires a DAHDI timer.
If you don’t have any Digium hardware there’s no real need for DAHDI if you’re in the 1.8 branch. This is especially useful when building Asterisk on virtual machines.
This particular machine is running 1.6. I am not using this for conferencing but rather for Call Queueing. We are doing local recording, moh, chanspy,etc. FreePBX is serving as the Call Center but our main PBX is Cisco Call Manger(For now) which is connected via SIP trunk. The real reason I ask is because I am trying to track down an intermittent call quality issue and was thinking that Dahdi timing might have something to do with it?
Thanks for the thorough explanation. Hopefully someone else can jump in and add to the conversation because I have nothing really. If your server is busy the DAHDI timing could be the culprit but so could network, disk I/O (especially if you are doing quite a lot of simultaneous recordings) and probably quite a few other things. Good luck!