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?
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).
- Can anybody comment on why DAHDI with core timers drop down to
99.6% occasionally?
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.
On another system with 10 ms timer ticks the jitter is increased, but even this
system does not have any problems mixing audio in meetme conferences:
Best: 99.608% -- Worst: 99.418% -- Average: 99.531611%
Cummulative Accuracy (not per pass): 99.995
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.
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.
- Is a hardware-card for timing the most efficient way to get timing
even if I just use the card for the timing?
I personally do not think so. The most efficient way should just be
to allow the normal kernel timers to also provide timing to your
asterisk system without the overhead of processing another
interrupt.
So I guess I would be interested to hear if a kernel update is all
you need to have good results with the core timer.
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?
--
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
