Dahdi_dummy Is More Accurate Than Core Timer?

Home » Asterisk Users » Dahdi_dummy Is More Accurate Than Core Timer?
Asterisk Users 6 Comments

Hi,

I have some servers that are dedicated to do meetme conferencing. From some previous test i concluded that I need to use dahdi_dummy as it is more accurate.

If I did use the core timers in dahdi (not loading dahdi_dummy) I got bad quality in the conferences and dahdi_test showed 99.6% as worst.

I thought maybe the issue as bad hardware for the timing or something else. But today I re-ran these tests on another server showing the same thing.

– Can anybody comment on why DAHDI with core timers drop down to 99.6%
occasionally?
– Is a hardware-card for timing the most efficient way to get timing even if I just use the card for the timing?

Below is some stats (trimmed, but you get the idea).

Thanks!

/Johan

** With Dahdi 2.7.0.1, and core timers:

99.998% 99.611% 99.615% 99.997% 99.993% 99.997% 99.996% 99.608%
99.999% 99.612% 99.607% 99.613% 99.999% 99.998% 99.994% 99.609%

— Results after 177 passes –

6 thoughts on - Dahdi_dummy Is More Accurate Than Core Timer?

  • Its a little different when you are using meetme as its an application built into dahdi itself and not a native asterisk application. It will therefore always use dahdi for its timing. If dahdi doesnt have a hardware interface (sangoma sell a usb based timing source if you want a hardware source) then it will use a software timing source of some form. I dont know what method it uses.

    Asterisk itself will use dahdi for timing but if res_timerfd is available it will use that itself. With your kernel version timerfd should be available. So if you run the following command asterisk will perform 1024 ticks over 1000ms which is equivalent to the dahdi test of 8192 over 8000ms
    (if you run it a few times). You can see in my case asterisk is using timerfd and no issues at all with the timing.

    > 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

    We are developing a conferencing feature and rather than use meetme with its dahdi requirement we are using confbridge10 instead so we dont have to have dahdi installed and it will use the better timerfd timing source.

    More information about timing sources can be found at :-
    https://wiki.asterisk.org/wiki/display/AST/Timing+Interfaces

  • For a typical virtual machine the values for timerfd can be significantly worse, even on otherwise powerful host systems. For a recent Fedora based test system running under VirtualBox I get typically varying values as low as 550 for “timing test 1024”, but this does not seem to have any major influence on plain calls.

    jg

  • 2013-10-02 13:55, Gareth Blades skrev:

    Yes, this is for a legacy application that are using Meetme. Maybe I was unclear above but with “core timer” I meant just “modprobe dahdi”.
    “dahdi_dummy” = “modprobe dahdi_dummy” and the hw card used “wct4xxp”.

    The wiki states:

    “As of DAHDI Linux 2.3.0 the dahdi_dummy module has been removed and its functionality moved into the main dahdi kernel module. As long as the dahdi module is loaded, it will provide timing to Asterisk either through installed telephony hardware or utilizing the kernel timing facilities when separate hardware is not available.”

    But when I test just dahdi (core timer, no dahdi_dummy) I get distortion and bad quality in the Meetme-conferences. This does not happen with dahdi_dummy.

  • Hmm…this is the first report I’ve heard of dahdi_dummy being more performant than the core timer.

    I wonder if this has something to do with the fact that you’re running under 2.6.32-5-openvz-amd64 which might be doing more work in the system timer (which is where the standard core timer work is processed).

    If you update to the latest 2.6.32-openvz kernel do you still have the audio problems in conferneces?

    After a quick search I found this stackoverflow question which talks about too much time spent in software interrupt context on
    2.6.32-5-openvz being resolved by a kernel update. This could definitely be related:

    http://serverfault.com/questions/399837/software-interrupts-cpu-time-is-high-and-keeps-growing

    This is because when using the core timer, the timer is only scheduled to fire ever 4ms. The differences in each *individual*
    measurement you see is due to timer jitter + the increased interval leaking more of the slight jitter up to userspace. However, this isn’t typically a problem when mixing audio in 20ms chunks by default as is typically done when you’re using meetme conferences.

    The number that is generally more interesting is the “Cummulative Accuracy” which shows over the entire dahdi_test how close DAHDI was to processing the expected amount of audio.

    If you run dahdi_test with the -vv flag you can see how sometimes it’s a little over and sometimes a little under. This is running under virtual box on a system configured with 4ms ticks and NO_HZ:

    # grep HZ /boot/config-$(uname -r)
    CONFIG_RCU_FAST_NO_HZ=y
    CONFIG_NO_HZ=y
    # CONFIG_HZ_100 is not set
    CONFIG_HZ_250=y
    # CONFIG_HZ_300 is not set
    # CONFIG_HZ_1000 is not set
    CONFIG_HZ%0
    CONFIG_MACHZ_WDT=m
    # dahdi_test -vv -c 10
    Opened pseudo dahdi interface, measuring accuracy…

    8192 samples in 8191.312 system clock sample intervals (99.992%)
    8192 samples in 8198.448 system clock sample intervals (99.921%)
    8192 samples in 8184.913 system clock sample intervals (99.913%)
    8192 samples in 8191.640 system clock sample intervals (99.996%)
    8192 samples in 8191.720 system clock sample intervals (99.997%)
    8192 samples in 8192.128 system clock sample intervals (99.998%)
    8192 samples in 8190.824 system clock sample intervals (99.986%)
    8192 samples in 8192.256 system clock sample intervals (99.997%)
    8192 samples in 8191.576 system clock sample intervals (99.995%)
    8192 samples in 8191.631 system clock sample intervals (99.995%)
    — Results after 10 passes –

  • 2013-10-02 17:12, Shaun Ruffell skrev:

    Okay, I guess it is just me then, that’s a good thing 🙂

    As Debian have dropped support for openvz in the current release and squeeze will not recive support after 2014-05 I will need to update these machines anyway soon – that means a new kernel, and it seems every project I found uses the redhat-kernel.

    I don’t think I dare to make such a big change to production servers as dahdi_dummy works fine (for the users – they are the one that counts). What I have noticed from dahdi_dummy is that cpu0 is nearly 95% at ~250
    channels and that got me worried (perfect quality in the meetme’s thought).

    Thanks for this detailed explination of the inner workings of dahdi!
    There are statements (mostly very old) that say that the results should not drop below 99.9 or you will have quality problems.

    My observation of quality problems in connection with results at 99.6
    seemed to confirm this, but if I understand you correctly dahdi should tolerate this.

    Seems very likley. I’ll start running tests at the replacement-system. But now I know how to troubleshoot this problem.

    On a sidenote, when I investigated the 95% cpu on the first core I did notice that all irq are hitting cpu0 (/proc/interrupts). I did some reading and installed irqbalance and now interrupts are spread evenly among the cores.

    Can this cause issues for the core timers?

  • 2013-10-03 09:52, Johan Wilfer skrev:

    After som more tests I noticed that the core timers work good with low load. But at ~200 concurrent calls *some* of the calls sounds bad. Very strange.. Switching back to dahdi_dummy solved this.

    I’ll test this more with a newer kernel, but I’m unable to do that right now. Also irqbalance solved the cpu issue (see below), so that wasn’t DAHDI.

    When I compare dahdi core timers and dahdi_dummy side-by-side I notice that dahdi_dummy spends a litte more time doing sys cpu ~10-15% for 200
    calls. And with this (old) kernel it seems more tolerant to load.

    After running test for some time my conclusion is that irqbalance on debian prevents the cpu from spiking on a busy system. So this solves the cpu issue.