esnet
-b and --fq-rate flags should be mutually exclusive
I think it does not make sense to give both -b and --fq-rate flags for iperf3. iperf3 should give an error in that case.
There could be a use case for using both rate limits with --bidir, since --fq-rate doesn't apply to the server (yet).
It might be better to print a warning instead, like when a large, but valid UDP length is set in iperf.
FYI I am currently using both for the exact reason @WBINVD mentioned. I am running a bidirectional test where I need to constrain the bandwidth in both directions. The ideal would be if --fq-rate worked on both client and server, since it has lower CPU overhead, but as a workaround I specify both, with a slightly higher value for --bitrate. e.g.
--fq-rate "2000m" --bitrate "2005m" --bidir
With this approach, CPU usage stays low on the client because --fq-rate kicks in before --bitrate, and --bitrate works on the server side.
cc @bmah888 please don't merge the PR until --fq-rate is supported on the server.
Going to close this issue for now because, while the behavior from specifying both -b and --fq-rate can create confusion, it’s not outright harmful. We can re-open it later if there’s a more compelling reason.