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.

See #1632