SOURCEFORGE » RALF » 2014 ACM testing using channel emulation

h1. Results

In this section we present and analyze some results as well as some conclusions.

h2. Link Emulation

In order to test performance of ACM and compare it to a CCM, we generated a file containing a time series of Es/N0 values. These ranged from 25dB to 2dB and formed both a descending and ascending phase. This means that the link's Es/N0 value starts descending from 25dB down to 2dB and ascending back to 25dB afterwards. This was done in 0.5dB increments which last 10 seconds each. 

Performing this with the link emulator is quite easy since there is a software variant that allows for importing of time series. This is explained in the [[Link Emulation]] section. Since the ACM client (station) reports Es/N0 estimates to the ACM controller (HUB), we went ahead and compared both the emulation input as well as the reported values:

p=. !{width: 70%}1.png(.)!

Both overlap quite nicely although there seems to be some underestimation specially around 15dB. There also some spurious values which can lead to modcod parameters being changed quite rapidly.

tip. In order to reduce spurious modcod changes, it may be of interest to refer to fade prediction values in the ACM client configuration. These options, however, are not explained in the EL470 user manual.

We can also take a look at the modcod parameters:

notice. In the lab setup, maximum achievable modcod is 16APSK 8/9 while the minimum is QPSK 1/4.

p=. !{width: 70%}3.png(.)!

This is an interesting graph because it shows that in the event of degradations in link conditions, ACM responds by adjusting modulation and coding to best match performance. As we will see further on, in the case of CCM there is an outage and nothing can really be done until link conditions get better. 

h2. UDP traffic

As stated in [[Measuring Tools and Scripts]] Iperf generated traffic will only be UDP since at this point we are only interested in an estimate of available channel capacity. Due to their inherent delay in transmitting messages, satellite links have very adverse effects on the way certain transport protocols such as TCP behave. This leads to low channel utilization and thus it is not useful as traffic when we want to measure channel capacity.  For more information on satellite links and its effects on TCP refer to "RFC2488: Enhancing TCP Over Satellite Channels using Standard Mechanisms":http://tools.ietf.org/html/rfc2488.

Now the question is what UDP datagram size to use and what target bandwidth at which the HUB will generate traffic. Since the modems are configured with a symbol rate of 512 kbauds and the maximum achievable modulation scheme is 16APSK, an upper bound on achievable throughput is 512k x log ~2~ 16 = 2.048 Mbps. This is clearly the bottleneck since Ethernet communication between PCs and modem interfaces highly exceed this capacity. We tested this by generating traffic at 3Mbps with a UDP length of 8KB. However, results were not looking good:

p=. !{width: 70%}0.png(.)!

The previous graph shows UDP throughput and the bitrate reported by the HUB modulator. Why weren't we getting a constant throughput? The answer is quite simple, generated UDP packets will be bigger than the link MTU and thus they will be fragmented in order to be sent. Since we are transmitting at a higher rate than the satellite link can handle, we will see losses in IP packets and throughput in the UDP layer will not be representative of channel capacity since the lower layer may discard packets for which fragments have not arrived. 

To fix this, we resorted to generating UDP datagrams with a length of 1300B, this way we are under the MTU. We then proceeded run tests with ACM enabled. The first test will see modcod parameters vary according to the current Es/N0 as we saw previously. In addition to this test run, we also limited ACM to only one modulation and coding scheme effectively emulating CCM operation. 

notice. Running in ACM mode is mandatory since we need the ACM controller log values. However, CCM can be emulated by setting minimum and maximum modcod to the same value in the ACM controller configuration.

For CCM, 16APSK 3/4, 8PSK 3/4 and QPSK 3/4 were chosen. In the following graph we can see UDP throughput for all 4 tests. Note that CCM test runs only contain the descending portion of the time series, this is because after a certain value of Es/N0 throughput drops to zero.

p=. !{width: 70%}2.png(.)!

If we now take a look at the modcod parameter as a function of Es/N0, we can see that for ACM there is a hysteresis phenomenon, this is expected since [[FlexACM]] uses different margins depending if Es/N0 is increasing or decreasing. 

p=. !{width: 70%}4.png(.)!

Another interesting plot which illustrates the concept of ACM quite nicely is the following graph:

p=. !{width: 70%}5.png(.)!

We can see that the application throughput is dynamically set and 

h1. Conclusions