[Spce-user] CPU timing in virtual enviroments

[Matthew Ogden]

Thanks for the feedback guys.

The interesting thing about the timing sources there. I have tried dummy
dahdi and all other sources but conf bridge just doesn't seem to gel so
well.

Given that you guys have positive experiences I would be keen to see the
exact timing source and which conf method is used etc what OS is in use and
any kernel parameters is has (preferably if that system was running on
VMware)

Kind regards

On 17 Jan 2018 11:00, "Jon Bonilla (Manwe)" <manwe at sipdoc.net> wrote:

> El Tue, 16 Jan 2018 17:37:00 +0200
> Matthew Ogden <matthew at ogden.co.za> escribió:
>
> > Hi All
> >
> > I know this is question is not completely SPCE related, but since Sipwise
> > is using asterisk as a component, and more importantly, since so many of
> of
> > the SPCE users understand those components, not just asterisk, I thought
> it
> > an interesting enough question for the community.
> >
> > All my own servers are are Virtual. Whether they be Asterisk or SPCE.  I
> > use VMWare as the hypervisor.
> >
> > in my instance, SPCE does not seem to have a problem with timing, because
> > the media relay can actually have small amounts of jitter and the edge
> > devices (phones or PBXs), are sorting this out.
> >
> > But in asterisk case, most things also work fine for boxes that run
> > asterisk. Except for conferencing. In my case, Meetme seems to work
> better
> > than conf-bridge (bad quality on meetme, but unusable on conf-bridge)
> >
> > I know that in asterisk case the timer options are available instead of
> > dadhi cards. I know that Linux can have different time resolutions of the
> > kernel, though more modern systems system tro default to 10ms anyhow.
> >
> > Does anyone out there consider themselves as a definitive guide on the
> > subject? I know that the Sipwise guys and anyone else contributing to
> media
> > relay projects probably see this as incredibly simple, but to me, I
> doesn't
> > make sense that with all the new hardware available based around
> > virtualization, to be able to have reliable timing sources or small
> enough
> > timing resolutions to take 2x  20ms packets align, merge their sound them
> > and send them to other system.
> >
>
> Hi Mathew
>
> There were timing problems many years ago in virtual environments and with
> older asterisk versions. That was solved and shouldn't be an issue with a
> recent asterisk and vmware software.
>
> Old asterisk meetme modules used zapata/dahdi as timing source. Not having
> a
> card to provide the clock forced us to load a dummy card module and it
> wasn't
> accurate enough for timing critical apps like meetme. Later, asterisk
> released
> other timing source options like timerfd which almost solved the issues
> but I
> think meetme contined using zpata/dahdi as timing source (not 100% sure of
> this). Confbridge will for sure use latest and modern timing sources so it
> should work better IMHO regarding timing.
>
> https://wiki.asterisk.org/wiki/display/AST/Timing+Interfaces
>
> In spce asterisk is an app server, a call termination point and not
> fundamental
> part of the system. You can have timing issues and never notice them in the
> spce because your calls usually don't use asterisk at all.
>
>
> --
> https://pekepbx.com
>
> _______________________________________________
> Spce-user mailing list
> Spce-user at lists.sipwise.com
> https://lists.sipwise.com/listinfo/spce-user
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20180117/38cc9404/attachment-0001.html>