Problems with FreePBX / conference call's on Xen

6 posts / 0 new
Last post
jsuyk
jsuyk's picture
Problems with FreePBX / conference call's on Xen

Hi,

I'm busy with developing a managed hosted PX solution for the company I work for. For this, I want to use FreePBX on Xen virtual servers. As a OS we use CentOS on both the host and the guest OS.

We use Xen (3.0.3-80.el5_3.3) for virtualization and the guest OS is in this case fully virtualized, using the ISO from FreePBX.

A uname -a from the guest OS: Linux <.>.signet.nl 2.6.18-128.4.1.el5 #1 SMP Tue Aug 4 20:19:25 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux

The problem is that the timing device which is used, dahdi, seems to be working, but thinks which involves the timing device, such as conference calls and voice mail messages, are going wrong. With conference calls we can talk to each other, but sometimes we can't hear each other for a while. Suddenly, after some time, we can hear each other again and this continues for the whole conversation.

If I do a dahdi_test, I get the following results:
99.906% 99.933% 99.811% 99.996% 99.898% 99.897%, which is fairly good as far as I can see?

What can I do to further debug this case?

Thanks!

Justin.

8f27e956
8f27e956's picture
1. Is the host hardware CPU,

1. Is the host hardware CPU, Angel intel non-i7, or (b) intel i7, or (c) AMD Series II Athlon or Phenom? In case (b) and (c), the clock can be presented better to he guest O/S. In case (a), nope.

2. Check what you current -- O/S -- clock source is,

# cat /sys/devices/system/clocksource/clocksource0/available_clocksource
-and-
# cat /sys/devices/system/clocksource/clocksource0/current_clocksource

On CentOS, you can force one (of the available) clock sources over the default via the grub boot menu /etc/grub.conf file

/etc/grub.conf 
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#          kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00
#          initrd /initrd-version.img
#boot=/dev/sda
default=0
timeout=15
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.18-164.el5) with CDRW
        root (hd0,0)
        kernel /vmlinuz-2.6.18-164.el5 ro root=/dev/VolGroup00/LogVol00 clocksource=acpi_pm hdc=ide-scsi
        initrd /initrd-2.6.18-164.el5.img

On my machine, clocksource=acpi_pm boot line argument provides superior timing results. On free-standing machines, HPET, if available, is usually best. On resent generation machines with well updated BIOS, acpi_pm is usually second best. ACPI can be the worst clocksource in bad in-BIOS acpi implementations or older generation machines.

On XEN and an i7 or AMD Series II, you should be able deliver a fairly high-quality acpi_pm timer to the guest O/S, if all the XEN VM settings are correctly set. You might just want to "try each one, boot, test and see the results for yourself."

/S

8f27e956
8f27e956's picture
Using acpi_pm, #

Using acpi_pm,

# dahdi_test
Opened pseudo dahdi interface, measuring accuracy...
99.999% 99.996% 99.996% 99.996% 99.996% 99.997% 99.996% 99.997% 
99.996% 99.995% 99.997% 99.996% 99.996% 99.996% 99.996% 99.997% 
99.996% 99.995% 99.996% 99.996% 99.997% 99.997% 99.996% 99.996% 
99.997% 99.995% 99.996% 99.997% 99.996% 99.997% 99.996% 99.996% 
99.996% 99.996% 

Using the default (non-acpi_pm) clock source, the results were 99.97% average.

Good luck,
/S

jsuyk
jsuyk's picture
Thank you!

Hi,

I've been testing with the hints you all gave me and I've completed a setup which is working for us, we gonna do more testing, but it seems promising Smile

For future reference, this is what we did.

I found out that with running a CentOS X86_64 Xen guest, you only get one available time-source, jiffies. With this timing device we couldn't get a reliable result. Because of this, I installed a CentOS x86 Xen guest. With this OS, you have a lot more timing devices, with for example, hpet. This timing device we use at the moment.

But, this was not enough, I needed to alter the timing divider as I found out, so the grub entry is as follows:
kernel /vmlinuz-2.6.18-164.2.1.el5 ro root=/dev/VolGroup00/LogVol00 divider=10 clocksource=hpet

With this, I get a 99,5 accurate results with dahdi_test and no droppings, which is the most important.

8f27e956
8f27e956's picture
Quote: But, this was not

Quote:
But, this was not enough, I needed to alter the timing divider as I found out, so the grub entry is as follows:
kernel /vmlinuz-2.6.18-164.2.1.el5 ro root=/dev/VolGroup00/LogVol00 divider=10 clocksource=hpet

I'm glad the "clocksource=" got you going in the right direction. May I ask you where you gathered the "divider=10" information from. I'm not aware of that being necessary and would like to read more on it.

Thanks,
/S

jsuyk
jsuyk's picture
Hi, No problem, I used the