[lxc-users] Current state of LXC as it relates to VoIP / realtime transcoding

David Favor david at davidfavor.com
Sat Nov 12 21:54:45 UTC 2016


Kevin Long wrote:
> Greetings, first post to the list.
> 
> I’ve been doing some initial research,  started with docker and also LXC by way of Proxmox (which I use for virtualization).
> 
> Basically, I’m looking at rolling out Freeswitch for a whole bunch of my customers in an automated fashion, and using containers, whether via docker,  LXD or proxmox is an attractive platform for this.
> 
> But everywhere I’ve raised the idea, IRC/forums etc,  people are saying that Linux containers are still not really suitable for this, unless security is significantly compromised by allowing container processes to access features of the kernel that they normally would not be able to, in order to have a clocking mechanism that is reliable enough for real-time transcoding etc,  and this also means the solution is not portable, as it presupposes that these escalated privileges will be available in all deployment environments.
> 
> 
> Anyone have more specifics on this,  is LXD any better/worse for this application than other containerization platforms, etc?
> 
> Thanks much!
> 
> Kevin Long

Good rules for transcoding...

More slower cores better than less faster cores.

So 40 slow cores better than 8 fast cores.

Even better, building boxes around Intel's 60 core CPUs will be even better.

Trick for realtime transcoding is to keep processes pinned to a CPU, reduce
context switching (when CPUs service many processes).

Also, target reducing all other processes. In other words, strip down your
OS to run your bootable kernel + only freeswitch.

If you must use containers, using something like a BusyBox container + Freeswitch,
with no other processes running.

Containers based on BusyBox or Alpine will like produce far less context switching,
then say an Ubuntu based container.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20161112/ea60c169/attachment.html>


More information about the lxc-users mailing list