3 ms·

It’s a shame that they don’t talk about it in the article but a big part of the drive toward next generation tools is to study the interfaces needed and used by

by raggi 2y ago

It’s a shame that they don’t talk about it in the article but a big part of the drive toward next generation tools is to study the interfaces needed and used by quic implementations which can’t “just be solved by” the flags you’re talking about, and iperf has no support for the relevant features (offloads).

klabb3 2y ago
Yeah, to be fair I’m assuming tcp both on the iperf side (which I always use it for) and the alternative ntttcp tool does have TCP in the name although it appears they have UDP support as well(?) I know UDP and QUIC comes with a ton of novel bottlenecks throughout the stack (even down to the NICs, no?), and at the very least tons of knobs, which warrants more custom tooling and keeping up with the latest in terms of OS/platform support. I can totally see how iperf isn’t suited for that. Still, it’s a pretty strong and different message that Microsoft is sending on an official channel, which is unfortunate if it indeed is the case that iperf works just fine on windows with pretty standard flags (note that even on typical Linux recv buffers are constrained to ~6MiB so -P is standard for WAN saturation tests). (Also good to see your relentless attention to engineering details as always. We used to work together some years back)
- raggi 2y ago
  It largely depends what you mean by "works just fine", if all you want is "high throughput on a low latency link" then sure, whack up the buffer and throw it at the wall, it'll stick - but you can just as well use curl for that. To study higher end network stacks or more modern protocol dynamics, or cross network flows, the other tools are providing much better insights. The need for -P for basic tests is also telling and part of the problem: if the tool can't outpace a browser then even for these "basic cases" it's showing its inadequacy for the kinds of things the bulk of users care about even today, even with old protocols.

by raggi 2y ago

klabb3 2y ago

Yeah, to be fair I’m assuming tcp both on the iperf side (which I always use it for) and the alternative ntttcp tool does have TCP in the name although it appears they have UDP support as well(?) I know UDP and QUIC comes with a ton of novel bottlenecks throughout the stack (even down to the NICs, no?), and at the very least tons of knobs, which warrants more custom tooling and keeping up with the latest in terms of OS/platform support. I can totally see how iperf isn’t suited for that. Still, it’s a pretty strong and different message that Microsoft is sending on an official channel, which is unfortunate if it indeed is the case that iperf works just fine on windows with pretty standard flags (note that even on typical Linux recv buffers are constrained to ~6MiB so -P is standard for WAN saturation tests). (Also good to see your relentless attention to engineering details as always. We used to work together some years back)

raggi 2y ago
It largely depends what you mean by "works just fine", if all you want is "high throughput on a low latency link" then sure, whack up the buffer and throw it at the wall, it'll stick - but you can just as well use curl for that. To study higher end network stacks or more modern protocol dynamics, or cross network flows, the other tools are providing much better insights. The need for -P for basic tests is also telling and part of the problem: if the tool can't outpace a browser then even for these "basic cases" it's showing its inadequacy for the kinds of things the bulk of users care about even today, even with old protocols.