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
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
