SL - ASP Itanium Tests -- Rate Limit -- UDP Bulk Tests

UDP Bulk Tests

Description

Below the results of executed UDP bulk tests will be displayed. Also in these tests the Iperf V. 1.6.5 traffic generator will be used. The UDP bulk tests have been executed as a function of the shaping bandwidth and of the # parallel flows. The UDP tests have been executed in both directions, also in the directions with and without rate limiting.

Results

In the following plots the sum UDP client and server bandwidth values, taken over the # parallel flows, has been displayed as a function of the sum shaping bandwidth, also taken over the # parallel flows, and as a function of those # parallel flows. The duration of each flow was 60 s. the sum client and server bandwidth values were taken over the final bandwidth values of the single flows. In figure 1 the client bandwidth is presented for the direction with rate limiting Amsterdam Science Park -> StarLight, while the server bandwidth for that direction is shown in figure 2. In figure 3 the client bandwidth is displayed for the reverse direction StarLight -> Amsterdam Science Park and in figure 4 the server bandwidth for that direction.

Figure 1. Sum UDP client bulk bandwidth, taken over the # parallel flows, as a function of the sum shaping bandwidth, also taken over the # parallel flows, and of the # parallel flows for the direction with rate limiting Amsterdam Science Park -> StarLight.

Figure 2. Sum UDP server bulk bandwidth, taken over the # parallel flows, as a function of the sum shaping bandwidth, also taken over the # parallel flows, and of the # parallel flows for the direction with rate limiting Amsterdam Science Park -> StarLight.

Figure 3. Sum UDP client bulk bandwidth, taken over the # parallel flows, as a function of the sum shaping bandwidth, also taken over the # parallel flows, and of the # parallel flows for the direction without rate limiting StarLight -> Amsterdam Science Park.

Figure 4. Sum UDP server bulk bandwidth, taken over the # parallel flows, as a function of the sum shaping bandwidth, also taken over the # parallel flows, and of the # parallel flows for the direction without rate limiting StarLight -> Amsterdam Science Park.

Below a different view at the data has been offered enlarged with information about the # packet lost. In the following figures the UDP sum server bandwidth, taken over the # parallel flows, and the total # packet lost for all parallel flows have been displayed as a function of the sum client bandwidth (also taken over the # parallel flows) for both directions StarLight <-> Amsterdam Science Park. In the figures 5, 6, ..., 12 these results have been displayed for 1, 2, ..., 8 parallel flows.

Figure 5. Sum UDP server bandwidth, taken over the # parallel flows, and the total # packet lost for all parallel flows have been displayed as a function of the sum client bandwidth (also taken over the # parallel flows) using one parallel flow.

Figure 6. Sum UDP server bandwidth, taken over the # parallel flows, and the total # packet lost for all parallel flows have been displayed as a function of the sum client bandwidth (also taken over the # parallel flows) using two parallel flows.

Figure 7. Sum UDP server bandwidth, taken over the # parallel flows, and the total # packet lost for all parallel flows have been displayed as a function of the sum client bandwidth (also taken over the # parallel flows) using three parallel flows.

Figure 8. Sum UDP server bandwidth, taken over the # parallel flows, and the total # packet lost for all parallel flows have been displayed as a function of the sum client bandwidth (also taken over the # parallel flows) using four parallel flows.

Figure 9. Sum UDP server bandwidth, taken over the # parallel flows, and the total # packet lost for all parallel flows have been displayed as a function of the sum client bandwidth (also taken over the # parallel flows) using five parallel flows.

Figure 10. Sum UDP server bandwidth, taken over the # parallel flows, and the total # packet lost for all parallel flows have been displayed as a function of the sum client bandwidth (also taken over the # parallel flows) using six parallel flows.

Figure 11. Sum UDP server bandwidth, taken over the # parallel flows, and the total # packet lost for all parallel flows have been displayed as a function of the sum client bandwidth (also taken over the # parallel flows) using seven parallel flows.

Figure 12. Sum UDP server bandwidth, taken over the # parallel flows, and the total # packet lost for all parallel flows have been displayed as a function of the sum client bandwidth (also taken over the # parallel flows) using eight parallel flows.

Show also the plots from the figures 5, ..., 12 as animation in a new browser window.

Conclusions

From the UDP bulk tests presented in the figures 1, ..., 12 the following conclusions can be drawn:

Only for 1 and 2 parallel flows the maximum UDP server bandwidth in the rate limit direction ASP -> SL (see a.o. figures 5 and 6), but that is still considerably below the rate limit bandwidth of 2800 Mbits/s.
When three or more parallel flows are used the client bandwidth is rapidly decreasing (figures 7, ..., 12). Probably this is due to host limitation effects. Therefore, the obtained server bandwidths are difficult to compare as a function of the # parallel flows. But as a function of the client bandwidth the server bandwidth in the rate limit directions is slightly decreasing, and corresponding the percentage packet lost is slightly increasing (see also the animation window). The reason probably is that with more parallel flows the chance for packet lost is increasing caused by an increasing collision chance.
In the results with one and two parallel flows (figures 5 and 6) there are many fluctuations in the results for the server bandwidth and the corresponding percentage packet lost in the rate limit direction, especially for client bandwidth values between 1 and 2 Mbits/s. The relatively small burst size of 50 KBytes, that has been configured at the Force 10 switch, could play a role here.
In the test direction without rate limiting, SL -> ASP there is never packet lost and the destination, server bandwidth is always equal to the sender, client bandwidth. Also the obtained bandwidth values are completely determined by sender limitations.