[asterisk-users] Dahdi_dummy is more accurate than core timer?
Johan Wilfer
lists at jttech.se
Thu Oct 17 04:20:18 CDT 2013
2013-10-03 09:52, Johan Wilfer skrev:
> 2013-10-02 17:12, Shaun Ruffell skrev:
>> On Wed, Oct 02, 2013 at 01:17:15PM +0200, Johan Wilfer wrote:
>>> 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.
>>
>> 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?
>
> 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).
>
>> When you explictly load the dahdi_dummy module, your results can
>> change in a couple of ways. 1) dahdi_dummy tries to always schedule
>> the system timer to fire at 1ms intervals (which it only will if the
>> system is configured for CONFIG_HZ=1000). 2) If on a newer kernel,
>> dahdi dummy will use kernel high resolution timers to increase the
>> precision of the timer. However this shouldn't be necessary since
>> the jitter in the normal kernel timer should be small compared to
>> all the other jitter in a voip system.
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.
>
> 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?
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.
--
Johan Wilfer
More information about the asterisk-users
mailing list