'jiffies' is both the available and current clock source.
How were you able to resolve the call transfer problem?
The jiffies clocksource should be fine. But, here is what I had posted over on the "greenie" forum. This system was a SIP-only setup and needed to use DAHDi for a timing source.
I ran into this problem on one of the servers we were in the process of deploying using a different Asterisk distribution. This affected music-on-hold (to a very minor degree, though), paging, conferencing, call transfers & parking - basically, anything that relies on the DAHDi timing source. However, intercom calls and extension-to-extension calls appeared to work just fine.
My most noticeable symptom outside the above issues: The NTP daemon on the server would try to re-sync about 80 times per hour. The clock would skew 3 seconds about every 3-4 minutes.
I install munin on each server I deploy as it will give you a quick visual reference on the state of the system. The munin graph for NTP was all over the place. High jitter and offset against a local (LAN) NTP source. Everything else about the system appeared normal.
After some digging, I found out that the Linux kernel uses a certain clocksource for timing at boot time. What I never found out is how it determines which clocksource to use. It appears to be automatic unless you specify it. Each reboot, the system might be using a different clocksource - which explained why it worked initially, but not after subsequent reboots.
Before you can set this at boot time, you have to know what is available in your kernel.
First, check which clocksource is being used:
Code:
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
This will tell you the current clocksource that the kernel is using.
In my case, the system was using
tsc (time-stamp counter). I found out that some hardware has issues making use of tsc. You may even see tsc (use dmesg) as "unstable". I then looked at the other available clocksources:
Code:
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
This returned
acpi_pm jiffies hpet tsc pit. I compared this to another system and found out it was using
hpet (high-precision event timer). I switched the misbehaving system over to
hpet by issuing:
Code:
echo hpet > /sys/devices/system/clocksource/clocksource0/current_clocksource
You can only do the above if it's available as an clocksource. If it doesn't exist in
available_clocksource, it won't work.
hpet is only available on the later kernel builds in CentOS.
All the problems mentioned above disappeared on that system. NTP went back to normal. You can make sure it always uses what you want by putting it in the grub.conf file For example, setting
hpet by adding clocksource=hpet to the kernel line in your grub.conf file:
Code:
kernel /vmlinuz-2.6.18-128.10.1.el5 ro root=/dev/md0 clocksource=hpet
The kernel timing (or lack thereof) will affect DAHDi along with everything else. I know the above may be a bit of a stretch for your problem. It's not something I've ever encountered before or since, thankfully.
Phone System 