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?
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.”
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
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.
[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[/quote]
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.
