| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
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.
|
|
* 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.
|
|
Most of the text contributed by @bltierney.
|
|
|
|
Move old news to a lower section level to avoid cluttering up the
table of contents. Update copyrights and some other version numbers.
|
|
|
|
|
|
|
|
|
|
While here some minor formatting tweaks.
|
|
|
|
Building and deploying the documentation requires some infrastructure
that's not part of this tree.
|
