Benchmarking the RTI is a bit like trying to measure how much water there is in the ocean at any given instant in time. You know that there really is a finite amount, but actually measuring it is hard, because there are so many variable factors that affect the result.

First, let's get some radio basics out of the way.

Quick note: It should be noted that, in this discussion, "model" refers to a model that includes multiple operators with control assets and other audio elements, as opposed to an academic "radio model", with no relationship to a real-life use of the system. "Active streams" refers to streams either transmitted or actively being received by the system. There may be many more streams on the network which are being rejected (maybe due to frequency mismatch, radio range conditions, crypto mismatch, etc.). Such streams may number into the hundreds, but are not included in the "active streams" count.

Our normal radio operational modes use mu-law audio compression, resulting in audio data being produced at approximately 100kbs. This results in basic telephone-quality audio. Since this compression is handled in the hardware, there is no DSP load associated with this technique. A DACS with a single DSP card can typically (* see note 1) handle around 48 active radios/voice streams in a networked situation.

One option for radio operation is to use CVSD voice compression to reduce the network bandwidth required to transfer a particular signal. The disadvantage of CVSD is two-fold: 1) the voice quality is somewhat degraded, and 2) the algorithm now uses DSP processing.

The network bandwidth required for a CVSD audio stream drops to 25kbs. However, a DACS with a single DSP card can now typically (* see note 1) support around 24 active radios (tx).

The above limits have nothing to do with HLA or anything other than basic DSP processing limits of the hardware base.

Now let's examine HLA.

The problem that HLA introduces is that, not only are we attempting to pass audio data around a network, but now we have added some overhead processing to the process. Each time a piece of HLA data is sent, we are required to interact with the RTI code; we are adding additional processing. The RTI is not optimized to necessarily handle real-time streaming data (as audio is by nature). Rather, it is better suited to handling 'event'-based data.

Back in the early days of HLA, ASTi performed some rigorous tests to look at RTI loading limits, andÑconsequentlyÑaudio stream capability. These tests revealed that the limit for clean audio reception was 16 audio streams. Above this number, we found that we began to suffer effects such as packets-received-out-of-order, dropped packets, and so on, resulting in audio break-up. This work was a 'snapshot in time' of the performance of the RTI and ASTi systems.

At this point, we now introduce our "amount of water in the ocean" analogy. The exact number of audio streams will be affected by: 1) the performance of the processors both running the RTI, 2) the processors used in the ASTi Telestra computing elements, and 3) any possible networking infrastructure between these devices.

We must also factor in any RTI code developments. Some developments may have improved the performance, whilst others may have detracted from it. Since RTI releases are quite often, as are changes to elements of the hardware, we could spend all our time benchmarking RTI/ASTi system performance. However, we feel that this is not worthwhile, since as soon as we complete the task, we would be starting again.

The end point for this discussion is that we use the number of 16 HLA audio streams on a network as a typical (yeah!, see Note 1!) *minimum* number. It is certainly NOT surprising to us that you may, in practice, find higher numbers.

To clarify, when you exceed the RTI capacity to process audio interactions, the kind of effects you may see will include broken-up audio, delayed audio, and similar distortions, up to the point where you receive no audio at all. Of course, if you are suffering anything like this, you should be talking to us at ASTi since we have a number of tricks that can help with such problems. That discussion belongs in another FAQ in its own right.

Note 1: The use of the word 'typically' is intended to act as a guidance value - there are many factors that affect the exact number.