> The average [of iperf3] across multiple tests was about 7.5 Gbps.<p>> Ntttcp averaged about 12.75 Gbps […] Ntttcp does something called pre-posting receives, which is unique to this tool.<p>This is TCP we’re talking about, and with large enough buffer—per-syscall (128k on my iperf3 by default - that’s good) you should be able to saturate even a thick line, provided auto-tuning is enabled correctly. But just add -P 16 to parallelize to be sure it’s not the TCP stack, instead? Did they even try a workaround, before suggesting an extremely limited and proprietary tool that nobody is familiar with? Or better yet, help the project out by contributing native code if the open source community is so bad at windows? At the very least, make a wire-compatible version.<p>Iperf is a very boring and wonderful tool that just works. Importantly, it’s a <i>networking</i> tool, which means you need interop across different systems. Any networking tool that’s single-platform is dead in the water, as far as I’m concerned.<p>Edit: To be fair, I see they have a Linux version, how generous. Last updated in 2022 and many open issues though.
> What Does Microsoft Recommend<p>> Microsoft maintains two synthetic network benchmarking tools, ntttcp (Windows NT Test TCP) and ctsTraffic.<p>Okay, let's see which of these is compatible with the iperf3 available on my locked-down commercial router (or, alternatively, the test endpoint my ISP provides) …<p>…it's neither…<p>…aaaaand we're back to iperf3 on Windows. :-(<p>As tongue-in-cheek this comment may be, a recommendation for 2 incompatible tools is worth nothing. Iperf is the de-facto standard, if anything the problem is sometimes you have iperf2 around for some reason. If, Microsoft, you want better Windows network stack benchmark results, you'll need to make something compatible with iperf3 (or fix iperf3.)<p>(It does not matter that ntttcp runs on Linux. I can't install ntttcp on an Ubiquiti router, or ask my ISP to add another test endpoint.)
"Go search for “iPerf3 on Windows” on the web. Go ahead, open a tab, and use your search engine of choice. Which I am certain is Bing with Copilot."<p>For many people it won't be by choice, it'll be because Windows' plethora of dark patterns and anti-consumer features have tricked you into using it, or taken away your previous explicit choice.
Perhaps Microsoft should work with OpenWRT to get the linux version of ntttcp incorporated and built for routers as a package. I use iperf2/iperf3 because it is provided by opkg.
This article is actually right that I downloaded the old version for Windows (would not happen on another OS, as there are maintained packages in most of the package managers).<p>But I just checked with the newer version and I didn't see a difference when testing with my 2.5GbE LAN (still 2.3Gbit UP and 1.9Gbit DOWN)
iperf3 is popular because its in the router software stack and a good way to check the raw performance. I know from my own experience that iperf3 on windows performs fairly similar to Linux on a modern machine all the way up to 10 gbit/s. Its a theoretical problem not a practical one but if Microsoft has a better solution then they can open source it and do the work to include it in the open source router software and it will get used.
I wonder how it performs under WSL. I assume worse than the suggested benchmarking tools, but far better than the outdated Iperf3 version using cygwin that the page references.
ntttcp only has packages for Debian, Ubuntu, and NetBSD:<p><a href="https://pkgs.org/download/nttcp" rel="nofollow">https://pkgs.org/download/nttcp</a><p>No user of the other commercial Linux distros (RHEL, SLES) is going to install ntttcp from source or random binaries.<p>Of course, the Windows kernel team could support POSIX system calls that iperf and other network applications require, instead of removing that feature altogether:<p><a href="https://learn.microsoft.com/en-us/archive/technet-wiki/10224.posix-and-unix-support-in-windows" rel="nofollow">https://learn.microsoft.com/en-us/archive/technet-wiki/10224...</a><p>But hey why provide customers a good product when you can just write a blog with a useless recommendation instead.<p>Microsoft is a big company with many teams on many products. Some of those teams really understand interoperability with modern developers and applications. This team don't.
Just some clarification: IPerf 2 is different from the iperf3 found at <a href="https://github.com/esnet/iperf">https://github.com/esnet/iperf</a> 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.<p>The current release of iperf 2 is 2.2.0 but 2.2.1 with bug fixes will be out soon.<p>Comparison table here: <a href="https://iperf2.sourceforge.io/IperfCompare.html" rel="nofollow">https://iperf2.sourceforge.io/IperfCompare.html</a>
Yet again this article shows how Microsoft programmers don't dogfood their own console applications.<p>Compare invocations for these commandline apps:<p>Linux app:<p><pre><code> iperf3 -s
</code></pre>
Windows app:<p><pre><code> .\ctstraffic.exe -listen:* -Buffer:"$(128KB)" -Transfer:"$(1TB)" -ServerExitLimit:1 -consoleverbosity:1 -TimeLimit:60000
</code></pre>
Who the hell wants to type all of that out?
Also, with iperf 2, -c localhost seems to perform the same on Windows as it does for Linux. So skeptical that the cygwin overhead is very large.<p>A binary is here <a href="https://sourceforge.net/projects/iperf2/files/" rel="nofollow">https://sourceforge.net/projects/iperf2/files/</a>
Over the years I've used a variety of network test tools including ntttcp, iperf, hrPing, and I even whipped a couple of custom ones.<p>I've gravitated towards using custom test tools that use the same pattern as the application that will run on the network. So instead of testing maximum UDP throughput or with dozens of TCP threads with artificially high window sizes, I test with "whatever it is" that the client/server apps are likely to do.<p>I still use hrPing, because it behaves a lot like a large category of common server apps, such as Linux tools ported to Windows.