Latency and especially high latency is one of the main problems when it comes to real time communication between a client and a server, so we decided to do some testing that would ultimately tell us which of the 3 main media-servers (AMS, Wowza and Red5) can achieve the lowest latency.

The Testbed

The testing was done using our flagship product, AVChat 3, for both client and server side as application.

The client side of AVChat was installed on a local machine in Romania. The local machine has the following processing and memory specifications: Intel i5 CPU @ 3.30Ghz and 8 GB of RAM, on a Windows 7 x64 OS.

For the media server I’ve used a VPS located in New York and one in Amsterdam, both with the following specifications: 4 CPUs and 8 GB of RAM, on a Linux CentOS 6.5 x64 OS.

This test was done using just one connected client.

The delay was probed in two ways:

1. Using an implemented  ‘ping’ like call from the client to the server that measured the round trip time (RTT) of the message:
2. Turning on the live-stream and measuring the delay between the broadcast and the viewing of the stream by simply holding a stopwatch app in front of the camera and measuring the difference that was shown between the 2 videos, like so:

Notice that in the image above there is a time difference of 120 ms between the two videos, which corresponds approximately with the RTT, shown in the green box, of 99 ms. The difference between the two obtained values of 21 ms can be accounted by the time it takes to encode the video on the broadcasters side and to decode the video on the viewer’s side.

The Actual Results

I’ve made a comparison table for all the 3 media-servers tested for both the RTT and the delay between broadcast stream and viewing stream and here are the results:

Media Server	RTT	Stream Delay
AMS 5.0.3 default settings	146 - 229 ms	390 ms - 520 ms
AMS 5.0.3 tweaked settings	140 - 160 ms	390 ms - 780 ms
Red5 1.0 RC1	140 - 192 ms	240 - 390 ms
Wowza Streaming Engine 4.0.3	139 - 221 ms	390 - 580 ms

The tweaked AMS settings mentioned in the table above are the ones Adobe recommends for obtaining lower latencies:

• StreamManager/Live/Queue/MaxQueueSize  in Application.xml. Setting the MaxQueueSize to lower values reduces latency but is less efficient performance wise.
• StreamManager/Live/Queue/MaxQueueDelay in Application.xml.  Decreasing the queue size reduces latency but is less efficient.
  

Overall these settings are designed to scale better with more clients connected at once. In this case is not really applicable as there is only one client connected.

The number of clients connected at any given time also plays a major role when it comes to latency. Some media-servers scale better in this regard but this is not the focus of our current experiment.

With that being said as you can see there are no major differences between the 3 media-servers when it comes to either RTT or stream delays.

To further the experiment I’ve made the same tests with an identical VPS only this time located in Amsterdam, so the connection was Romania – Amsterdam, instead of Romania – New York as previously tested, and here are the results:

Media Server	RTT	Stream Delay
AMS 5.0.3 default settings	58 - 82 ms	90 - 130 ms
Wowza Streaming Engine 4.0.3	62 - 87 ms	80 - 140 ms
Red5 1.0 RC1	59 - 91 ms	100 - 150 ms

After this final testing we can draw the following conclusion: the most important aspect when it comes to latency between client and server is the location of the server in relation to the location of the client.

Different technologies and tweaks may help with decreasing the latency but ultimately the distance between client and server will be the determining point.