SL - ASP Itanium Tests -- TCP Tests

TCP Tests

Description

As mentioned before, these tests have been executed to get an expression about the network performance of both Itanium hosts and their connecting network. Again the Iperf V. 1.6.5 traffic generator has been used to generate the TCP flows between both hosts. It has the advantage that multiple, parallel flows can be generated relatively light-weighted by using the so called pthread library.

The TCP tests have been executed as a function of the # parallel flows between both hosts, and of the TCP window size which will be varied such that the sum of the TCP window over the # parallel flows will be kept constant. This make a better comparison possible of the results of the various # parallel flows, as the achieved TCP throughput is a.o. dependent from the total TCP window size.

Results

The results of the following TCP tests have been presented in this section:

A small step-size variation of the TCP window and of the # parallel flows with a fixed socket buffer size of 8000 Bytes.
A larger step-size variation of the TCP window and of the # parallel flows . Also the socket buffer size has been varied here.

Fixed Socket Buffer Size

Below the results of TCP throughput tests have been shown as a function of the sum TCP window (taken over the # flows), and of the # parallel flows between both Itanium hosts. Also the throughput values are sums taken over the # parallel flows. In these tests a fixed socket buffer size of 8000 Bytes have been used. The test duration was 60 s. Each 4 s a bandwidth interval report has been generated by Iperf.

From these interval reports the TCP throughput values were calculated as described below. In general the Iperf interval reports do not exactly match intervals of 4 s. Therefore, these reports are resampled by means of linear interpolation such that they are exactly 4 s intervals. The results of the parallel flows for the same interval are summed. From these summed values the median is calculated. By taking the median there will be corrected for TCP slow startup effects.

In the following plots results are presented from December 17, 2003. That is before the period when there were some hardware problems with the Chicago Itanium. Further below analogous results are presented when these problems had been fixed again. In the sum TCP throughput has been displayed as a function of the sum TCP window and the # flows for the direction StarLight -> Amsterdam Science Park and in for the reverse direction.

. Sum TCP throughput values, taken over the # parallel flows, as a function of the sum TCP window size, also taken over the # parallel flows, and of the # parallel flows for the test direction StarLight -> Amsterdam Science Park. The test date was December 17, 2003.

. Sum TCP throughput values, taken over the # parallel flows, as a function of the sum TCP window size, also taken over the # parallel flows, and of the # parallel flows for the test direction Amsterdam Science Park -> StarLight. The test date was December 17, 2003.

In the average TCP throughput per flow has been displayed as a function of the TCP window size per flow for the test direction StarLight -> Amsterdam Science Park. The results for some # parallel flows have been represented here by corresponding plot traces. In these data have been presented for the reverse direction.

. Average TCP throughput values per flow as a function of the TCP window size per flow for the test direction StarLight -> Amsterdam Science Park. The results for some # parallel flows have been represented by corresponding plot traces. The test date was December 17, 2003.

. Average TCP throughput values per flow as a function of the TCP window size per flow for the test direction Amsterdam Science Park -> StarLight. The results for some # parallel flows have been represented by corresponding plot traces. The test date was December 17, 2003.

In the corresponding figures have been presented as in the , but here for results that were obtained at February 17, 2004. That is after the hardware problems with the Chicago Itanium had been solved. Another difference with the previous results is that the maximum TCP window size per flow has been limited to 64 MBytes. The reason was that at that moment there were some suspicions that using large TCP window sizes could lead to problems in the OS.

. Sum TCP throughput values, taken over the # parallel flows, as a function of the sum TCP window size, also taken over the # parallel flows, and of the # parallel flows for the test direction Amsterdam Science Park -> StarLight. The maximum window size per flow has been limited to 64 MBytes/s and the test date was February 17, 2004.

. Average TCP throughput values per flow as a function of the sum TCP window size per flow for the test direction StarLight -> Amsterdam Science Park. The results for some # parallel flows have been represented by corresponding plot traces. The maximum window size per flow has been limited to 64 MBytes/s and the test date was February 17, 2004.

. Average TCP throughput values per flow as a function of the sum TCP window size per flow for the test direction Amsterdam Science Park -> StarLight. The results for some # parallel flows have been represented by corresponding plot traces. The maximum window size per flow has been limited to 64 MBytes/s and the test date was February 17, 2004.

From the results displayed in the the following conclusions can be drawn:

The obtained results are largely independent from the # flows. This is an indication that there are few strong host related artifacts.
In the executed at December 17, 2003 no directional effects were found, while in the tests that were executed at February 17, 2004, the throughput in the direction Amsterdam Science Park -> StarLight is slightly higher as in the reverse direction.

Socket Buffer Size Variation

In this section the influence of the socket buffer size variation has been studied. The other test parameters are the same as in the previous section, but also the socket buffer size has been varied from 2 KBytes to 16 KBytes.

In the the sum of the TCP throughput values, taken over the # parallel flows, has been displayed as a function of the sum of the TCP window size, also taken over the # parallel flows and the socket buffer size (per flow). In these figures the results have been presented for 2, 4, ..., 16 parallel flows in the direction StarLight -> Amsterdam Science Park. The are showing the corresponding results for the reverse direction Amsterdam Science Park -> StarLight.

. Sum TCP throughput values, taken over the # parallel flows, as a function of the sum TCP window size, also taken over the # parallel flows, and of the socket buffer size for the test direction StarLight -> Amsterdam Science Park using 2 parallel flows.

Show also the plots from the as in a new browser window.

. Sum TCP throughput values, taken over the # parallel flows, as a function of the sum TCP window size, also taken over the # parallel flows, and of the socket buffer size for the test direction Amsterdam Science Park -> StarLight using 2 parallel flows.

. Sum TCP throughput values, taken over the # parallel flows, as a function of the sum TCP window size, also taken over the # parallel flows, and of the socket buffer size for the test direction Amsterdam Science Park -> StarLight using 4 parallel flows.

. Sum TCP throughput values, taken over the # parallel flows, as a function of the sum TCP window size, also taken over the # parallel flows, and of the socket buffer size for the test direction Amsterdam Science Park -> StarLight using 6 parallel flows.

. Sum TCP throughput values, taken over the # parallel flows, as a function of the sum TCP window size, also taken over the # parallel flows, and of the socket buffer size for the test direction Amsterdam Science Park -> StarLight using 8 parallel flows.

. Sum TCP throughput values, taken over the # parallel flows, as a function of the sum TCP window size, also taken over the # parallel flows, and of the socket buffer size for the test direction Amsterdam Science Park -> StarLight using 10 parallel flows.

. Sum TCP throughput values, taken over the # parallel flows, as a function of the sum TCP window size, also taken over the # parallel flows, and of the socket buffer size for the test direction Amsterdam Science Park -> StarLight using 12 parallel flows.

. Sum TCP throughput values, taken over the # parallel flows, as a function of the sum TCP window size, also taken over the # parallel flows, and of the socket buffer size for the test direction Amsterdam Science Park -> StarLight using 14 parallel flows.

. Sum TCP throughput values, taken over the # parallel flows, as a function of the sum TCP window size, also taken over the # parallel flows, and of the socket buffer size for the test direction Amsterdam Science Park -> StarLight using 16 parallel flows.

Show also the plots from the as in a new browser window.

Below a different view will been given from the data that had been presented in the in the sense that plots of the sum TCP throughput values are presented as a function of the sum TCP window size and the # parallel flows. In the results have been presented for socket buffer sizes of 2, 4, ... 16 KBytes in the direction StarLight -> Amsterdam Science Park and in the for the reverse direction.

Show also the plots from the as in a new browser window.

. Sum TCP throughput values, taken over the # parallel flows, as a function of the sum TCP window size, also taken over the # parallel flows, and of the # parallel flows for the test direction Amsterdam Science Park -> StarLight using a socket buffer size of 2 KBytes.

. Sum TCP throughput values, taken over the # parallel flows, as a function of the sum TCP window size, also taken over the # parallel flows, and of the # parallel flows for the test direction Amsterdam Science Park -> StarLight using a socket buffer size of 4 KBytes.

. Sum TCP throughput values, taken over the # parallel flows, as a function of the sum TCP window size, also taken over the # parallel flows, and of the # parallel flows for the test direction Amsterdam Science Park -> StarLight using a socket buffer size of 6 KBytes.

. Sum TCP throughput values, taken over the # parallel flows, as a function of the sum TCP window size, also taken over the # parallel flows, and of the # parallel flows for the test direction Amsterdam Science Park -> StarLight using a socket buffer size of 8 KBytes.

. Sum TCP throughput values, taken over the # parallel flows, as a function of the sum TCP window size, also taken over the # parallel flows, and of the # parallel flows for the test direction Amsterdam Science Park -> StarLight using a socket buffer size of 10 KBytes.

. Sum TCP throughput values, taken over the # parallel flows, as a function of the sum TCP window size, also taken over the # parallel flows, and of the # parallel flows for the test direction Amsterdam Science Park -> StarLight using a socket buffer size of 12 KBytes.

. Sum TCP throughput values, taken over the # parallel flows, as a function of the sum TCP window size, also taken over the # parallel flows, and of the # parallel flows for the test direction Amsterdam Science Park -> StarLight using a socket buffer size of 14 KBytes.

. Sum TCP throughput values, taken over the # parallel flows, as a function of the sum TCP window size, also taken over the # parallel flows, and of the # parallel flows for the test direction Amsterdam Science Park -> StarLight using a socket buffer size of 16 KBytes.

Show also the plots from the as in a new browser window.

From the results presented in this section, where also the socket buffer size have been varied the following can be concluded:

Variation of the socket buffer size does not show much effect.
Also in these results the performance in the direction Amsterdam Science Park -> StarLight is slightly better than in the reverse direction.

Conclusions

From the TCP tests the following conclusions can be drawn:

The TCP performance of the Itanium hosts is as could be expected theoretically. There are no differences in the performance as a function of the # flows. This probably implies that there no severe host implementation limitations.
The maximum throughput in the direction Amsterdam Science Park -> StarLight is about 5.2 Gbits/s and 5.0 Gbits/s. The differences may also be related with the differences in used Linux kernels.
Variation of the socket buffer size does not have much influence in the obtained TCP throughput values.

SL - ASP - Itanium Tests

Table of Contents

UDT Tests

Rate Limit