Closed amass87 closed 7 years ago
I use 4 parallel streams with -P 4 parameter. By using multiple streams I get better throughput than using one stream.
I do the same, and I get better throughput. Honestly though I am dealing with a customer who swears they should get better throughout with 1 TCP session instead of multiple. So I am now trying to find a tool that can test the limits of Windows TCP Receive Window Autotuning.
Sent from my iPhone
On Nov 23, 2016, at 1:22 PM, taismi notifications@github.com<mailto:notifications@github.com> wrote:
I use 4 parallel streams with -P 4 parameter. By using multiple streams I get better throughput than using one stream.
You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/esnet/iperf/issues/481#issuecomment-262608042, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AWjMmnD-An2kF3r6a5xbc_lwvH83MMPnks5rBJKIgaJpZM4K43dx.
To address the original comment, the window size limitation you observed isn't from iperf3. If you specify a maximum window size from the command line, there's a 512MB sanity-check limitation, but if you let it autoscale (I don't know if Windows supports autoscaling in its TCP implementation) there's no theoretical limit imposed by iperf3.
It appears that iPerf3 has a default window size cap of 212992. When I packet capture iPerf traffic between 2 Windows Servers, TCP autotuning in Windows only scales to a maximum window of 53248 with window scale multiplier of 4. This issue persists across 2 separate tunnels with similar RTT and is the same whether I am using Server 2008 R2, Server 2012R2, or Windows 7. This is a problem for testing long fat networks.
I am trying to to test the limitations on an ipsec tunnel with 1Gbps Internet at both ends and a 28ms RTT. However, I appear to be hitting an artificial limit. I can use the -w flag, but it requires a lot of guess and check work. It seems the sweet spot is somewhere around a window of 524288. It might be asking a lot, but their should be a way to allow iperf to use the underlying receive window of the OS to test real world limitations.