* Issue 1065
* feat: Allow to configure a custom value for time drift between client/server for authentication
The use case is to support scenarios where it's not possible to enforce sync between client and server times.
* enh: drift redefined with skew
Co-authored-by: Francesco Marino <francesco.marino@cybaze.it>
That mention points to the iperf3 FAQ, which contains information
about the history of iperf2 and iperf3, and a pointer to continued
iperf2 development. Suggested by a comment from @beau-williamson
in #27.
This question has come up a few times, so even though iperf3
doesn't officially support any Windows platform, I'm putting
this in here. Thanks to @ijspzpt for the references.
Addresses #590 and possibly #546.
* s/bandwidth/bitrate/ in user-facing places. Towards #583.
iperf3 has long misused terminology; bandwidth is a measure of
capacity. iperf3 measures bitrate or throughput. We standardize
on "bitrate" because it begins with the same letter as "bandwidth"
(to match the -b command-line option).
User-facing output mentioning "bandwidth" now uses "bitrate".
The long command-line option for -b (--bandwidth) is now --bitrate
(--bandwidth is transparently accepted for backward compatibility).
A few places in documentation that talk about bandwidth as a
measured value have been reworded to use bitrate or throughput.
There are a number of places in code where variables are still
called "bandwidth". We leave these alone for now.
A mention of "bandwidth" in the test parameters JSON also needs
to remain unchanged to avoid breaking compatibility. However,
the test results JSON never used the term "bandwidth" in
the first place.
* s/bandwidth/throughput in one place in RPM description. Towards #583.
While here, add a few words of explanation that the manpage might
not correspond to a current version of iperf3 (at this moment in
time, it in fact is from the not-yet-released iperf-3.2).
