UDPmon Monitor Results for Large Configuration

• General Description
• Tests SARA & EVL
  • Host gwgsara4 Directly Connected to the ONS
  • Hardware Loop
  • Back-to-Back
  • Tests with ONS and 6509 Only, Using also SNMP Counters
  • Hardware Loop and SNMP Counter
  • More Results and SNMP
• Tests NIKHEF with Jumbo Frames
• Tests Level(3) Lambda
• Other Result Links:
  • SURFnet5 UDPmon Results and SNMP
  • Compact Presentations UDPmon Lambda Performance
  • Lambda TCP / UDP Measurements
  • Index of All Lambda Results

UDP Experiments 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 following parameters were used, unless otherwise stated:

From the UDPmon package obtained bandwidths are always calculated from the sequence number and the relative receiving time from the last packet that arrived without lost at the receiving host.

The results described here are obtained after the ONS update.

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.

Host gwgsara4 Directly Connected to the ONS

The scheme for this tests was:

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

   SARA                                     EVL

The following tests with the streams listed in the subsection below were executed.

prusin => gwgsara2

The results are displayed in , where the relative receiving times in microsec. are plotted as function of the packet sequence number. From this plot it is clear that no packets were lost. From the time difference between first and last packet it follows that the corresponding bandwidth is about 573 Mbit/s.

.

The relative receiving time as function of the packet sequence number for the UDP stream prusin => gwgsara2.

gwgsara2 => prusin

The results from this tests are displayed in .

.

The relative receiving time as function of the packet sequence number for the UDP stream gwgsara2 => prusin.

In , package lost is encountered with the following pattern:

So the package lost pattern is almost periodic. The bandwidth is 497 Mbit/s.

There can be expected that increasing the inter-packet wait time will minimise the packages lost. The situation with 12 micros inter-packet wait time has been displayed in .

.

The relative receiving time as function of the packet sequence number for the UDP stream gwgsara2 => prusin with an inter-packet wait time of 12 microsec.

In the following pattern has been found:

Compared with the non-waiting situation the package lost frequency is lower and the # packages lost per interval is smaller. The bandwidth is 507 Mbit/s.

At a test with 15 microsec.. wait time no package lost had been found. The corresponding bandwidth is here 501 Mbit/s. See .

.

The relative receiving time as function of the packet sequence number for the UDP stream gwgsara2 => prusin with an inter-packet wait time of 15 microsec.

Note that at all these tests the bandwidth is not limited by the wait time, so there are external factors limiting the wait time. Presumably the prusin host is not capable of receiving the packets, may be because it is slower than gwgsara2 (650 MHz compared with 800 MHz). Also the used Gigabit Ethernet cards may play a role.

The path for this stream is gwgsara2 => SSR => ONS => ONS => 6509 => ONS => ONS => gwgsara4. The results from this tests are displayed in .

.

The relative receiving time as function of the packet sequence number for the UDP stream gwgsara2 => gwgsara4.

The path used at this test in gwgsara2 => SSR => gwgsara3. The results are available in .

.

The relative receiving time as function of the packet sequence number for the UDP stream gwgsara2 => gwgsara3.

The bandwidth is 581 Mbit/s, comparable with the results from the stream gwgsara2 => gwgsara4, calculated for seq. #2572. Comparison with the stream gwgsara2 => gwgsara4 probably leads to the conclusion that in both situations the receiving host is responsible for the package lost.

gwgsara4 => gwgsara5

For this test the following scheme has been used:

		   +-+
  		   | |
+--------+	   | |
|gwgsara4|---------|O|        +-+
+--------+	   | |        |O|
		   |N|- .... -|N|-+
		   | |- .... -|S| | hardware loop
		   |S|        | |-+
+--------+	   | |        +-+
|gwgsara5|---------| |
+--------+         +-+

   SARA

So in this test gwgsara4 and wgwsara5 are connected by a hardware loop. The SSR and 6509 are not in the path. The results are displayed in .

.

The relative receiving time as funtion of the packet sequence number for the UDP stream gwgsara4 => gwgsara5 using the hardware loop.

The results have the same form as for the streams gwgsara2 => gwgsara4 and gwgsara2 => gwgsara3, indicating again that receiving host effects are the dominant factor. The bandwidth is 582 Mbit/s for seq. #1900.

gwgsara4 => gwgsara5

For these tests gwgsara4 and gwgsara5 were connected back-to-back. Tests with packet sizes of 1000 bytes (figure .I) and 1460 bytes (figure .II) were performed. No packets lost were found in these figures. The bandwidths were: 581 Mbit/s (packet size 1000 bytes) and 834 Mbit/s (1460), both calculated for seq. #4999.

.I.

The relative receiving time as funtion of the packet sequence number for the UDP stream gwgsara4 => gwgsara5 connected back-to-back. The packet size was 1000 bytes.

.II.

The relative receiving time as funtion of the packet sequence number for the UDP stream gwgsara4 => gwgsara5 connected back-to-back. The packet size was 1460 bytes.

For this configurations also a TCP throughput test with Netperf has been executed with 512 Kbyte socket and buffer sizes. The output is:

wgsara4> netperf -H gwgsara5 -l 20 -- -m 512K -M 512K -s 512K -S 512K
TCP STREAM TEST to gwgsara5
Recv   Send    Send                          
Socket Socket  Message  Elapsed              
Size   Size    Size     Time     Throughput  
bytes  bytes   bytes    secs.    10^6bits/sec  

1048576 1048576 524288    20.01     522.76

For these tests the following configuration has been used.

		   +-+
+--------+         | |
|gwgsara2|---------|O|        +-+   +-+
+--------+         | |        |O|   |6|
		   |N|- .... -|N|---|5|
		   | |- .... -|S|   |0|
		   |S|        | |   |9|
+--------+	   | |        +-+   +-+
|gwgsara4|---------| |
+--------+         +-+

So the stream is now defined by gwgsara2 => ONS => ONS => 6509 => ONS => gwgsara4. The tests were defined as function of the packet size. Also the ingoing and outgoing SNMP counters at the both ONS's were registered just before and after the UDPmon tests. Combination of the appropriate ingoing and outgoing counters makes it possible to detect package lost at:

1. The Lambda connection Amsterdam => Chicago and both ONS's.
2. The 6509 in Chicago.
3. The Lambda connection Chicago => Amsterdam and both ONS's.

The streams specified in the following subsections were tested.

gwgsara2 => gwgsara4

The results for this stream, using packet sizes of 500, 1000, 1200, and 1460 bytes are displayed in figures .I, ..., .IV.

.I.

The relative receiving time as funtion of the packet sequence number for the UDP stream gwgsara2 => gwgsara4 using the ONS's and the 6509. The packet size was 500 bytes.

.II.

The relative receiving time as funtion of the packet sequence number for the UDP stream gwgsara2 => gwgsara4 using the ONS's and the 6509. The packet size was 1000 bytes.

.III.

The relative receiving time as funtion of the packet sequence number for the UDP stream gwgsara2 => gwgsara4 using the ONS's and the 6509. The packet size was 1200 bytes.

.IV.

The relative receiving time as funtion of the packet sequence number for the UDP stream gwgsara2 => gwgsara4 using the ONS's and the 6509. The packet size was 1460 bytes.

The SNMP counters did not indicate any package lost for this stream registered at the SNMP locations described above.

gwgsara4 => gwgsara2

The results for this stream, using packet sizes of 500, 1000, 1200, and 1460 bytes are displayed in figures .I, ..., .IV.

.I.

The relative receiving time as funtion of the packet sequence number for the UDP stream gwgsara4 => gwgsara2 using the ONS's and the 6509. The packet size was 500 bytes.

.II.

The relative receiving time as funtion of the packet sequence number for the UDP stream gwgsara4 => gwgsara2 using the ONS's and the 6509. The packet size was 1000 bytes.

.III.

The relative receiving time as funtion of the packet sequence number for the UDP stream gwgsara4 => gwgsara2 using the ONS's and the 6509. The packet size was 1200 bytes.

.IV.

The relative receiving time as funtion of the packet sequence number for the UDP stream gwgsara4 => gwgsara2 using the ONS's and the 6509. The packet size was 1460 bytes.

The SNMP counters did not indicate any package lost for this stream registered at the SNMP locations described above.

The fact that no SNMP package lost have been found at the network equipment for the streams gwgsara2 <=> gwgsara4 is also an indication that the observed host package lost may be caused by the receiver.

In these tests the configuration from section "Hardware Loop" have been used. The tests were performed as function of the packet sizes. Also the incoming and outgoing octet counters at the Amsterdam ONS were registered to check for packets lost.

The streams specified in the following subsections were tested.

The results for this stream, using packet sizes of 500, 1000, 1200, and 1460 bytes are displayed in figures .I, ..., .IV.

.I.

The relative receiving time as funtion of the packet sequence number for the UDP stream gwgsara4 => gwgsara5 using the loop-back interface. The packet size was 500 bytes.

.II.

The relative receiving time as funtion of the packet sequence number for the UDP stream gwgsara4 => gwgsara5 using the loop-back interface. The packet size was 1000 bytes.

.III.

The relative receiving time as funtion of the packet sequence number for the UDP stream gwgsara4 => gwgsara5 using the loop-back interface. The packet size was 1200 bytes.

.IV.

The relative receiving time as funtion of the packet sequence number for the UDP stream gwgsara4 => gwgsara5 using the loop-back interface. The packet size was 1460 bytes.

The SNMP counters did not indicate any package lost for this stream.

The results for this stream, using packet sizes of 500, 1000, 1200, and 1460 bytes are displayed in figures .I, ..., .IV.

.I.

The relative receiving time as funtion of the packet sequence number for the UDP stream gwgsara5 => gwgsara4 using the loop-back interface. The packet size was 500 bytes.

.II.

The relative receiving time as funtion of the packet sequence number for the UDP stream gwgsara5 => gwgsara4 using the loop-back interface. The packet size was 1000 bytes.

.III.

The relative receiving time as funtion of the packet sequence number for the UDP stream gwgsara5 => gwgsara4 using the loop-back interface. The packet size was 1200 bytes.

.IV.

The relative receiving time as funtion of the packet sequence number for the UDP stream gwgsara5 => gwgsara4 using the loop-back interface. The packet size was 1460 bytes.

The SNMP counters did not indicate any package lost for this stream.

The results for stream gwgsara4 => gwgsara5 seems to be better than for stream gwgsara5 => gwgsara4. An explanation might be that gwgsara4 is slower than gwgsara5 (860 MHz compared to 1000 MHz).

As in subsection "Tests with hardware loop" again the hadware loop has been used. However, for these tests NIKHEF hosts have been used, running Linux 2.4 with an MTU of 9000 bytes. The scheme for this test was, comparable with the section referred above:

		   +-+
  		   | |
+--------+	   | |
|keeshond|---------|O|        +-+
+--------+	   | |        |O|
		   |N|- .... -|N|-+
		   | |- .... -|S| | hardware loop
		   |S|        | |-+
+--------+	   | |        +-+
|  haan  |---------| |
+--------+         +-+

  NIKHEF

In the effective bandwidth has been displayed as function of the packet size for the UDP stream keeshond => haan. In these results are displayed for the reverse direction.

.

The effective bandwidth as funtcion of the packet size for the UDP stream keeshond => haan using the loop-back interface with an MTU of 9000 bytes

.

The effective bandwidth as function of the packet size for the UDP stream haan => keeshond using the loop-back interface with an MTU of 9000 bytes.

For these streams also the # packets lost has been given, again as function of the packet size. In these data are displayed for the stream keeshond => haan and in for the reverse direction.

.

The # packets lost as function of the packet size for the UDP stream keeshond => haan using the loop-back interface with an MTU of 9000 bytes.

.

The # packets lost as function of the packet size for the UDP stream haan => keeshond using the loop-back interface with an MTU of 9000 bytes.

From these figures there follows that larger packet sizes are leading to higher effective bandwidths and fewer # packets lost, indicating that the # packets send are the limiting factors. Presumambly these are hosts effects.