![]() |
Bulk Throughput Measurements - SoXBulk Throughput Measurements | Bulk Throughput Simulation | Windows vs. streams | Effect of load on RTT and loss | Bulk file transfer measurements |
ndd /dev/tcp tcp_max_buf = 4194304 ;ndd /dev/tcp tcp_cwnd_max = 2097152 ;ndd /dev/tcp tcp_xmit_hiwat = 16384 ;ndd /dev/tcp tcp_recv_hiwat = 24576The window buffer sizes on gigatcp1 were as shown below:
sysctl kern.ipc.maxsockbuf = kern.ipc.maxsockbuf: 20480000 ;sysctl net.inet.tcp.rfc1323 = net.inet.tcp.rfc1323: 1 ;sysctl net.inet.tcp.sendspace = net.inet.tcp.sendspace: 1024000 ;sysctl net.inet.tcp.recvspace = net.inet.tcp.recvspace: 1024000
Unfortunately I was unable to install iperf on gigatcp1 with multi thread support (the host appears to lack pthreads support), so we were unable to make tests with multiple streams.
The performances (seen below) are very asymmetric, throughput being a factor of 8 better
from SLAC to SoX than from SoX to SLAC. This is not understood.
I looked with tcpdump on pharlap at the iperf packets coming from 199.77.194.26 the
wscale is set to 7, and the window 65535 in the SYN packet. The SYN ACK from pharlap
has a wscale of 7 and a window of 32772. The MSS advertised by 199.77.194.26
is 4430 bytes and pharlap advertises 1460 bytes. The don't fragment bit is set on
most packets in both directions.