Local TCP / UDP Tests with the Loop-Back at SARA

• TCP Tests
  • Ethernet Loop-Back
  • Sonet Loop-Back with Web100 / Unmodified Kernel
• UDP Tests
  • Ethernet Loop-Back
  • Sonet Loop-Back with Web100 / Unmodified Kernel
• General Conclusions
• More Result Links:
  • Other results after the Linux Upgrade to V. 2.4
  • UDPmon Large
  • Index of All Results

In this document some results are presented that were obtained with local TCP and UDP measurements at SARA, with a loop-back in various locations at the Cisco 15454. In a number of these tests the performance of the default used Linux&nbp;2.4.16 Web100 kernel has been compared with an unmodified V. 2.4.16 kernel. In these tests hosts gwgsara4 and gwgsara5 have been used that were directly connected with the Cisco 15454. Both hosts were located in the same VLAN.

Multiple stream throughput tests between these two hosts have been performed. Iperf has been used to generate the traffic, because this tool can easily handle multiple streams. The topology and other details of these tests are described in the following sections.

Setup

In these tests the loop-back device has been created at the Gigabit Ethernet interfaces of the Cisco 15454. Due to the short round-trip times a maximum TCP window size of 128 Kbyte has been used. The test time was 60 s.

Results

In the sum of the TCP throughput, taken over all streams, has been presented with a 3D plot as a function of the TCP sum of the window size, also taken over all streams, and as a function of the total #  streams. Source and destination window sizes are chosen identical. In the throughput per stream has been displayed as a function of the TCP window size. In this plot the data for each # streams are represented by a separate trace.

.

Sum throughput in the direction gwgsara4 => gwgsara5 over the Gigabit Ethernet loop-back as a function of the total window size and the # streams.

.

Throughput per stream in the direction gwgsara4 => gwgsara5 over the Gigabit Ethernet loop-back as a function of the window size per stream.

From the and  the following conclusions can be drawn:

• From the sum of the sum of the throughput values () there follows that for # streams > 1 the achieved throughput is independent from the # streams. Probably it will be limited by the host capacity. Please note that before the memory, and Linux kernel upgrade the hosts were not capable to achieve higher throughput values than about 550 Mbit/s.
• Most clearly from there follows that for single stream TCP a remarkable dip in the performance at a window size of about 44 Kbyte. After this dip the single stream throughput never reaches high values again.

Setup

For these tests the loop-back device has been created at the Sonet interface of the Cisco 15454. The tests were executed both with a Web100 V. 2.4.16 kernel and an unmodified V. 2.4.16 kernel. Again a maximum TCP window size of 128 Kbyte had been used, and the test duration had been set to 60 s.

Results

In the following 3D figures the sum of the throughputs has been given as a function of the sum of the TCP window size and of the # streams. In these results are presented in the direction gwgsara4 => gwgsara5 with the Web100 kernel and in for the reverse direction with the same kernel. In the and  the data for the same directions as in the previous figures are displayed, but here an unmodified kernel has been used.

.

Sum throughput in the direction gwgsara4 => gwgsara5 over the Sonet loop-back for a Web100 kernel as a function of the total window size and the # streams.

.

Sum throughput in the direction gwgsara5 => gwgsara4 over the Sonet loop-back for a Web100 kernel as a function of the total window size and the # streams.

.

Sum throughput in the direction gwgsara4 => gwgsara5 over the Sonet loop-back for an unmodified kernel as a function of the total window size and the # streams.

.

Sum throughput in the direction gwgsara5 => gwgsara4 over the Sonet loop-back for an unmodified kernel as a function of the total window size and the # streams.

In the throughput per stream has been given as a function of the TCP window size for the direction gwgsara4 => gwgsara5, using a Web100 kernel, while in the throughput per stream has been shown for the reverse direction. In these plots are the data for each # streams represented by a separate trace. The and  are displaying the equivalent data as in the previous two figures, using an unmodified kernel.

.

Throughput per stream in the direction gwgsara4 => gwgsara5 over the Sonet loop-back for a Web100 kernel as a function of the window size per stream.

.

Throughput per stream in the direction gwgsara5 => gwgsara4 over the Sonet loop-back for a Web100 kernel as a function of the window size per stream.

.

Throughput per stream in the direction gwgsara4 => gwgsara5 over the Sonet loop-back for an unmodified kernel as a function of the window size per stream.

.

Throughput per stream in the direction gwgsara5 => gwgsara4 over the Sonet loop-back for an unmodified kernel as a function of the window size per stream.

Conclusions

The following can be concluded from the , ..., :

• Equivalent behaviour as has been described in the "Conclusions" subsection from the "Ethernet Loop-Back" section could be found here.
• There are no performance differences between the Web100 and the unmodified kernel.
• There are also no performance differences between the two test directions.

Multiple stream UDP bandwidth tests between the two test hosts gwgsara4 and gwgsara5 are presented here. Also here Iperf has been used to generate the traffic because 1) it is well capable of handling UDP traffic and 2) this tool can easily handle multiple streams. The topology of these tests are the same as described in the "TCP Tests" section. It and the other test information are described in the following sections.

Setup

Below follows the description of the UDP tests were the loop-back was located at the Gigabit interfaces. Also here the default Web100 kernel had been used. The maximum bandwidth send was 800 Mbit/s. The duration of each test was 60 s.

Results

shows the percentage total packets lost as a function of the total bandwidth that has been send. The data for each # streams are represented in this plot by a separate trace.

.

Total packets lost in the direction gwgsara4 => gwgsara5 over the Gigabit Ethernet loop-back as a function of the sum of the bandwidths send.

From the following conclusions can be drawn:

• No more than about 600 Mbit/s could be send. Host effects are probably responsible for that.
• No packet lost did occur for the tests with 1, 2, 3 streams.

Setup

For these tests the loop-back device has been created at the Sonet interface of the Cisco 15454. The tests were executed both with a Web100 and an unmodified V. 2.4.16 kernel. Again the maximum bandwidth send was 800 Mbit/s and the test length was 60 s.

Results

In the following figures the percentage total packets lost has been given as a function of the total bandwidth. The data for each # streams are represented in these figures by a separate plot trace. In these results are presented in the direction gwgsara4 =&ft; gwgsara5 with the Web100 kernel and in for the reverse direction with the same kernel. In the and  the data for the same direction as in the previous figures has been displayed, but here an unmodified kernel has been used.

.

Total packets lost in the direction gwgsara4 => gwgsara5 over the Sonet loop-back for a Web100 kernel as a function of the sum of the bandwidths send.

.

Total packets lost in the direction gwgsara5 => gwgsara4 over the Sonet loop-back for a Web100 kernel as a function of the sum of the bandwidths send.

.

Total packets lost in the direction gwgsara4 => gwgsara5 over the Sonet loop-back for an unmodified kernel as a function of the sum of the bandwidths send.

.

Total packets lost in the direction gwgsara5 => gwgsara4 over the Sonet loop-back for an unmodified kernel as a function of the sum of the bandwidths send.

Conclusions

The following can be concluded from the , ..., :

• The same characteristics that have been found in the "Conclusions" subsection from the "Ethernet Loop-Back" section could be found here.
• As in the TCP tests no differences could be found between the tests in the direction gwgsara4 => gwgsara5 and the tests in the reverse direction.

From the TCP and UDP test results presented here, the following general conclusions can be given:

• No differences between the Web100 kernel and the unmodified kernel could be found.
• The single stream TCP congestion problems are not detected with UDP traffic type: UDP traffic seems to behave quite normal.
• No directional dependent effects could be found.

---

Other results after the Linux Upgrade to V. 2.4