No cookie for

MÄK RTI Performance Blog 5: Bundling and Compression Benchmarks

If you’re just joining us in this 5 part blog series, welcome! Check out the previous few blogs describing the goal of this series, Latency benchmark info, Throughput benchmark info, and HLA Services benchmark info. 

In addition to turning services on and off as noted in my last blog, the MÄK RTI provides a few ways to reduce the traffic in the network. The two most commonly used methods to do this are bundling and compression. The ideal value to set both of these features varies by the type of simulation being done. Thus it is best to understand their effects on traffic to use effectively. The following graph shows the effects of bundling on network throughput:

MAK_RTI_Performance_Paperbundling2

The above graph shows our test application with message bundling turned on and off. For this test, the bundling was set at the default 1400 bytes, or just a little under the UDP packet maximum. We also show bundling at 5,000 bytes for comparison. A cursory look at the graph will show a significant speed improvement on small message counts. The improvements then start decreasing until you actually get a small penalty under medium message counts. Once messages become bigger than the bundle value, bundling stops occurring and the performance results are the same as not bundling at all. 

Understanding why this happens is the trick to knowing when to set message bundling. On small and very frequent messages, message bundling dramatically improves performance by reducing the significant cost of the TCP or UDP socket. This is at a price of an extra copy, but as you can see by the graph, it is worth the cost. However, once you reach the point where you can only send one message per packet, now you actually are doing worse than you would with message bundling turned off, since the extra copy is still there. You get the entire penalty and none of the improvements. 

It should be noted that if your simulation is using RPR and is mostly sending entity updates - those are perfect for bundling. In fact, it has been our experience that most HLA exercises send small sized updates, therefore we recommend that unless you know you are doing something special, you should keep message bundling turned on. 

When looking at this chart, one might think that even larger bundling values would be better, as a bundling value of 5000 provides a small but clear improvement in throughput even at smaller counts. There are drawbacks with going bigger, however. Larger packets have a higher tendency to drop while being sent through UDP. At 5,000 bytes, the drops were still minimal, but increasing that value further, will certainly degrade your packet completion count. For that reason, we have defaulted bundling to 1400 bytes, which should still cause significant speed up but is well below the safety line for dropped packets. 

MAK_RTI_Performance_Papercompression1

As you can see above, message compression is almost the exact opposite of bundling. For smallsized messages, compression doesn’t really provide much improvement in payload size and there is a very real CPU cost to compression. 

If processing time is your limitation, as is the case for most federates, then compression would be counterproductive. You might send smaller sized packets, but your throughput will be negatively affected. Even if you are sending larger messages of easily compressible data as we are in this test, there is no throughput gain at any scale. Most large RPR-based simulations will probably not benefit from compression either, given the expected small size of the average messages.

Compression does reduce the number of bytes sent on the network. Therefore it can provide a faster exercise when faced with an overloaded network. Therefore, if your exercise is running in a 3G environment or large packet 1 gigabit exercises, then you should definitely experiment with this setting to find your optimal results.

MÄK CST Fills the Command and Staff Training Capab...
VR-Forces 4.3 Simulation Model Set Enhancements

By accepting you will be accessing a service provided by a third-party external to https://www.mak.com/