Hi All!
Hoping someone can give me some definitive answers regarding timing in Asterisk.
Recently I upgraded our company MeetMe conference bridge to 11.5.0 from 1.6.0.28 on a new 24 core RHEL 6.4 server platform. The end users are all connected to Cisco UCM and connected to this platform using a SIP trunk/G711u/Directmedia.
The bridge was up for over 3 years with no issues using 1.6.0, but since the upgrade I have received a couple of reports about bad audio for isolated participants on a larger conference after around 45 minutes or so. The audio is severely distorted, and the caller has to disconnect and reconnect, after which the problem is resolved for the remainder of the call. Other users are not affected at the same time. No errors logged anywhere that I can find to help explain it.
I’m looking at Asterisk timing along with the other possible root causes. On the new platform, dahdi_test results are not what I expected… most individual tests are 99.997, but occassionally I see tests as low as 99.6. Strangely, the bad timer results seem to come in sets. 99.997 99.997 99.604 99.604 99.997 (etc, etc.) We’ve tried lots of tweaks to RHEL kernel timing sources, etc, with no change in the dahdi_test behavior.
In the process of researching this, I uncovered a couple of things that have changed since the original 1.6.0 build:
–MeetMe no longer requires dahdi for timing. (Still for bridging.) My installation uses the res_timing_timerfd.so interface, which is used instead of dahdi if available.
Question 1: How do I confirm the timerfd interface is working properly? “dahdi_test” results are now meaningless for my purposes, right? If dahdi is not used for timing, is 99.6 still an indicator of a system problem?
–There are reportedly better timing sources available than HPET.
Question 2: RHEL 6.4 (our build anyway) uses tsc for timing, but can also use hpet and acpi. “tsc” is now the preferred method, yes?
Can anyone give me the scoop on timing nowadays?
For those of you that made it to the end of this, I thank you.
-Brian