Transfer Tests between London UCL HEP and Bristol Physics

Conducted on Monday 26th November 2001

IperfER is currently monitoring this site from pc35.hep.ucl.ac.uk. See here.

PingER is currently monitoring this site from pc35.hep.ucl.ac.uk. See here.

Results

Initial Pipechar results here. They seems to show apparent bottlenecks at man-gw-1-bwe.net.uk, ub-gw-1.bwe.net.uk, and br1.nwpp.bris.ac.uk. With the lowest throughput shown at man-gw-1.bwe.net.uk with only a throughput of 22.46Mbits/sec.

Bristol's server (bsesrv1.phy.bris.ac.uk) was initially set with a buffersize of 1024k and a series of iperf transfer from UCL (pc35.hep.ucl.ac.uk) with various buffer sizes were conducted:

Click here to analyse the web100 files.

The maximum throuhgput of 12Mbps seems strange as the pipechar results indicate that we should see about 22Mbits/sec. The fact that it the maximum bandwidth does not occur with high socket buffer size indicated that we are saturating the network with too many packets. This is also shown in the graph below,

This shows the amount of time that the cwnd is the limiting factor in the transfer. 1e+06 is 1 second, and as you can see, for high client socket buffer sizes, the ratio of which the cwnd is the limiting factor is almost always 1. It is only for the lower socket buffer sizes that this isn't so. It is interesting to note that the transfer becomes limited by the cwnd when the client socket buffer is set to 64k.

Analysis of the CurrentRwinRcvd shows the window size that TCP/IP actually see's of the remote host (server). This is shown below,

For all values, the RcvdWin size seems to be at around 64k. Considering the test were set for 1024k, it shows that bsesrv1 is currently set to have a maximum window size of only 64k.

An email was sent to adjust the rmem_max and wmem_max parameters in order to increase the maximum values of the server socket buffer size. See here for more details.

However, the problems associated with the funny peaking of the socket buffer size against throughput should not be caused by a limited server sb. As such, and with the pipechar results as a backing, it is possible that the network path is limited by the routers.

Looking at the number of timeouts during the transfers,

shows a considerable number of timeouts considering the low RTT of the link between here and bristol of about 12ms. However, the variation (mean deviation) is quite high with a value of approx 2 ms. This is most likely this variation that is going beyond th bounds of the RTT Timeout clock set in TCP/IP causing a timeout.

Tests were continued on the 28-11-01. Here.

Update:

Due to the set rwin size of 64k on bsesrv1, high socket buffer sizes set on the sending host should show that the link is being limited by the socket buffer sizes on bsesrv1. This is the output of Web100,

This shows that for all sending socket buffer sizes, web100 shows that there is no problem with pc35 recieving stuff in. As we are not actually receiving any information (except for ACKS) this graph makes sense.

Wed, 28 November, 2001 16:30