Level(3) Lambda UDPmon Large Monitor Results

• Description
• Tests SARA & EVL
  • Host gwgsara5 Directly Connected to the ONS
• Other Result Links:
  • v Level(3) Lambda UDPmon Large (4 * STS 12C)
  • v Level(3) Lambda UDPmon Large with STS Tuning
  • Teleglobe Lambda UDPmon Large Results
  • Teleglobe Lambda TCP / UDP Measurements
  • Index of All Lambda Results

In this document UDP experiments are described that were performed with a modified version of the UDPmon package written by R.E. Hughes-Jones in the sense that from 5000 packets the sequence number and the arrival time in microsec. are specified. The experiments were executed at the Level(3) Lambda before acceptance by SURFnet. All tests were performed after the hosts upgrade of the SARA cluster to 515 Mbyte memory and Linux V.2.4.16-web100.

An overview and description of the tests at the preceding Teleglobe Lambda can be found in this document. During those tests the Lambda, the hosts hardware and OS were in various upgrade states.

The tests, described in the following subsections, were executed. The wait time between two packets, send by UDPmon, was always zero sec. The from this package obtained bandwidth are always calculated from the sequence number and the relative receiving time from the last packet that arrived without lost at the receiving host.

In this section the results between test hosts located at SARA and EVL are described. The SARA hosts were running Linux 2.2.15, and the EVL hosts Linux 2.4.2.

Setup

The scheme for this tests was:

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

   SARA                        Chicago

Using this scheme tests were performed with the following streams to be able to notice the differences between the induced paths:

Results

In these tests the receiving time difference with the first packet has been plotted as a function of the package sequence number for packet sizes of 500, 1000, 1200 and 1460 bytes. In the these data are shown for the stream prusin => gwgsara2, in the for the stream prusin => gwgsara5, and in the these data are presented for the stream gwgsara2 => gwgsara5 shows for these streams as function of the packet size: 1) the bandwidth (B) calculated with , from the sequence number at the last received packet without lost (variable Last_Recv_Seq_Nr) and from the packet size in bytes, 2) the sequence number of that last received packet without lost, and 3) the # packets lost.

B  =  (Last_Recv_Seq_Nr * Packet_Size * 8)  /  Rel_Time

.I.

The relative receiving time as function of the packet sequence number for the UDP stream prusin => gwgsara2 using the SSR 8000 and the LSD 6509. The packet size was 500 bytes.

.II.

The relative receiving time as function of the packet sequence number for the UDP stream prusin => gwgsara2 using the SSR 8000 and the LSD 6509. The packet size was 1000 bytes.

.III.

The relative receiving time as function of the packet sequence number for the UDP stream prusin => gwgsara2 using the SSR 8000 and the LSD 6509. The packet size was 1200 bytes.

.IV.

The relative receiving time as function of the packet sequence number for the UDP stream prusin => gwgsara2 using the SSR 8000 and the LSD 6509. The packet size was 1460 bytes.

.I.

The relative receiving time as function of the packet sequence number for the UDP stream prusin => gwgsara5 using only the LSD 6509. The packet size was 500 bytes.

.II.

The relative receiving time as function of the packet sequence number for the UDP stream prusin => gwgsara5 using only the LSD 6509. The packet size was 1000 bytes.

.III.

The relative receiving time as function of the packet sequence number for the UDP stream prusin => gwgsara5 using only the LSD 6509. The packet size was 1200 bytes.

.IV.

The relative receiving time as function of the packet sequence number for the UDP stream prusin => gwgsara5 using only the LSD 6509. The packet size was 1460 bytes.

.I.

The relative receiving time as function of the packet sequence number for the UDP stream gwgsara2 => gwgsara5 using the SSR 8000 and the loop-back at the LSD 6509. The packet size was 500 bytes.

.II.

The relative receiving time as function of the packet sequence number for the UDP stream gwgsara2 => gwgsara5 using the SSR 8000 and the loop-back at the LSD 6509. The packet size was 1000 bytes.

.III.

The relative receiving time as function of the packet sequence number for the UDP stream gwgsara2 => gwgsara5 using the SSR 8000 and the loop-back at the LSD 6509. The packet size was 1200 bytes.

.IV.

The relative receiving time as function of the packet sequence number for the UDP stream gwgsara2 => gwgsara5 using the SSR 8000 and the loop-back at the LSD 6509. The packet size was 1460 bytes.

In these tests the UDPmon tool has been run for a large number of packet sizes, while the other parameters were unchanged. In the plots, shown below, the following parameters are presented as a function of the packet size:

• displays the bandwidth, calculated with  from the sequence number at the last received packet without lost. The bandwidth is only calculated when at least 200 packets were received without lost.
• presents the sequence number from the last packet that has been received without any lost.
• gives the bandwidth calculated from the received packets in the region were packet lost did occur. The bandwidth is only calculated when at least 200 packets have been received in this region.
• gives the # packets lost.

.I.

The bandwidth from the region without packet lost as function of the packet size for the streams presented by the plot traces.

.II.

The Sequence Number from the last packet without loss as function of the packet size for the streams presented by the plot traces.

.III.

The bandwidth in the region with packet loss as function of the packet size for the streams presented by the plot traces.

.IV.

The # packets lost as function of the packet size for the streams presented by the plot traces.

Conclusions

From these results the following conclusions can be drawn:

• The time-sequence plots can be compared with corresponding results at the Teleglobe Lambda described in the described in the "UDPmon Monitor Results for Large Configuration" and the "More SARA & EVL UDPmon Large Results and SNMP". It appears that the packets lost at the Level(3) Lambda are considerably less than with the Teleglobe Lambda, although it looked like that some bandwidths at the previous Teleglobe Lambda were higher, which may also result in higher percentages packets lost, due to host effects. There also should be realised that the SARA during the tests at the Teleglobe Lambda were still equipped with 128 MB memory and Linux V. 2.2.15 kernels. That also makes the comparison less reliable.
• In the plot of the no loss bandwidth as function of the packet size () it appears that the bandwidth values for the smaller packet sizes are linearly increasing as function of the packet size, reflecting that network properties are dominant in this region. Hereafter host effects become dominant reflecting in the highest bandwidths in the streams between SARA hosts, a lower bandwidth for the streams from EVL hosts to SARA hosts and the lowest bandwidth in the reverse direction. This is completely in agreement with the better performance of the SARA hosts compared with the EVL hosts.
• For higher packet sizes the larges # packets lost are found for streams from SARA hosts to EVL, also reflecting the lower performances of the latter hosts.
• The bandwidth values in the packet loss region () are comparable with the bandwidths in the region without loss. This may be an indication that the losses are not caused by bottlenecks in the network.
• When the results of the streams from / to gwgsara5 are compared with those from / to gwgsara2 no large influences of the SSR 8000 could be observed. That is especially true for the larger packet size.