-b and --fq-rate flags should be mutually exclusive

[bltierney]

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.

[WBINVD]

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.

[talawahtech]

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.

[bmah888]

See #1632

[bmah888]

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.