This value is available on the sender side, expressed in
microseconds. It's available in the JSON output.
In the JSON output we also output the maximum observed RTT
per-stream. Note that since the observation interval is many times
the RTT, it's not clear how good this value would be at capturing the
largest computed RTT value over the lifetime of each stream.
While here, also determine the maximum observed snd_cwnd value over
the lifetime of each stream.
This all works pretty well on Linux, but on FreeBSD (which should
theoretically be supported) we don't do a good job of supporting the
tcp_info structure. We need to make this code a lot more portable,
rather than just assuming the world of platforms is "Linux"
vs. "everything else". Fixing this requires some rearchitecting of
the way that we retrieve, compute, and print statistics.
Part of a fix for #215.
For UDP over IPv4, this is the maximum IPv4 packet size (65535) minus
the size of the IPv4 and UDP headers, arriving at 65507.
In theory for a system implementing IPv6 jumbogram support, there is
no maximum packet size for UDP. In practice we've observed with
CentOS 5 a limitation of 65535 - 8, which is dictated by the size
field in the UDP header (it has a maximum value of 65535, but needs
to count both payload and header bytes, thus subtracting off the 8
bytes for the UDP header).
We take the most conservative approach and use the 65507 value
for UDP / IPv4.
This is (I believe) the last part of issue #212.
This can happen if the server gets into a weird state (see the test
cases for reproducing issue #212). We need to do a couple of checks
to make sure we're not dereferencing NULL pointers (yay C).
While here, also fix up a couple of related output glitches, where
in this case we can emit some invalid JSON (NaN values, such as what
you get if there's a division by zero, are not valid JSON).
Part of a fix in progress for #212.
with system header <locale.h>.
This apparently fixes problems on an ARM build, but this was generally
broken anyway. It's slightly amazing this didn't cause problems before;
perhaps we never used <locale.h> before?
Addresses #203.
UDP tests store a packet sequence number in the packets to detect loss
and ordering issues. This sequence number is a 32-bit signed integer,
which can wrap during very long-running UDP tests. This change adds
an option (defaulting to off) which uses a 64-bit unsigned integer to
store this quantity in the packet. The option is specified on the
client side; the server must support this feature for proper
functioning (older servers will interoperate with newer clients, as
long as --udp-counters-64-bit is not used).
The default might be changed in a future version of iperf3.
As a part of this change, the client sends its version string to the
server in the parameter block.
Uses a public-domain compatibility shim for 64-bit byte order
conversions. There are probably some additional platforms that need
to be supported, in particular Solaris. We might add some
configure-time checks to only enable this feature on platforms where
we can support the byte-order conversions.
This change is not well-tested.
Towards issue #191.
We support using k, m, and g as suffices on input values. In most
cases these are 2-based suffixes (i.e. K == 1024) because they are
sizes of objects. In the case of rates, we need to use 10-based
suffices (i.e. K == 1000).
We do this by implementing (using copy-and-paste) a unit_atof_rate()
subroutine that parses strings similarly to unit_atof but using
10-based suffices instead.
Fixes#173.
If specifying -B with an IPv4 literal address or with an FQDN that
resolved to an IPv4 address, but we had not explicitly specified an
address family with -4, we failed to set up the socket correctly
because we assumed binding to an IPv6 address, and instead (after some
error spewage) wound up binding to wildcard address.
The fix in this commit has multiple parts: First, if the address
family hasn't been explictly specified, don't force AF_INET6 in the
hints to getaddrinfo(3). AF_UNSPEC should generate the correct
(according to RFC 6724) behavior.
Second, iperf_reset_test() should not discard members that were passed
from command-line parameters, because that alters the behavior of the
iperf3 when it tries to recreate the listening socket. In the failure
situation described in this issue (and possibly other as well), the
value of -B gets discarded, so on subsequent attempts to set up the
listening socket it just binds to the wildcard address.
While here, fix on-line help related to the -B option to match
reality.
Note that we're not completely in compliance with RFC 6724, which
states that we should actually try all of the addresses in returned by
getaddrinfo(3), rather than just the first one.
Fixes Issue #193.
The various "connected" structures were just dumped into the "start"
structure. This caused problems if there were multiple connections
(i.e. multiple parallel streams), because the "connected" structures
would overwrite themselves. Instead, make these structures members
of a "connected" array.
This is technically an incompatible API change, but the prior behavior
was unusable.
Discovered and fix suggested by: @i2aaron
An open(2) call had two arguments instead of the required three.
While here, replace a hard-coded mode in a different open(2) call
with symbolic constants for readability.
Fixes#183.
Submitted by @ssahani.
retrieve (most of) the output emitted by the server.
If the server was invoked with the --json flag, the output will be in
JSON, otherwise it will be in the human-readable format.
If the client was invoked with the --json flag, the output will be
contained within the JSON output structure, otherwise it will be
appended (in whatever format) to the bottom of the human-readable
output.
Because of the sequencing of the output generation and display, the
server-side output includes only the starting output, interval
statistics and summaries, but not the overall summaries. (The overall
summaries were already displayed in the client's output.)
Towards issue #160.
algorithm selection) option to work on FreeBSD for free, starting with
FreeBSD 9. Update various documentation places to note this. One
specifies the congestion algorithm in the same was on Linux, although
the names of the algorithms are (at least in the general case) different.
"sysctl net.inet.tcp.cc" on FreeBSD provides a list of available
algorithms, which are implemented as loadable kernel modules.
Rename the --linux-congestion long option to --congestion (retaining
the old option as a deprecated synonym).
not including it.
To fix this required us to change config.h to iperf_config.h (to
avoid potential filename collisions with this generic name). Then
iperf.h could include this.
Adjust the existing header file inclusions to track this, and also
canonicalize their inclusion to be at the top of *.c files.
As with several other recent commits, don't check explicitly for an
OS platform, but rather detect the various API bits that are used
to implement CPU affinity setting.
We check at configure-time to see if IPV6_FLOWLABEL_MGR is defined
in <linux/in.6>, if it is we set a HAVE_FLOWLABEL CPP symbol to
turn on conditional compilation of the support for this feature.
Rather than checking for anything Linux-specific at configure-time,
see if TCP_CONGESTION is defined in <netinet/tcp.h> and if so define
a CPP variable HAVE_TCP_CONGESTION, which we then use to enable
conditional compilation of the code for this feature.
Rather than doing checks for platforms that we believe support SCTP,
instead look for an indication (notably the presence of <netinet/sctp.h>)
that it's supported. This makes the conditionals for SCTP more obvious.
In addition, it opens up the possibility that SCTP might work on some
new OS that's not FreeBSD or Linux.
This change may force some additional build-time requirements on Linux,
such as lksctp-tools-devel on CentOS / Fedora or libsctp-dev on
Ubuntu.
Committing this first cut for review and to enable testing on multiple
platforms. So far this works correctly on Linux (SCTP support) and
MacOS (no SCTP support).
Squashed commit of the following:
commit 23ef0d047fb5396df671be9245f7872153fc299c
Author: Bruce A. Mah <bmah@es.net>
Date: Mon Apr 7 13:35:29 2014 -0700
Add a few API calls to the client-side example program so we can
exercise recently-added JSON-related functionality.
commit 5f8301e8d0380133d533da9b2e39ca4ac522e1c3
Author: Bruce A. Mah <bmah@es.net>
Date: Mon Apr 7 13:16:39 2014 -0700
Revert part of earlier change.
We still want to save the JSON for libiperf consumers that might want it,
but preserve the prior behavior of writing that JSON to stdout. This
maintains (roughly) the behavior of older libiperf, in which libiperf
consumers (such as the iperf3 executable) do not need to explicitly print
the JSON if that's all they're doing with it.
commit 173dcdb05867af00103205bfe39d1b71e18689e9
Author: Bruce A. Mah <bmah@es.net>
Date: Tue Mar 25 13:55:45 2014 -0700
Update manpage for newly-added library calls.
Bump document date while here.
Part of Issue #147.
commit 51a275de9463febc440d41cee9d971fcd381e01c
Author: Bruce A. Mah <bmah@es.net>
Date: Tue Mar 25 13:30:09 2014 -0700
Allow consumers of libiperf3 to get the JSON output for a just-completed test.
This changes the behavior of iperf_json_finish() so that it no longer
outputs JSON output, but saves the rendered output in a NUL-terminated
string buffer. After calling iperf_run_server() or iperf_run_client(),
the client application should check iperf_get_test_json_output() to see
if it returns a non-NULL pointer. If so, there is JSON data available
for it to print or otherwise consume. The buffer is automatically
deallocated when the containing iperf_test structure is deallocated
with iperf_free_test().
Also adds a new API call iperf_get_test_outfile() to find the output
FILE* structure.
Modifies the iperf3 application to use the new API. Users of iperf3
will not notice any functional change.
No effect in "normal" output mode (non-JSON).
iperf_parse_arguments(). Basically we need to initialize the
output stream in the iperf_test structure regardless of whether
iperf_parse_arguments() gets called; some programs (in particular
the programs in the examples/ directory and bwctl) don't do this
(and indeed should not need to).
This problem was introduced in the solution for Issue #119; the fix
needs to be merged to any codeline where fixes for Issue #119 go.
This works for both client and server side (in the case of the server,
either for daemon or non-daemon mode).
Consistifies a few places that were using printf instead of iprintf.
Fixes Issue 119.
This makes SCTP with default parameters work on CentOS 6; formerly
it was just using the TCP default (128KB) and failing with
a "message too long" error. It might be possible to fix this with
some manipulation of other default values, so that TCP and SCTP
can use the same default message size, but I haven't figure out
what this would be.
This ties up one loose end from Issue 131.
Note this option only has a long option flag; we're running out of
letters for short options.
Based heavily on a patch submitted in Issue 131 (SCTP support for
iperf); I added support for FreeBSD and did some other packaging and
documentation improvements.
We probably shouldn't tie SCTP support to looking specifically for
Linux or FreeBSD; we probably leave support enabled all the time if
possible, possibly with some configure-time checks.
We were computing and printing this in JSON output mode anyway; this
change just exposes this quantity in a human-friendly manner (better
than the first attempt at this) when doing normal output.
Resolves Issue 99 (Additional TCP_INFO items).
mapped_v4_to_regular_v4() committed the sin of doing strcpy(3) on
overlapping buffers. This caused an abort on MacOS X 10.9. Fix this
to use memcpy(3) instead, which handles overlapping buffers correctly.
Issue: 135 (Crash on OS X when using IP address)
Apparently older kernels don't support TCP_CONGESTION, so we can't
just test for defined(linux) to know if we can use this sockopt or not.
This change unbreaks the build on (notably) CentOS 5.
Mostly this change consists of adding FreeBSD-specific code to handle
this feature. The concepts and system calls are very similar to what's
already done for Linux. One difference is that on FreeBSD, the CPU
affinity mask is saved before -A processing and restored afterwards.
This causes a slight change to the function signatures for
iperf_setaffinity() and iperf_clearaffinity() (these functions
however are not documented as a part of the libiperf3 API).
Slightly improve some of the documentation for the -A command line
option, to hopefully stave off some of the questions about this
feature.
Mostly based on a submitted patch.
Issue: 128 (better error message for CPU affinity failure)
Submitted by: Susant Sahani <ssahani@redhat.com>
When the client process gets interrupted, both the client and server
dump out accumulated interval statistics, as well as a partial set of
summary statistics (basically each side dumps what it has, but without
the exchange of information that usually happens at the end of a
normal run).
If the server process gets interrupted, the server dumps out its
accumulated interval and summary statistics as above. The client does
this as well in the -R case, but exits with a "Broken pipe" in the non
-R case (this behavior was present all along; it was not introduced in
this change). More investigation will be needed to understand the
client behavior.
Bump copyright dates in a few places.
Issue: 132 (signal handler for API calls)
Discussed with: aaron@internet2.edu
