Level(3) Lambda TCP / UDP Measurements Before Acceptance

• TCP Tests
  • Host gwgsara5 Directly Connected to the ONS
• UDP Tests
  • Host gwgsara5 Directly Connected to the ONS
• Other Result Links:
  • Results After Acceptance  (under construction)
  • Index of All Lambda Results

In this document the results from TCP and UDP measurements are described that were performed at the Lambda between SURFnet, Amsterdam, and StarLight, Chicago, provided by Level(3). The results are displayed from the period where the Lambda had not yet been accepted by SURFnet. All tests were performed after the hosts upgrade of the SARA cluster to 512 Mbyte memory and Linux V.2.4.16-web100.

In these tests host gwgsara5 has been connected directly to the Cisco ONS, according to the scheme from . During these tests host reynolds was not available at EVL, unfortunately.

+--------+   +-+
|gwgsara2|---|S|
+--------+   | |   +-+        +-+
             |S|---| |        | |   +-+
+--------+   | |   |O|        |O|   |6|
|gwgsara3|---|R|   | |- .... -| |   |5|   +------+
+--------+   +-+   |N|        |N|---|0|---|prusin|
                   | |- .... -| |   |9|   +------+
+--------+         |S|        |S|   | |
|gwgsara5|---------| |        | |   +-+
+--------+         +-+        +-+

   SARA                                      EVL

TCP throughput tests were performed between host prusin located at EVL and host gwgsara5 at SARA. At each host one to eight streams were started to the equivalent host at the other location. During these tests the sum of the TCP window sizes over the streams was maximal 8 Mbyte. The duration of each test was 60 s. The TCP streams were generated using Iperf V. 1.2.1, because this tool can easily handle multiple streams.

These tests were obtained after a Level(3) maintenance period. At the UDP tests, also results before this maintenance period were available, hence it has been explicitly mentioned here.

Results

In the following figures the sum of the TCP throughput values, taken over all streams, has been presented as a function of the sum of the TCP window sizes, also taken over the streams, and as a function of the total # streams. In these data are displayed for the stream gwgsara5 => prusin and in for the reverse direction.

.

Sum throughput gwgsara5 => prusin as a function of the total window size and the # streams.

.

Sum throughput prusin => gwgsara5 as a function of the total window size and the # streams.

In the average throughput per stream has been given as a function of the TCP window size per stream in the direction gwgsara5 => prusin. Each # streams is represented in this plot by a trace. displays these results for the reverse direction.

.

Throughput per stream in the direction gwgsara5 => prusin as a function of the window size per stream.

.

Throughput per stream in the direction prusin => gwgsara5 as a function of the window size per stream.

Conclusions

The results presented in can be compared with corresponding results at the Lambda provided by Teleglobe and where the SARA hosts have the same configuration as in the current tests. These results can be found in the "Lambda TCP Tests after Host Upgrade to Linux 2.4" in the figures 1, 2, 5, and 6.

When both results are compared there follows that from a TCP performance point of view the both Lambda's are comparable.

In this section the results from some UDP tests are described that were executed just before and after a Level(3) maintenance period.

Setup

In these UDP tests the topology scheme from has been used that has been described in the corresponding "Setup" subsection. Again due to the unavailability of reynolds at EVL, only single host pair UDP tests were performed with the following parameters. The maximum bandwidth was 800 Mbit/s, the used # streams varies from one to eight, and the test duration was 60 s.

Results

In this sub section the results from some UDP tests are described that were executed just before Level(3) maintenance.

In the figures presented below the total packets lost has been shown as a function of the total bandwidth that has been send. The data for each # streams in these plots are represented by a separate trace. displays these data for the direction gwgsara2 => prusin and for the reverse direction. There are here also data available for the complete route Amsterdam - Chicago - Amsterdam, using hosts gwgsara2 and gwgsara5; see also the scheme from . The data for the direction gwgsara2 => gwgsara5 are presented in and in they are presented for the other direction.

.

Total packets lost in the direction gwgsara2 => prusin, according to the scheme in , as a function of the sum of the bandwidth send.

.

Total packets lost in the direction prusin => gwgsara2, according to the scheme in , as a function of the sum of the bandwidth send.

.

Total packets lost in the direction gwgsara2 => gwgsara5, according to the scheme in , as a function of the sum of the bandwidth send.

.

Total packets lost in the direction gwgsara5 => gwgsara2, according to the scheme in , as a function of the sum of the bandwidth send.

In this sub section equivalent results are presented as in the "Before Maintenance", but here the results are obtained just after Level(3) maintenance.

Again the total packets lost has been shown as a function of the total bandwidth that has been send. A separate trace presents the data for a particular # streams. shows these data for a single host pair in the direction gwgsara5 => prusin and in for the reverse direction.

Also UDP data, using two host streams are available. Using the scheme from it is possible to use one route between and Amsterdam and Chicago by using a SARA host and an EVL host, while a route Amsterdam - Chicago - Amsterdam can be created by using host gwgsara5 and one of the hosts connected with the SSR. Therefore, shows the total packets lost as a function of the total bandwidth send along these routes for the streams gwgsara2 => prusin and gwgsara3 => gwgsara55. , shows these data for the streams in the reverse directions.

.

Total packets lost in the direction gwgsara5 => prusin, according to the scheme in , as a function of the sum of the bandwidth send.

.

Total packets lost in the direction prusin => gwgsara5, according to the scheme in , as a function of the sum of the bandwidth send.

.

Total packets lost for the streams gwgsara2 => prusin and gwgsara3 => gwgsara5 according to the scheme in , as a function of the sum of the bandwidth send.

.

Total packets lost for the streams prusin => gwgsara2 and gwgsara5 => gwgsara3 according to the scheme in , as a function of the sum of the bandwidth send.

Conclusions

Single Host Pair

Unfortunately for single host pair UDP there is no good material available to compare with older results. Also the situation before and after the maintenance are not completely the same according to the scheme from . Still the following conclusions can be drawn from these tests:

• The percentage # packets lost in the tests between SARA and EVL after the maintenance ( ) is larger than in the period before the maintenance ( ). Also the spreading in the results after maintenance is larger. That is remarkable, because in the results after maintenance the SSR is not involved, so better results might be expected.
• The less good results in the direction gwgsara2 => prusin () compared with the results can be explained by the lower performance of prusin compared with the other hosts.
• In the direction prusin => gwgsara2 () up to five streams can be send (almost) without packets lost, and in the directions gwgsara2 <=> gwgsara5 ( ) four streams. This may lead to the conclusion that the connection over the longer route Amsterdam - Chicago - Amsterdam performs slightly worse. However, this effect could also be subscribed to the performance difference between prusin and gwgsara2.
• With the exception of the direction gwgsara5 => prusin, the maximum received bandwidth is in all cases about 550 Mbit/s. This probably has been caused by host limitations.

Two Host Pairs

Also for two host pairs ( ) no good comparison material with older results has been available, but still the following conclusions can be drawn:

• There is not much differences in the percentage packets lost for the tests in the directions to and from host prusin, this in contradiction with the single host pair tests. The reason is that hosts gwgsara2 and gwgsara3 are situated in the same VLAN. Therefore, the packets to the prusin are much better spread as with the single host pair situation.
• The maximum bandwidth that could be obtained without packets lost is about 900 Mbit/s for both directions for single streams per host pair. The limiting factor in that value is probably the SSR.