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:
Although there are many criteria for evaluating and comparing RTI implementations, one of the most important is performance. Choosing an RTI that maximizes throughput and minimizes latency, bandwidth, and CPU usage can mean the difference between success and failure for an HLA simulation program.
Performance, however, is a difficult thing to quantify. There is not just one number that defines an RTI. There are many types of HLA exercises with wildly varying requirements. High performance on one exercise does not necessarily mean high performance on a different exercise. How many federates are you using? How many updates per second? Are you using a WAN configuration? Are you using any of the services such as DDM or time management? Are you using a Java or a C++ federate? Are you using HLA 1.3 or HLA Evolved?
The answer to all of these questions can have significant effects on performance. In order to provide the flexibility that meets the needs of most users, an RTl’s configuration options must be robust. It should support the needs of most users out of the box. It must also provide the ability to reconfigure performance capabilities for the exceptional cases, if necessary.
VT MÄK, Antycip Simulation, and Thales have entered into a multi-year corporate-wide agreement to provide the MÄK RTI to Thales. Using the MÄK RTI, Thales will provide High Level Architecture (HLA) Evolved and HLA 1.3 compatibility to their range of simulations for training, experimentation, and demonstration.
The MÄK RTI is a proven solution that enables HLA federations to rapidly and efficiently communicate. It has been chosen for both large and small federations because of its support for a wide variety of network topologies and architectures, ease of configuration, high performance, and its range of supported platforms.
MÄK’s first HLA certification came in 1998 and since then, the company has been on the leading edge of developing and implementing the standard. MÄK’s tools and services have helped hundreds of organizations around the world comply with multiple standards including HLA, DIS, and DDS.
This is part 5 in my series of blog posts on RTI RID configuration tips. Check out the previous posts in this series, and stay tuned for more to come.
Part 1: RID Consistency Checking
Part 2: The Advantages of MTL
This is part 3 in my series of blog posts on RTI RID configuration tips. Each of these tips, unless otherwise noted, works in HLA 1.3, HLA 1516-2000, or HLA Evolved. Check out the previous posts in this series, and stay tuned for more to come.
This is part 4 in my series of blog posts on RTI RID configuration tips. Each of these tips, unless otherwise noted, works in HLA 1.3, HLA 1516-2000, or HLA Evolved. Check out the previous posts in this series, and stay tuned for more to come.
<
Part 1: RID Consistency Checking
This is the 6th and final part in my series of blog posts on RTI RID configuration tips. Each of these tips, unless otherwise noted, works in HLA 1.3, HLA 1516-2000, or HLA Evolved. If you’re interested in learning how to make better use of your RID file, check out the previous posts in this series as well.
Part 1: RID Consistency Checking
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:
We are pleased to announce the release of MÄK RTI 4.4, a major feature release that significantly improves performance, as well as adds several new features.
While MÄK has always focused on performance with our RTI, over the last year we doubled our efforts. Version 4.4 is the second major release with significant improvements in performance. For this release, we have overhauled the message sending and receiving process to dramatically reduce the time to process incoming messages from the network while significantly lowering CPU processing time. Additionally, we have separated the sending and receiving of messages into separate threads so that performance will not be affected when either one of these is heavily taxed. To better understand what makes the MÄK RTI the fastest RTI on the market please read this.
We didn’t stop with performance: you can now use the MÄK RTI with FOM Modules in Lightweight Mode and international customers can now easily translate the text found in the RTI assistant to target the local language.
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:
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.
By Aaron DuBois - The MAK RTI version 4.0 was released on the same day that IEEE officially released the IEEE 1516-2010 standard, otherwise known as HLA Evolved. We were very excited to be able to fully support the new version of HLA from the very first day the standard was out. The down side, however, is that we did all of our development for RTI 4.0 before the standard was finalized, and even at the very end there were minor tweaks happening. Unfortunately we failed to capture the very last change made to the C++ API. As a result, versions 4.0-4.0.3 of the MAK RTI were built against a nearly-final version of the C++ headers, which means that those versions are not quite compatible with the final version of the specification. The new release of RTI 4.0.4 fixes this, and is now built against the final version of the header files.
The final change that was not included in the previous RTI versions was related to a defect in one of the final draft versions of the specification. We actually wrote about this defect in a previous blog post. The problem was with the createFederationExecution RTIambassador methods. There were three variations of this method, each with different input parameters. Some of these parameters contained default values, and as a result there was an ambiguity between two of the variations. We mistakenly thought that there hadn’t been time to get a fix for this ambiguity into the spec, but apparently it did make it in after all. The third variation was renamed to createFederationExecutionWithMIM.
So what does this mean? If you are an RTI customer, but are currently using HLA 1.3 or 1516-2000, this doesn’t affect you at all. The new version of the RTI contains a few bug fixes, so you may want to upgrade anyway, but the HLA Evolved API change won’t be a problem unless you decide to move to the new standard. If you are using HLA Evolved, however, we strongly recommend that you upgrade to the new release and recompile your federate against the new header files. If you were using the third variation of createFederationExecution you will also need to edit your code to use the renamed method. Otherwise, no code changes are necessary. Once you recompile your federate, it will then be truly compatible with the final version of the HLA Evolved specification.
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
Because HLA has so many configuration options, it can be frustrating to learn that your system isn’t communicating when you think everything is set up correctly. The MÄK RTI team works very hard to make it as easy to use as possible, but sometimes things go wrong. HLA federations can be very complicated.
Luckily, the new MÄK RTI 4.2 provides a revamped RTI Assistant that will help you find the problem and fix it faster than ever. In this blog, we will identify and attempt to remedy the most common problems.
Are all the federates correctly connected?
Double clicking on your RTI Assistant tray icon opens up the Federations View.
This is part 2 in my series of blog posts on RTI RID configuration tips. Each of these tips, unless otherwise noted, works in HLA 1.3, HLA 1516-2000, or HLA Evolved. Take a look at part 1 HERE, and stay tuned for future posts in this series.
The RID file is written in MTL. MTL stands for MÄK Technologies Lisp. MTL is basically a limited form of the Lisp programming language. The primary purpose of the RID MTL file is to set specific variables which are parsed by the RTI’s MTL parser and loaded into configuration settings. The same goal could be achieved using other formats such as XML (another popular MÄK configuration file format), but there are advantages to MTL.
The first important thing to understand is the difference between the setq and setqb commands. The "b’ in the setqb command stands for "bound". This command is used to set the bound variables that are recognized by the RTI. So the only variables set using setqb should be those that are documented RID parameters that are accepted by the RTI. The setq command, however, can be used to set any temporary variables you want that can be used in RID processing. Why would you want to do this? Well, used in conjunction with other features of MTL, this can make your life just a little bit easier. Here’s an example:
As anyone who has edited a RID file for the RTI can tell you, there are a lot of different parameters available to customize how you want the RTI to function. It can be pretty overwhelming. Over the years we’ve tried to make RTI configuration as simple as possible, while still preserving the ability for users to get their hands dirty with the nitty-gritty details of RTI operation. To this end we’ve tried to choose default settings that make sense, and we created the RTI Assistant to allow you to quickly and easily edit the most commonly used connection parameters from a simple GUI. Hopefully that helps many of you stay out of the RID file as much as possible, but chances are at some point you will have to take the plunge and delve into it. To help you out when that day comes, I’ll be writing a series of blog posts with tips and tricks that will hopefully come in handy. I’m not going to go through each parameter in detail. Instead I’m going to cover some general configuration techniques and tips on debugging potential RID issues. If you have a question about individual RID parameters, please see the back of the RTI Reference Manual or drop us an email at This email address is being protected from spambots. You need JavaScript enabled to view it.. Unless otherwise noted, all of the tips I’ll be discussing can be used for all HLA versions: HLA 1.3, HLA 1516-2000, and HLA Evolved.
When adding features to a product we frequently need to make design decisions. Often these decisions come after many hours of sometimes heated arguments. Today I want to write about one of the design decisions we made with the RTI, and what its implications for the future are. I want to talk about the two main information dialogs in the RTI Assistant: the Federations View, and the Network Component View.
Today I want to discuss a key design decision we made with the RTI in version 3.4: we removed the rtiexec user interface. For many years the MÄK RTI’s rtiexec had two user interfaces: a console and a QT based GUI. In version 3.4, we removed both options and made the rtiexec a simple daemon with no interactive interface.
Frequently people write to support and say“My RTI Crashed!”, or they write "I have 10 federates, and the RTI is installed on Machine X." When I read sentences like these I sometimes cringe. I cringe because RTIs really don’t crash; a component of your RTI crashed. Maybe I cringe because I have been working with RTIs for a very long time.
Occasionally we receive a support request asking for the latency of a message in the RTI. Answering these questions is difficult as there are many factors which can affect RTI latency. Not least of these is the network itself and the tick rate of the federate. These are probably the two largest factors in determining latency.
Today I just wanted to provide a status update on our upcoming MAK RTI 4.0 release, and the corresponding VR-Link 4.0 release . These releases will add support for HLA Evolved to each product. As most of you know, HLA Evolved is the latest version of the IEEE 1516 standard which was released this spring.
An HLA Evolved compatible MAK RTI is almost ready for release. As we have been awaiting its release we have received a few requests for more information about HLA Evolved, specifically the work required to update a federate to the latest version of HLA. I was always surprised about this because I have always used VR-Link; our plan is to make VR-Link source compatible, so there will be almost no work required to upgrade a federate using VR-Link.
After you have connected to the RTI and Joined a Federation, your federate will tell the RTI what Classes it will be publishing and subscribing to: these are the HLA Declaration Management Services. For objects, this is done through the RTIAmbassador’s publishObjectClass() and subscribeObjectClassAttributes() respectively. Additionally for Objects you will need to tell the RTI which attributes in the class you will be publishing or interested in. The process is similar for interactions, but with interactions you must subscribe to and publish all attributes.
Just a quick note of good news. IEEE officially released the published IEEE-1516-2010 standard today. You can now order printed copies and download the PDF from www.ieee.org. Keeping with our promise to support IEEE, MAK is pleased to also announce the release of the MAK RTI Version 4.0!
I am frequently asked the question“Should I upgrade my existing HLA Federate to HLA Evolved?” I confess, I cringe when I hear this, mostly because there is no clear answer and usually the inquisitor expects such. Anyone making the decision to upgrade the version of HLA they are using needs to answer a few questions first:
After we completed the recent update to HLA Evolved in the MÄK RTI, we have started overhauling our sockets to support IPv6 for the 4.1 release. One of the new configuration options we added to help everyone with complex network environments is Node Configurable Compression and Bundling.
Specifically, with the current version of the MÄK RTI, you can enable packet-bundling, and or packet-compression throughout the entire exercise. For example, you can do either of the below:
Earlier this week MÄK released the latest version of the RTI, 4.1. One of the big features of this release was support for IPv6. For those that don’t know much about IPv6, it is the latest version of the Internet Protocol and replaces IPv4. The primary motivating factor behind the creation of IPv6 was the size of the IP address space in IPv4. IPv4 addresses are only 32 bits long. That’s enough for 4,294,967,296 different addresses, but it’s not enough for the size of the internet today.
For a number of years, the MÄK RTI has supported a useful feature called FDD (or FED if we’re talking about HLA 1.3) file distribution. The original idea was that often during federation development you might find the need to update your FDD file. This often meant going around to every machine you were using and updating the local copy of the file. Obviously, this is both tedious and error prone. With FDD file distribution, only the federate that created the federation execution needed to have a local copy. When the federation was created, the file was distributed through the RTI to the rtiexec, which then distributed it to every other joining federate. This guaranteed that everyone was using the most up to date file and there were no discrepancies. There was one obvious downside to this feature however: start-up times were slower.
The HLA standard makes no guarantee for how data is marshaled over the network. Under most circumstances there’s no reason for anyone to care how it’s in there as long as you have access to it. However, there is one situation where it does matter. If you need a 64-bit or 32-bit byte aligned value, HLA gives you no option to do that. And if you are casting a pointer to a 64-bit value, you need that byte alignment to access it correctly.
In the past, VR-Link has managed to get around this by simply copying all attributes from the RTI to a new byte aligned memory space to allow said casting. As you might expect, this extra copy takes processing time and will slow down your simulation some amount. Starting with the MÄK RTI 4.3, however, we have decided to force all attributes to be byte aligned to either 32 or 64 bits depending on the size of the attribute. As long as you are using the MÄK RTI, you can ask the RTI for data pointers and cast the data directly to whatever you want it to be, avoiding that copy.
Among the many performance improvements we have done in VR-Link 5.1, it now includes the option to use data pointers. And if you are using the MÄK RTI version 4.3 or better, you don’t have to do anything to turn this feature on - it will detect the right RTI version and reconfigure itself for the faster data access version. If you are using an RTI by a different vendor that includes byte alignment or you have no 64-bit values, we do provide the capability to enable the faster method by enabling ’setGetValueMethod’ in the DtExerciseConnInitializer.
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.
