Attempt to fix some brokenness in -F from #301.
In some work related to #125, we introduced a bug in which
chunks of a file being read for the -F option were not
completely sent, particularly with TCP sockets. We attempt
to fix this by detecting cases in which not all data passed
to a socket could be actually sent (for example due to full
socket buffers) and preserving that data for future send
iterations.
The ending statistics in the "diskfile" JSON structure were
wrong, and did not properly distinguish between sender-side
and receiver-side statistics. This has been fixed (at least
for the client side).
Specifically mention in the manpage that "iperf -F" is not
a file transfer tool.
Improve the compatibility of iperf_api.h with C++ so that libiperf can more easily be used with C++ programs.
This involves function declarations as extern "C" and inclusion of a couple of more headers (which arguably improves the C use case).
* 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).
* Add configurable timeout for the setup of the control connection.
This is specified using the new --connect-timeout option, with an
integer parameter in ms. The iperf3 client will wait for this
amount of time for the setup of the control connection to the
server. If this option is not given, the OS default for TCP
connection setup is used. Specifying a smaller connection timeout
allows faster detection of a down / unresponsive iperf3 server.
The implementation uses a variation on the timeout_connect()
function from OpenBSD's netcat utility.
Fixes#216.
For the case of multiple TCP streams, compute the grand total
summaries using the appropriate times for the sender and receiver
ends.
Add some divide-by-zero checks.
On the server side, only print the side of the grand total lines
where we have data. (This follows the behavior of the other
end-of-test output lines.)
Fix a minor (compared to all the other problems) bug with
UDP output printing the wrong ending timestamp.
Recent code changes require the server to send the start and end
timestamps for a test, so that the client can accurately compute
statistics for the sender side of a test. iperf 3.1 and 3.0
servers won't do this, so if this information isn't passed back
in the results at the end of a test, we fall back to using the
client's timestamps. The results might not match what's displayed
on the server, but this is basically what iperf 3.1 and earlier
did anyway.
Fixes#574.
Keep track of UDP packets sent/received and use appropriately.
We were using the number of UDP packets seen on the server
(regardless of whether it was the sender or receiver) for
computing loss percentages, etc. This caused confusion in the
case that the last UDP packet doesn't make it to the server
before the test finishes (or if a packet gets lost), because
the client and server had different ideas of how many packets were
sent (OK) and we used the wrong number when computing statistics.
This fix changes the human-readable output to make more sense.
It doesn't change the JSON output. That needs some more review.
I'm reluctant to make structural changes to the JSON output,
because other programs rely on that format.
We also need to investigate whether the last UDP packet can be
still in flight when the test ends (per hypothesis), and if so
what we should do about this.
We apply similar fixes for human-readable summaries for multi-stream UDP tests.
The fixes are similar to those already done for the stream
summary statistics, but these cover a type of output that's only
done if there is more than one stream.
Adjust the JSON computations / output to do a better job of figuring
out the total number of packets sent.
We really need to disentangle the computation and output formatting,
these two operations shouldn't be mixed together like this.
Fixes#252.
We now reject all invalid format characters given as the
argument to the -f/--format flag. All valid characters are now
documented in the usage message and manual page.
Towards #566.
Commit 5ab2132c (PR #551) fixed, among other things, a memory
leak. The solution, however, causes a hazard where a free() of
an invalid pointer can corrupt the heap. We've observed this
fairly repeatably while running the test_commands.sh script on
CentOS 7.
To remedy this, we NULL out a pointer after the object it
pointed to has been free-d, just like a number of other similar
objects.
* Add --pacing-timer option to allow tuning of -b timers.
These control the granularity of the timer and hence burstiness
of iperf3's sends. The default is 1ms (1000), which is the default
starting with iperf 3.2. Follow-on to the commit in #460.
* Update manpage and release notes for --pacing-timer.
These values show up in the start structure as sock_bufsize (requested
size), sndbuf_actual (actual SO_SNDBUF value) and rcvbuf_actual (actual
SO_RCVBUF value). These values are available for both TCP and UDP.
Both client and server emit these values in their JSON output for their
respective sides, but don't exchange them.
Towards #558.
* Untangle some problems with printing summary statistics.
There were (at least) two problems:
o The server cannot print summary statistics as seen from the
client, because the server has to generate its summaries
before receiving any statistics from the client. This
shortcoming is somewhat hard-coded into the semantics of
messages on the control channel, and probably can't be easily
changed.
o UDP summary statistics for each stream were ambiguous in that
it wasn't clear whether they were intended to apply to the
sender or receiver.
To fix this, we split UDP summary statistics into two lines,
one for the sender side and one for the receiver side. This
hopefully eliminates any ambiguity about the statistics. On the
server, we don't attempt to print the (not very meaningful and
potentially misleading) statistics corresponding to the client.
Possible fix for #560.
* Try to report more accurate ending statistics.
Basically the client side was using only its measured test duration
to compute figures such as bitrate, but the server's test duration
could be different due to network delays/jitter. So we make sure
that the test durations (for each stream) are passed in the test
results and used appropriately when we print statistics for the
sender and receiver.
Towards #560, also this could help towards #238.
* Silence a warning over an uninitialized variable.
Basically the client side was using only its measured test duration
to compute figures such as bitrate, but the server's test duration
could be different due to network delays/jitter. So we make sure
that the test durations (for each stream) are passed in the test
results and used appropriately when we print statistics for the
sender and receiver.
Towards #560, also this could help towards #238.
There were (at least) two problems:
o The server cannot print summary statistics as seen from the
client, because the server has to generate its summaries
before receiving any statistics from the client. This
shortcoming is somewhat hard-coded into the semantics of
messages on the control channel, and probably can't be easily
changed.
o UDP summary statistics for each stream were ambiguous in that
it wasn't clear whether they were intended to apply to the
sender or receiver.
To fix this, we split UDP summary statistics into two lines,
one for the sender side and one for the receiver side. This
hopefully eliminates any ambiguity about the statistics. On the
server, we don't attempt to print the (not very meaningful and
potentially misleading) statistics corresponding to the client.
Possible fix for #560.
On FreeBSD, unlike Linux (and NetBSD?) snd_cwnd is expressed in
octets instead of segments. Hilarity ensued when we erroneously
multiplied by snd_mss and integer overflows occureed.
Possible fix for #465, #475, #338. Testing from FreeBSD users
appreciated.
