[PVE-User] Time synchronisation

[karl-theo hofer]

Hi 
Because Freeswitch is calling out both legs and when the lys are connected
FS is bridging them together
In this constellation it can happen that leg A is running G711 and leg B
G729 now freeswitch has to trancode the media.
Because voice is a realtime application the VM needs access to hardware
clock, which is very important for conferences and transcoding.
KR
KT


On 11/08/14 19:45, "Adam Thompson" <athompso at athompso.net> wrote:

>On 14-08-11 11:44 AM, Joel S. | VOZELIA wrote:
>> Did you get any feedback or advice? I'm interested too.
>>> We are running a proxmox 3.24 on top a ubuntu 12.04 and a freeswitch
>>> On the freeswitch we have to transcode voice from G711 to G729 and
>>>vice versa
>>> to perform this correctly we have to have the hardware and the
>>>software in
>>> perfect clock sync.
>>> My question is now do you have a best practice for this or does
>>>someone have
>>> experience with proxmox VE and freeswitch?
>
>I'm running a 4-node PVE cluster, each node being 2 x 4-core (+HT) Xeon
>L5520 with 48GB RAM.  None of the nodes are anywhere near capacity, so
>I'm not contending for CPU cycles or network bandwidth right now.
>On top of that, I'm running AsteriskNOW (aka FreePBX Distro) in an
>all-G.711 environment.  No analog lines or analog hardware exists except
>for two ATAs.
>I am using Asterisk as a B2BUA which means it's in the voice path for
>every call; I'm not transcoding, however.
>I very occasionally encounter minor glitches in voice call quality when
>the link to my upstream SIP provider is congested, but I have never
>encountered any problems with calls internally.
>Latency isn't quite as low as I'd like, but it's still well within
>acceptable limits.
>
>I have done NO tweaking yet, nor have I implemented any QoS yet, because
>my results have shown that I don't need to.
>I expect to have to give that VM more CPU cycles as the cluster becomes
>more heavily loaded, and I also expect to have to implement QoS at the
>network layer... I probably won't have to do network QoS on the PVE
>hosts, they each have more than enough bandwidth to the switches right
>now to accomodate VoIP without any packet loss.
>
>Note that the vmbr (linux bridging module) does add a measurable amount
>of latency; I haven't tried VT-d yet, because I'd rather retain the
>ability to hot-migrate the VM than reduce latency by ~0.5msec.
>
>However, my question is: what on earth does the OP mean by ³c"?  Unless
>you're running DADHi cards,
>there is no hardware to keep in sync; and running DADHi (or worse,
>zaptel) through VT-d would just be... well... bizarre.  And even in that
>case, there still isn't really anything that can get out of sync; if you
>lose sync on a T1 trunk, you lose the entire set of channels - it's
>either OK or it's not, and it has nothing to do with transcoding.
>
>Perhaps the OP is talking about some sort of PCI co-processor that
>handles transcoding for him???
>
>-- 
>-Adam Thompson
>  athompso at athompso.net
>