There is some confusion here. First, some information on iperf 2 which is not the predecessor to iperf 3. Iperf 2 is the continuation of the original iperf that was abandoned in 2010 or so. We in Wi-Fi chips took over maintenance in 2014. It's mostly been rewritten since then though adhering to the major design patterns, e.g. threads and separation of user i/o from traffic i/o. More about the differences here: https://iperf2.sourceforge.io/IperfCompare.html
To your reasons (which don't necessarily apply to iperf 2.) Also note, that tools really need broad statistical verifications before they can be used broadly and across platforms. This is non trivial and goes beyond code writing.
Reason 1: There really is minimal support by ESNet for any release. They are a research group. The most testing & support, including statistical verification from release to release, comes with iperf 2 because Wi-Fi mfgs have something like 14B devices in the field. We also do test 100G+ networks as chips (NICs and merchant forwarding silicon) support that too.
Reason 2: MingW support does allow for posix calls. Some key things are:
- Some use iperf for network measurements
- Some use iperf to characterize applications that use TCP/UDP or end to end which includes host stacks and app level writes/reads.
The CPU, and hence emulation, should not be the bottleneck for network measurement. If it is, then iperf is not a network test tool anymore. It becomes a syscall limited tool. Second, interactions with the stack can impact interoperability but that usually shows up as latency of syscalls that get seen by the network message passing. Again, not a network issue, but a stack/app issue. So, from a network capacity test perspective, the use of posix emulation shouldn't matter. Latency measurement or CPU constrained systems need more analysis and posix emulation could have impacts.
Reason 3: Yes, iperf.fr is woefully out of date and spreads misinformation. A suggestion is to go the sites for authoritative information. There is much misinformation found on the net, lots and lots of misunderstandings.
Also, your article conflates two different metrics, throughput and latency. Iperf 2 has had a focus on latency, including one way delay, traffic patterns & measurements for years now. Most don't understand latency and those impacts on user experience. More capacity, or a capacity measurement, shouldn't be confused with latency or responsiveness.
Finally, IPerf 2 https://sourceforge.net/projects/iperf2/ is different from the iperf3 found at https://github.com/esnet/iperf Each can be used to measure network performance, however, they DO NOT interoperate. They are completely independent implementations with different strengths, different options, and different capabilities. Both are under active development.
Thanks for starting the discussion.
PS. A localhost test can provide CPU & syscall measurements, e.g. iperf -c localhost -i 1 -e and iperf -s