No cookie for

The MAK RTI has many configuration parameters that control how it connects federates to federations and how it implements the various RTI services. You can use these parameters to tune the performance of your federates and federations. In MAK RTI 4.4.2 and previous releases, these parameters were set in the following ways:

Last modified on Read more
Hits: 4863 0 Comments

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

Last modified on Read more
Hits: 3143 0 Comments

We’ve talked about Latency and we’ve talked about Throughput in the MAK RTI, but now we’ll get into HLA Services.

One major advantage of the MÄK RTI is its ability to turn HLA services on and off. If you are not using DDM, for example, you can have the RTI turn that feature off to get a performance increase. 

Two things need to be noted when using this feature. First, even with all services turned on, the MÄK RTI is very fast. The test federate could still send over 120 thousand updates per second. That is much more than every simulator that we know of, so users really should not fear leaving all services on. Second, every service has its own overhead cost, as is shown in the following chart:

Last modified on Read more
Hits: 3308 0 Comments

Let’s talk about MÄK RTI Throughput. (If you’re interested in the other MÄK RTI Benchmark posts, check out our previous blog on Latency benchmarking.)

Throughput is a measure of how fast an RTI can write to and read from the network. Because throughput tells you how well an RTI can handle federations with large numbers of objects that are frequently sending updates, it is often an even more important metric of RTI performance than latency. In many real-time platform-level simulations, updates or interactions that contain 100-150 bytes of data are fairly typical. For packets this size, we have demonstrated a throughput of over 170 thousand packets per second on our test system.

For larger packets, we do even better. In fact, for packets with 5000 bytes of payload data, we have achieved a throughput of over 22 thousand packets per second, around 90% of the theoretical maximum for a 1 gigabit network. In our original test system, we consistently topped out at 90% payload usage (not counting our minimal HLA overhead); we re-ran all our tests in a 10 gigabit network to get a better idea of what our limit is and we measured over 60 thousand messages over 5,000 bytes per second.

Last modified on Read more
Hits: 8210 0 Comments

Welcome to the first topic of our multi-post series highlighting specifics about the performance of the MÄK RTI! We’ll start with the topic of Latency, or the amount of time it takes for data to reach its destination. 

Much of the literature on distributed simulations indicates that latencies of up to 30-100 milliseconds are tolerable without losing the feeling of real-time interactivity. Even a 3D graphics-based application running at 60Hz has 16 milliseconds in which to compute and draw each frame, meaning that latencies of 5-10 milliseconds may not even effect the time at which a particular event is drawn. Meanwhile, typical latencies for the MÄK RTI are closer to 100 microseconds on our gigabit network "“ fast enough to meet the needs of even the most sensitive real-time simulations. 

Latency Benchmark Info

Last modified on Read more
Hits: 7095 0 Comments