VoIP Mailing List Archives

[kristian.kielhofner at...]

Speaking of networking...

After timing that's the next "achilles heel" of RTP handing with virtualization.

Very, very few of these platforms were designed to handle massive
numbers of very small RTP packets. Everything from interrupt handling
on the actual ethernet adapter to getting the data into userspace
within the virtual instance is worrisome:

http://www.xen.org/files/xensummit_4/NetworkIO_Santos.pdf
http://forum.openvz.org/index.php?t=msg&goto=11619&

Interestingly enough the Xen paper makes it out to be really bad yet
the OpenVZ post praises Xen's performance. Without any real testing,
who knows? I just know that scaling 50pps per RTP stream (20ms
packetization) can be difficult enough on native hardware, let alone
[virtualization technology du jour].

On Thu, Jan 15, 2009 at 5:02 PM, Remko Kloosterman
<R.Kloosterman@mtel.nl> wrote:

[anthony.minessale at g...]

Yes it's hard to trust virtualized stuff because you have no idea what they skimp on in terms of realtime access.

I won't endorse using FS on a VM as i have not done it very extensively beyond openvz but I can
point out a few reasons why it has a fighting chance.

FS uses a timer architecture designed to amplify the work of one timer thread into every timer open
by FS. This single thread uses the monotonic clock on the system to try and perfrom a 1ms accurate loop.

This single loop updates a soft value for current epoch time and microsecond epoch time with the goal
of (again) being as close as possible to being accurate to 1 ms.

The timer loop also has a global matrix to all of the timing intervals being subscribed to by a timer open by FS.
The loop will tick a counter in each unique timing interval (10ms, 20ms, 60ms etc) and fire a conditional broadcast to all of the timers who are blocking for a tick. This is not perfectly accurate but close enough to end up plus or minus 2ms in resulting rtp traces.

So as long as the VM will expose the syscall down to the real monotonic clock rather than doing it's own soft timing technique you have a better chance for success.

The other issue with VM is with vmware, the bridged networking mode seems to send 2 of every RTP
packet to the channel resulting in garbled audio from the obvious timing issue introduced from too many packets.

Anyway evaluating FS with a VM is a good way to get acquainted but, with all the money saved choosing FS, many can afford to buy it a nice 8 core box for it to live on and still have money left over to support the project or ClueCon 2009 this august


On Fri, Jan 16, 2009 at 2:17 AM, Kristian Kielhofner <kristian.kielhofner@gmail.com (kristian.kielhofner@gmail.com)> wrote: