CLOUD for NDI
global ip video network
Cloud Blog #4
31st August 2017, London
Pushing Internet Connections to their limit
- using the Bandwidth Test Tool
Todays experiments use the latest version of the bandwidth test tool in the cloud for NDI local web interface.
One of the most important things to establish when setting up a Cloud for NDI network is to properly test your connections and evaluate their limits. The Bandwidth test tool is your friend here since it uses a true-to-life test between your nodes, simulating video traffic and plotting the results on a graph.
When testing you will be able to clearly see if you are over or under the limit of the connection, and you can set your per stream bandwith accordingly.
In these tests we are using a cable-modem internet connection which is rated at 12mBps uplink - the results show this is bang on target and also that cloud for NDI is able to take advantage of the entire bandwidth using its UDP based WAN acceleration and congestion control system. The other end of the test is a machine on a different ISP with at least 38mBps downlink and so should not limit the test, but will give a realistic load on the system.
One thing important to note is that this internet connection is technically capable of much higher speeds, but the cable modem is limiting the speed based on the commercial contract. Some other connections such as ADSL may be more limited by the capabilities of the physical wiring and so they will probably have a less controlled failure model.
Below Limit
The first picture shows the bandwidth test when we select 11mBps, which should be managed OK by the connection.
You can see that the red trace, which is a representation of the in-flight time of each video packet settles very quickly and does not really alter much. Also you can see there are no dropped packets (which typically indicate stress on the connection) and we are getting around 10800bps average data rate.
The green trace shows the number of packets 'in flight' - the white shows the calculated RTT and the yellow shows the congestion control throttling of sent packets (to prevent UDP flooding of the connection).
All in all this is a beautiful trace, and you can be confident to send 11mBps of video down this link. Of course - connection speed is not the only part of the equation and you will need to ensure that your CPUs are fast enough to handle the compression / decompression and other things which this test does not stress.
At Limit
The next test shows what happens when you push the connection right to its limits. In this case 12mBps.
Here you can see that things are not so smooth - it coughs a bit at the start and then finally settles down. There is another little cough towards the end of the trace and its likely that this connection will continue to struggle and might sometimes drop packets, possibly leading to a video glitch or a dropped frame, depending on your smoothing latency (which is designed to take up the slack on these things)
Beyond Limit
The final test shows what happens when you push the connection beyond its limits.
This reveals quite a lot more about the congestion control and what happens when you push too hard. The red lines are long which generally indicates that packets are sloshing around the internet for quite a while before they finally land. The green shows the number of packets still in flight which is changing on a cycle as the congestion control kicks in. The White round trip time echos the experience of the red line (which is scaled differently). The most interesting trace is the yellow lines which show the congestion control rate throttling. It lifts the limit gradually, until packets start getting dropped, then it suddenly imposes a higher limit. This cycle will continue - and we can see that we are actually only getting about 11500 bps (less than on the 'within limit' test) showing that the dropped packets, resends and other congestion control is actually reducing the overall throughput compared to operating the connection below its limit. The long flight time of the packets (red) will also have an impact on the minimum latency you can acheive since frames are being resent and generally delayed.
Conclusion
Cloud for NDI offers a great deal of flexibility and control when wrangling limited bandwidth data connections. Learning to interpret the bandwidth test in the web interface and appreciating the tools at your disposal to optimise use of the connection will give Cloud for NDI users maximum utility from a limited connection.
When data rate is limited, don't try to push the link too far - better to run it a little under capacity and reap the benefits of reliable, glitch free operation with minimum latency.