1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
  2. If you had a PIAF Forum account in the vBulletin days, log in with your old credentials. Otherwise, sign up again and we'll get you back in business as soon as we can.
  3. A serious FreePBX vulnerability has been reported. Update your Framework Module immediately. Click here for details.

FOOD FOR THOUGHT Best Timing Source

Discussion in 'Trunks' started by kflorian, Dec 23, 2010.

  1. kflorian Member

    A pointer to a good thread on the subject would be appreciated. I have reviewed a large handful of threads here which contain the words "timing source" but did not find what would seem to be definitive info. I do note in this thread: http://pbxinaflash.com/forum/showthread.php?t=8544&highlight=timing source

    that the Sangoma UT-50 or 51 is recommended even when PTSN support is not required. Does that advice apply in my case?

    I am running the PBX in a VM on ESXI 4.1. I have plenty of ram and up/down bandwidth appears more than adequete. I've given the IP of the server "Premium" status in my dd-wrt-enabled Linksys router. Having said that, it is of course possible that running this in a vm issue and my situation is untenable for various performance-related reasons.


    I do not need PTSN support.

    For the next several years I need to support only two simultaneous calls.

    I am able to receive / make calls on my install using x-lite but there are occassional 'breaks' in the inbound sound stream....just enough so to probably make it unusable as currently configured.

    I am using the "purple" install configured for for-fee Vitelity service. All else is in pristine, out-of-the-box configuration.
    FreePBX: 2.8.04
    Asterisk: 1.8.1.1
    Centos: 5.5
  2. Linetux Guru

    You have two things working against you.

    One is ESX. The other is the timing. But ESX is a double-whammy.

    ESX doesn't easily let you pass devices that are needed by Asterisk into the VM. If you do, it's a tricky adventure. But most importantly, your VM's health is dependent on everything else that's going on in that host. Got backups going on at night? You might need to forget about making calls.

    Now Proxmox and other VM hosts use a different technology which cures the timing/slicing issues. Sometimes it's a lot easier in these devices to pass hardware up into the VM for a real timing source.

    But generally speaking, I don't touch virtualized phone systems in production environments. Others will argue their own experience here (please do, as a rounded discussion is a healthy one) - but for me, it's physical-or-nothing.

    That being said, one of the most visual ways of determining if you have a problem is using ztspeed. Blanche has a great page written up on this that you should read:

    http://www.cadvision.com/blanchas/Asterisk/ZaptelPerformanceTesting.html

    Run that on your VM and see what you get. I'd be willing to bet you're in the 96-97% range, which is kind of unacceptable (that's the value I get off of a very fast IBM Xeon box running ESX 4 with light loading on the host).

    If you don't have a choice and can't put a timing source into the box, the best you can do is tune the kernel as best you can for a good timing source. That's a whole 'nother discussion.
  3. kflorian Member

    Thank you

    Thanks for the input. I will give the timing tests a look and report the results for the record book.

    Ken
  4. A timing source is.......

    DAHDI

    All you have to do is to download and install DAHDI, it will detect that there is no cards, but then load a dummy dahdi device, and presto, you have a timing source.

    You will only need this if you are planning to use Conferencing.
  5. kflorian Member

    Any other stand-alone tool I can use beside zttest? I don't have zaptel drivers installed and won't be needing them.

    Ken
  6. Linetux Guru

    I believe it's been renamed to 'dahditest' - same tool.

    And Mickecarlsson, keep telling yourself that, but what's the #2 reason (right behind scalability) for FreeSwitch? That's right, timing. The built-in stuff is crap, and I've got a lot of experience to back that up. If you say otherwise, that just means you haven't done enough (or big enough) installs yet.
  7. dswartz Guru

    linetux, I was under the impression that running a PV appliance, the issue with timing is not the case any more. Is that incorrect?
  8. Linetux Guru

    Okay, you're going to make me get out my soapbox... hang on.... <scraaaapppppeee>

    That's the whole point.

    Yes, the issue is less of a problem than it is with a fully virtualized host. But no, it doesn't make the problem go away.

    Timing is a real problem for Asterisk. It introduces a lot of small issues that, depending on the installation, can either be a deal breaker or result in the device being replaced by something "supported" (sound familiar?)

    Anyway, this is one of the big problems with Asterisk. While at Astricon this year, I spent a lot of time discussing this subject with a lot of folks who've been in it for a lot longer than most of everyone else has... and the main consensus is that when you make something as 'easy' as PIAF (not picking, but it's the obvious target), folks sometimes (no, make that often) don't understand all of the nuances of the setup, then when there's a problem or an issue, they don't know how to fix it. Is this a documentation problem? Maybe. Is this an immaturity problem? Probably. Whatever the issue, when you don't understand the product fully, you can't support it.

    Now, not all of us can understand a product 100%. But that's when we're able to pick up the phone and call to get an answer (and pay, of course). Problem is, there's really nothing like that setup in the ecosystem - at least in a hierarchal, organized way. This leads to problem installations, which leds to unhappy customers, which leads to Asterisk getting a bad name.

    So please, understand the timing issue. Test, and make sure you're able to accept the results you're expecting. If it fits your situation, great ... but make sure you know what you're getting yourself into before you sell yourself - or more importantly anyone else - that it's the right way to go.

    Okay, I'll get off now....
  9. dswartz Guru

    " Yes, the issue is less of a problem than it is with a fully virtualized host. But no, it doesn't make the problem go away."

    I was hoping you would explain why this the case?
  10. Linetux Guru

    I thought I covered that. Maybe not; no matter.

    As I believe you understand, para-virtualization exposes parts of the underlying hardware allowing the guest OS direct access to some things, chief among them hardware clocks and timing which is absolutely critical to Asterisk.

    If you run Asterisk as a fully virtualized guest, it is unlikely to run properly because the clock bounces all over the place. This is why you are supposed to install "VMWare tools" which helps mitigate these issues. There might be other similar products for other VM software, but I'm most familiar with Xen and VMWare.

    This is evident when you run the 'zttool' applet and compare it to the results of a non-virtualized guest. It's also evident when you compare ztdummy to a PBX that has a real timing source in it. Although I'm talking about Zaptel, the same holds true for Dadhi. I've posted on this forum about the same issue in more detail as well.

    When you run Asterisk on Xen (or Proxmox), it runs great. There is also a Xen kernel modules for Digium cards meaning you install the Digium cards in the Xen box and then all the virtual machines can access them just as if they were installed on the local system. This gives you the ability to have a *real* timing source for your virtualized PBX.

    I don't have any experience with running multiple PBX's off of a single timing source... I don't imagine it's possible. But you could always put a bunch of cards in a Xen host and go at it.

    Just for the record, there is a massive difference between virtualization installed on top of an existing OS (such as VirtualBox, Microsoft Virtualization and most of the free VMWare products), and "bare metal" virtualization like ESX, Proxmox and Xen. Bare metal is the only way to go for serious virtualization.
  11. dswartz Guru

    I think we must have had some kind of disconnect here. I was under the impression that because a PVM has access to the real clock, the timing issue was not there anymore, but the comment you made (that I quoted) implied (I thought) that that was not the case; but your most recent post doesn't address that?
  12. Jake Member

    VM Ware Server

    I have had good luck with VM Ware's server virtualization running on Windows 2003 Server. I had no timing issues and the call quality was great. I did have to load CentOS VM Kernel and I did have Dahdi loaded but other then that. I hope that ESX would behave about the same but I could be wrong.
  13. Linetux Guru

    I'm saying that overall, using the PC's hardware clock is unreliable.

    Even moreso when you're talking about virtualized devices. Less so when it's a PVM.

    That's the point.

    If you don't understand (as many) about the difference between 'real' timing and ztdummy/Dahdi, you need to educate yourself to make sure it's not going to be a problem for you in your installations.

    As I've already said, sometimes it's perfectly okay. But you have to figure that out for your situation - that's nothing anyone can tell you without knowing your exact situation.
  14. dswartz Guru

    Yeah, I get that. What I wasn't not getting was why the PC clock is any less reliable in a PVM than in fully native mode.
  15. Linetux Guru

    10-4, now I'm with you.

    Let's think about timing for a second. Timing is, of course, sensitive. It's sensitive because it's so damned accurate. It has to be... our ears can pick up on very small nuances or inaccuracies in timing - it really throws off conversations. So that, in a nutshell, is why we need it.

    Now think about the scale that we're dealing with. We're talking about nano-seconds here... kind of hard to grasp (the human mind can only thing so-small and so-big before things just kind of break down), but just keep it in mind.

    Now let's go look at PC's, and the clock. So if you have a non-VM host, it's going to be 1:1... in other words, there's nothing between the clock and the Asterisk timing device (zaptel/dahdi).

    Now shift a little over to a VM. Now you're shimming the device - as we've discussed, sometimes more than others. But you're still shimming it. Shims means interpreters. Anything that gets between the source and destination is going to induce latency - guaranteed. Is it bad enough to cause problems? Perhaps not.... but quite honestly, I've never bothered to take the time to get timing samples from a host, then throw a VM on the same host and see what it looks like. So I can't say to what degree you're going to see a difference, but there will be one. The significance, as I've said a few times, is fully dependent on your application.

    Hope that helps.
  16. dswartz Guru

    Okay, I see what you are saying. My understanding of how openvz works is that is is basically a variant of a chroot/jail setup, so there is actually no emulation overhead for things like this. My setup is a home/soho one, so not heavily loaded anyway.
  17. luckman212 Guru

    So back to the OPs original question, would the UT50/UT51 be the best solution for a reliable timing source in a pbx without any DAHDI hardware / TDM cards in it? Are there any other (better?) hardware timing sources for CentOS systems that can't use the new res_timing_timerfd.so module due to lack of kernel support?
  18. Linetux Guru

    The UT50/51 is a very reliable timing source. However, I don't have any practical experience passing USB devices to a guest from a host, so I can't comment on overall effectiveness in a virtual environment.
  19. malcolmd Guru

    I've been on virtualized installations where the software derived timer is superior, by an order of magnitude, to a timer derived from USB-driven hardware.

    res_timing_timerfd is your best bet. But, you'll need kernel 2.6.25 or greater and glibc 2.8 or greater.
  20. luckman212 Guru

    On my system I have the following timers available, according to cat /sys/devices/system/clocksource/clocksource0/available_clocksource
    acpi_pm jiffies hpet tsc pit


    My /etc/grub.conf kernel boot line is:
    kernel /vmlinuz-2.6.18-194.17.4.el5 ro root=LABEL=/ clocksource=hpet

    The system reports from cat /sys/devices/system/clocksource/clocksource0/current_clocksource that I am successfully booted with HPET. :thumbsup:

    However, I don't think for some reason that my dahdi_dummy is utilizing this. From various posts around the web it seems that I should be seeing something like the following in my dmesg | grep dahdi output:

    dahdi: Telephony Interface Registered on major 196
    dahdi: Version: 2.1.0.4
    dahdi_dummy: Trying to load High Resolution Timer
    dahdi_dummy: Initialized High Resolution Timer
    dahdi_dummy: Starting High Resolution Timer
    dahdi_dummy: High Resolution Timer started, good to go


    But all I have is:
    dahdi: Telephony Interface Registered on major 196
    dahdi: Version: 2.4.0
    dahdi_transcode: Loaded.
    dahdi: Registered tone zone 0 (United States / North America)


    Here's an interesting bit from /usr/src/dahdi/linux/drivers/dahdi/dahdi_dummy.c:
    /*
    * To use the high resolution timers, in your kernel CONFIG_HIGH_RES_TIMERS
    * needs to be enabled (Processor type and features -> High Resolution
    * Timer Support), and optionally HPET (Processor type and features ->
    * HPET Timer Support) provides a better clock source.
    */


    Does this mean I would need to (arg) build a new kernel to enable this feature? If I was going to attempt to switch kernels on this PiaF box, I would rather try to go with 2.6.25 and glibc 2.8 + make use of the res_timing_timerfd.

    Here's the result of grep HPET /boot/config-2.6.18-194.17.4.el5 on my system:
    CONFIG_HPET_TIMER=y
    CONFIG_HPET_EMULATE_RTC=y
    CONFIG_HPET=y
    # CONFIG_HPET_RTC_IRQ is not set
    # CONFIG_HPET_MMAP is not set

    Any ideas on the best path to take from here? Not happy with my dahdi_test results (avg is ~99.7 and I am getting choppy sound occasionally, on this Aspire Revo U1600 w/ 2GB ram)

Share This Page