First, realize that we've been setting the congestion control (CC)
algorithm unnecessarily; rather than doing it for all listening or
connecting sockets, do it just for those sockets that are being used
for TCP test streams.
Record the CC algorithm in use (this handles the case where a CC algorithm
hasn't been specified), and have the client and server exchange this
information.
Report the CC algorithms that were used (note that it's theoretically
possible for the two ends of the test to be using different algorithms,
if no algorithm was explicitly specified and the two end hosts have
different defaults, or if one side allows setting the CC algorithm and
the other doesn't).
Committing to a branch to make it easier to test this code on a
wider combination of systems.
commit 2dc03630a736be2ae9f64823aabb5776e7074c2a
Merge: 61e325c 0da552c
Author: Bruce A. Mah <bmah@es.net>
Date: Thu May 26 09:40:58 2016 -0700
Merge branch 'master' into issue-325
commit 61e325c5d0a4e7a9823221ce507db0f478fc98b5
Merge: 227992f ccbcee6
Author: Bruce A. Mah <bmah@es.net>
Date: Thu May 26 11:09:54 2016 -0400
Merge branch 'issue-325' of github.com:esnet/iperf into issue-325
Conflicts:
src/iperf3.1
commit 227992f366e7f4895b6762011576ba22a42a752e
Author: Bruce A. Mah <bmah@es.net>
Date: Thu May 26 11:07:01 2016 -0400
Don't set SO_MAX_PACING_RATE if the rate is 0. Also tweak some help text.
Towards #325, in response to feedback from @bltierney.
commit ccbcee6366d50ec632fc00eb11fde8a886f8febe
Author: Bruce A. Mah <bmah@es.net>
Date: Tue May 24 09:19:41 2016 -0700
Fix manpage formatting for consistency.
commit 90ac5a9ce09bd746ca5f943a8226ab864da3ebf8
Author: Bruce A. Mah <bmah@es.net>
Date: Tue May 24 12:14:16 2016 -0400
Add some documentation for fair-queueing per-socket pacing.
For #325.
commit 5571059870f7aefefb574816de70b6406848888f
Author: Bruce A. Mah <bmah@es.net>
Date: Tue May 24 11:55:44 2016 -0400
Change the fair-queueing socket pacing logic in response to feedback.
By default, on platforms where per-socket pacing is available, it
will be used. If not available, iperf3 will fall back to application-
level pacing.
The --no-fq-socket-pacing option can be used to forcibly disable
fair-queueing per-socket pacing. (The earlier --socket-pacing option
has been removed.)
Tested on CentOS 7, more testing on other platforms is required to
be sure it didn't break the old application-level pacing behavior.
For #325.
commit 3e3f506fe9f375a5771c9e3ddfe8677c1a7146e7
Merge: 50a379e 3b23112
Author: Bruce A. Mah <bmah@es.net>
Date: Tue May 24 09:54:39 2016 -0400
Merge branch 'master' into issue-325
commit 50a379eddfa89d1313d2aeeb62a6fbc82f00ea17
Author: Bruce A. Mah <bmah@es.net>
Date: Sat Apr 16 02:55:42 2016 -0400
Regen.
commit 200d3fe3917b3d298bdf52a0bde32c47cf2727b0
Author: Bruce A. Mah <bmah@es.net>
Date: Sat Apr 16 02:41:32 2016 -0400
Checkpoint for initial work on #325 to add socket pacing.
This works only on Linux and depends on the availability of
the SO_MAX_PACING_RATE socket option and the fq queue discipline.
Use --socket-pacing to use SO_MAX_PACING_RATE instead of the
default iperf3 user-level rate limiting; in either case, the
--bandwidth parameter controls the desired rate.
Lightly tested with both --tcp and --udp, normal and --reverse.
Real testing requires analysis of packet timestamps between
multiple hosts.
When we do TCP tests and specify the socket buffer size, MSS, or
TCP no delay option, the iperf3 server destroys the socket it was
using to listen for the control connection and opens up a new
listening socket for the test's data connections. This is (I think)
to make sure that the data connections all have the correct TCP
parameters.
When we re-create the listening socket, we also need to go through
the binding logic again (with all of the address family selectiion,
etc. goop). The bug fixes that were a part of issue #193 need to
be ported to this code as well.
This problem only affects TCP tests, because for other protocols,
the listening socket for data cannot be the same listening sock as
for the control connection.
While here, add some comments so anybody trying to understand this
code will have an easier time.
Based on patch by: @i2aaron
setsockopt(3) returns an error if passing 0 to this option (which
we do if no address family is specified when we bind to the wildcard
address, say by invoking "iperf3 -s" with no other options). This
is because OpenBSD explicitly does not support IPv4-mapped addresses,
so even though the IPV6_V6ONLY socket options exists, it only works
with a non-zero argument.
Fixes#196.
Should fix#177, in which compilation failed on older Solaris systems
that didn't have it. This is a different approach than a patch
suggested in that issue.
Weakly regression-tested on other platforms (test this by specifying
-6, -4, or neither to the server when binding to the wildcard address,
and seeing if a client can connect with various of -6, -4, or neither).
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.
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.
The bug and solution are very similar to Issue 126 (fixed in
d7e0c1445c0a). Basically a setsockopt(IPV6_V6ONLY) call had a bogus
level argument, but we never checked the return value so we never
noticed this.
As with the prior issue, the fix is to unbreak the setsockopt() call,
and add some error checking to detect future breakage.
This bug was on a codepath that only got called if non-default values
were set for the socket buffer size, the MSS, or the NODELAY parameter.
It might have affected some FreeBSD tests, but really only got noticed
when debugging some other code that was (probably) cut-and-pasted
from this code.
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.
Also remove a couple of places where we were saving and restoring errno
where we didn't need to.
Submitted by: Susant Sahani <ssahani@redhat.com>
Issue: 121 (TCP congestion control algorithm support for client)
This functionality uses some setsockopt(2) calls that unfortunately
don't seem to have an analog on other platforms.
Slightly tweaked version of a patch that was...
Submitted by: ssahani@redhat.com
Issue: 40 (Option for setting Flow Label field in IPv6
header)
A couple more sizeof issues found and fixed. One of them is
actually another protocol change, but due to a fortuitous accident
it should remain compatible with older versions.
Detailed explanation: When a client attempts to connect to a server that
is already busy, the server is supposed to return ACCESS_DENIED as a
state value. It was doing so, but was writing it as an int, even though
state values are supposed to be signed chars. The client read the value
correctly as a signed char, getting one byte and throwing away the rest.
So why did this ever work? Because ACCESS_DENIED is the value -1, and
any byte of an int -1 equals a signed char -1. If ACCESS_DENIED had been
any other value, this would have been an opvious bug and would have long
since been fixed. As is, it stuck around working by accident until now.
The user-visible parts are commented out or return a "not implemented
yet" error message. The other parts are harmless.
We'll come back to this once we figure out how exactly one sets
the Flow Label.
one is the new -Z flag.
- Fixed potential bug in net.c's Nread and Nwrite routines. If they
had ever needed to loop they would have read/written the wrong address,
due to incorrect pointer arithmetic - sizeof(void) is not 1. Fix
was to change the type of the buffer pointer to char*, which also
meant adding casts to some callers.
- Better checking for conflicts between command-line flags - now they
should no longer be order-dependent.
- Added a new -Z / --zerocopy flag, to use a "zero copy" method of
sending data, such as sendfile(2) instead of the usual write(2).
- Renumbered error enum to make inserting new ones easier.
