1
1
iperf3/src/iperf_udp.c

591 строка
16 KiB
C
Исходник Обычный вид История

2009-11-02 22:43:19 +00:00
/*
* iperf, Copyright (c) 2014-2020, The Regents of the University of
* California, through Lawrence Berkeley National Laboratory (subject
* to receipt of any required approvals from the U.S. Dept. of
* Energy). All rights reserved.
*
* If you have questions about your rights to use or distribute this
* software, please contact Berkeley Lab's Technology Transfer
* Department at TTD@lbl.gov.
*
* NOTICE. This software is owned by the U.S. Department of Energy.
* As such, the U.S. Government has been granted for itself and others
* acting on its behalf a paid-up, nonexclusive, irrevocable,
* worldwide license in the Software to reproduce, prepare derivative
* works, and perform publicly and display publicly. Beginning five
* (5) years after the date permission to assert copyright is obtained
* from the U.S. Department of Energy, and subject to any subsequent
* five (5) year renewals, the U.S. Government is granted for itself
* and others acting on its behalf a paid-up, nonexclusive,
* irrevocable, worldwide license in the Software to reproduce,
* prepare derivative works, distribute copies to the public, perform
* publicly and display publicly, and to permit others to do so.
*
* This code is distributed under a BSD style license, see the LICENSE
* file for complete information.
2009-11-02 22:43:19 +00:00
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <unistd.h>
#include <assert.h>
#include <arpa/inet.h>
2009-11-02 22:43:19 +00:00
#include <sys/socket.h>
#include <sys/types.h>
#include <netinet/in.h>
#ifdef HAVE_STDINT_H
2009-11-02 22:43:19 +00:00
#include <stdint.h>
#endif
2009-11-02 22:43:19 +00:00
#include <sys/time.h>
#include <sys/select.h>
2009-11-02 22:43:19 +00:00
#include "iperf.h"
#include "iperf_api.h"
#include "iperf_util.h"
2009-11-02 22:43:19 +00:00
#include "iperf_udp.h"
#include "timer.h"
#include "net.h"
#include "cjson.h"
#include "portable_endian.h"
2009-11-02 22:43:19 +00:00
#if defined(HAVE_INTTYPES_H)
# include <inttypes.h>
#else
# ifndef PRIu64
# if sizeof(long) == 8
# define PRIu64 "lu"
# else
# define PRIu64 "llu"
# endif
# endif
#endif
/* iperf_udp_recv
2009-11-02 22:43:19 +00:00
*
* receives the data for UDP
2009-11-02 22:43:19 +00:00
*/
int
iperf_udp_recv(struct iperf_stream *sp)
2009-11-02 22:43:19 +00:00
{
uint32_t sec, usec;
uint64_t pcount;
int r;
2009-11-02 22:43:19 +00:00
int size = sp->settings->blksize;
int first_packet = 0;
2009-11-02 22:43:19 +00:00
double transit = 0, d = 0;
2018-05-16 23:49:45 +02:00
struct iperf_time sent_time, arrival_time, temp_time;
r = Nread(sp->socket, sp->buffer, size, Pudp);
2009-11-02 22:43:19 +00:00
/*
* If we got an error in the read, or if we didn't read anything
* because the underlying read(2) got a EAGAIN, then skip packet
* processing.
*/
if (r <= 0)
return r;
/* Only count bytes received while we're in the correct state. */
if (sp->test->state == TEST_RUNNING) {
/*
* For jitter computation below, it's important to know if this
* packet is the first packet received.
*/
if (sp->result->bytes_received == 0) {
first_packet = 1;
}
sp->result->bytes_received += r;
sp->result->bytes_received_this_interval += r;
/* Dig the various counters out of the incoming UDP packet */
if (sp->test->udp_counters_64bit) {
memcpy(&sec, sp->buffer, sizeof(sec));
memcpy(&usec, sp->buffer+4, sizeof(usec));
memcpy(&pcount, sp->buffer+8, sizeof(pcount));
sec = ntohl(sec);
usec = ntohl(usec);
pcount = be64toh(pcount);
2018-05-16 23:49:45 +02:00
sent_time.secs = sec;
sent_time.usecs = usec;
}
else {
uint32_t pc;
memcpy(&sec, sp->buffer, sizeof(sec));
memcpy(&usec, sp->buffer+4, sizeof(usec));
memcpy(&pc, sp->buffer+8, sizeof(pc));
sec = ntohl(sec);
usec = ntohl(usec);
pcount = ntohl(pc);
2018-05-16 23:49:45 +02:00
sent_time.secs = sec;
sent_time.usecs = usec;
}
if (sp->test->debug)
fprintf(stderr, "pcount %" PRIu64 " packet_count %d\n", pcount, sp->packet_count);
/*
* Try to handle out of order packets. The way we do this
* uses a constant amount of storage but might not be
* correct in all cases. In particular we seem to have the
* assumption that packets can't be duplicated in the network,
* because duplicate packets will possibly cause some problems here.
*
* First figure out if the sequence numbers are going forward.
* Note that pcount is the sequence number read from the packet,
* and sp->packet_count is the highest sequence number seen so
* far (so we're expecting to see the packet with sequence number
* sp->packet_count + 1 arrive next).
*/
if (pcount >= sp->packet_count + 1) {
/* Forward, but is there a gap in sequence numbers? */
if (pcount > sp->packet_count + 1) {
/* There's a gap so count that as a loss. */
sp->cnt_error += (pcount - 1) - sp->packet_count;
}
/* Update the highest sequence number seen so far. */
sp->packet_count = pcount;
} else {
2021-09-03 13:24:55 +00:00
/*
* Sequence number went backward (or was stationary?!?).
* This counts as an out-of-order packet.
*/
sp->outoforder_packets++;
/*
* If we have lost packets, then the fact that we are now
* seeing an out-of-order packet offsets a prior sequence
* number gap that was counted as a loss. So we can take
* away a loss.
*/
if (sp->cnt_error > 0)
sp->cnt_error--;
2021-09-03 13:24:55 +00:00
/* Log the out-of-order packet */
2021-09-03 13:24:55 +00:00
if (sp->test->debug)
fprintf(stderr, "OUT OF ORDER - incoming packet sequence %" PRIu64 " but expected sequence %d on stream %d", pcount, sp->packet_count + 1, sp->socket);
}
/*
* jitter measurement
*
* This computation is based on RFC 1889 (specifically
* sections 6.3.1 and A.8).
*
* Note that synchronized clocks are not required since
* the source packet delta times are known. Also this
* computation does not require knowing the round-trip
* time.
*/
2018-05-16 23:49:45 +02:00
iperf_time_now(&arrival_time);
2018-05-16 23:49:45 +02:00
iperf_time_diff(&arrival_time, &sent_time, &temp_time);
transit = iperf_time_in_secs(&temp_time);
/* Hack to handle the first packet by initializing prev_transit. */
if (first_packet)
sp->prev_transit = transit;
d = transit - sp->prev_transit;
if (d < 0)
d = -d;
sp->prev_transit = transit;
sp->jitter += (d - sp->jitter) / 16.0;
}
else {
if (sp->test->debug)
printf("Late receive, state = %d\n", sp->test->state);
2009-11-02 22:43:19 +00:00
}
return r;
}
/* iperf_udp_send
*
* sends the data for UDP
*/
2009-11-02 22:43:19 +00:00
int
iperf_udp_send(struct iperf_stream *sp)
2009-11-02 22:43:19 +00:00
{
int r;
int size = sp->settings->blksize;
2018-05-16 23:49:45 +02:00
struct iperf_time before;
2018-05-16 23:49:45 +02:00
iperf_time_now(&before);
++sp->packet_count;
if (sp->test->udp_counters_64bit) {
uint32_t sec, usec;
uint64_t pcount;
2018-05-16 23:49:45 +02:00
sec = htonl(before.secs);
usec = htonl(before.usecs);
pcount = htobe64(sp->packet_count);
2021-09-03 13:24:55 +00:00
memcpy(sp->buffer, &sec, sizeof(sec));
memcpy(sp->buffer+4, &usec, sizeof(usec));
memcpy(sp->buffer+8, &pcount, sizeof(pcount));
2021-09-03 13:24:55 +00:00
}
else {
uint32_t sec, usec, pcount;
2018-05-16 23:49:45 +02:00
sec = htonl(before.secs);
usec = htonl(before.usecs);
pcount = htonl(sp->packet_count);
2021-09-03 13:24:55 +00:00
memcpy(sp->buffer, &sec, sizeof(sec));
memcpy(sp->buffer+4, &usec, sizeof(usec));
memcpy(sp->buffer+8, &pcount, sizeof(pcount));
2021-09-03 13:24:55 +00:00
}
r = Nwrite(sp->socket, sp->buffer, size, Pudp);
if (r < 0)
return r;
sp->result->bytes_sent += r;
sp->result->bytes_sent_this_interval += r;
if (sp->test->debug)
printf("sent %d bytes of %d, total %" PRIu64 "\n", r, sp->settings->blksize, sp->result->bytes_sent);
return r;
2009-11-02 22:43:19 +00:00
}
/**************************************************************************/
/*
* The following functions all have to do with managing UDP data sockets.
* UDP of course is connectionless, so there isn't really a concept of
* setting up a connection, although connect(2) can (and is) used to
* bind the remote end of sockets. We need to simulate some of the
* connection management that is built-in to TCP so that each side of the
* connection knows about each other before the real data transfers begin.
*/
/*
Issue 496 (#498) * Dynamically determine an appropriate default UDP send size. We use the TCP MSS for the control connection as the default UDP sending length, if the --length parameter is not specified for a UDP test. This computation replaces the former hard-coded 8K default, which was way too large for non-jumbo-frame Ethernet networks. The concept for this solution was adapted from nuttcp. The iperf3 implementation is pretty easy since we already were getting the MSS for the control connection anyway (although we needed to get it slightly earlier in the setup process to be useful). Towards issue #496. While here, s/int/socklen_t/ in one place to fix a compile warning, and bump a few copyright dates. * Warn if doing a UDP test and the socket buffer isn't big enough. This is surprisingly an issue on FreeBSD and macOS, where the MTU over the loopback interface is actually larger than the default UDP socket buffer size. In these cases, doing a UDP test over the loopback interface (with the new UDP defaults) will fail unless a smaller --length or a larger --window size is set explicitly. Linux has larger UDP socket buffers by default (much larger than the largest possible MTU), but even in the case that the socket buffers are too small to hold an MTU-sized send, the kernel seems to do the send correctly anyway. Still working towards a good solution for issue #496. * Further refinement on UDP buffer size settings. If the default buffer size on a UDP test can't hold a packet, then increase the buffer size to be large enough to hold one packet payload. (If the buffer size was explicitly set, but too small to hold a packet payload, then warn but don't change the buffer size.) Minor code refactoring to...factor out some common code into a new iperf_udp_buffercheck() function. Still working towards issue #496.
2017-01-10 09:13:57 -08:00
* Set and verify socket buffer sizes.
* Return 0 if no error, -1 if an error, +1 if socket buffers are
* potentially too small to hold a message.
2009-11-02 22:43:19 +00:00
*/
int
Issue 496 (#498) * Dynamically determine an appropriate default UDP send size. We use the TCP MSS for the control connection as the default UDP sending length, if the --length parameter is not specified for a UDP test. This computation replaces the former hard-coded 8K default, which was way too large for non-jumbo-frame Ethernet networks. The concept for this solution was adapted from nuttcp. The iperf3 implementation is pretty easy since we already were getting the MSS for the control connection anyway (although we needed to get it slightly earlier in the setup process to be useful). Towards issue #496. While here, s/int/socklen_t/ in one place to fix a compile warning, and bump a few copyright dates. * Warn if doing a UDP test and the socket buffer isn't big enough. This is surprisingly an issue on FreeBSD and macOS, where the MTU over the loopback interface is actually larger than the default UDP socket buffer size. In these cases, doing a UDP test over the loopback interface (with the new UDP defaults) will fail unless a smaller --length or a larger --window size is set explicitly. Linux has larger UDP socket buffers by default (much larger than the largest possible MTU), but even in the case that the socket buffers are too small to hold an MTU-sized send, the kernel seems to do the send correctly anyway. Still working towards a good solution for issue #496. * Further refinement on UDP buffer size settings. If the default buffer size on a UDP test can't hold a packet, then increase the buffer size to be large enough to hold one packet payload. (If the buffer size was explicitly set, but too small to hold a packet payload, then warn but don't change the buffer size.) Minor code refactoring to...factor out some common code into a new iperf_udp_buffercheck() function. Still working towards issue #496.
2017-01-10 09:13:57 -08:00
iperf_udp_buffercheck(struct iperf_test *test, int s)
2009-11-02 22:43:19 +00:00
{
Issue 496 (#498) * Dynamically determine an appropriate default UDP send size. We use the TCP MSS for the control connection as the default UDP sending length, if the --length parameter is not specified for a UDP test. This computation replaces the former hard-coded 8K default, which was way too large for non-jumbo-frame Ethernet networks. The concept for this solution was adapted from nuttcp. The iperf3 implementation is pretty easy since we already were getting the MSS for the control connection anyway (although we needed to get it slightly earlier in the setup process to be useful). Towards issue #496. While here, s/int/socklen_t/ in one place to fix a compile warning, and bump a few copyright dates. * Warn if doing a UDP test and the socket buffer isn't big enough. This is surprisingly an issue on FreeBSD and macOS, where the MTU over the loopback interface is actually larger than the default UDP socket buffer size. In these cases, doing a UDP test over the loopback interface (with the new UDP defaults) will fail unless a smaller --length or a larger --window size is set explicitly. Linux has larger UDP socket buffers by default (much larger than the largest possible MTU), but even in the case that the socket buffers are too small to hold an MTU-sized send, the kernel seems to do the send correctly anyway. Still working towards a good solution for issue #496. * Further refinement on UDP buffer size settings. If the default buffer size on a UDP test can't hold a packet, then increase the buffer size to be large enough to hold one packet payload. (If the buffer size was explicitly set, but too small to hold a packet payload, then warn but don't change the buffer size.) Minor code refactoring to...factor out some common code into a new iperf_udp_buffercheck() function. Still working towards issue #496.
2017-01-10 09:13:57 -08:00
int rc = 0;
int sndbuf_actual, rcvbuf_actual;
2009-11-02 22:43:19 +00:00
/*
* Set socket buffer size if requested. Do this for both sending and
* receiving so that we can cover both normal and --reverse operation.
*/
int opt;
socklen_t optlen;
2021-09-03 13:24:55 +00:00
if ((opt = test->settings->socket_bufsize)) {
if (setsockopt(s, SOL_SOCKET, SO_RCVBUF, &opt, sizeof(opt)) < 0) {
i_errno = IESETBUF;
return -1;
}
if (setsockopt(s, SOL_SOCKET, SO_SNDBUF, &opt, sizeof(opt)) < 0) {
i_errno = IESETBUF;
return -1;
}
}
/* Read back and verify the sender socket buffer size */
optlen = sizeof(sndbuf_actual);
if (getsockopt(s, SOL_SOCKET, SO_SNDBUF, &sndbuf_actual, &optlen) < 0) {
i_errno = IESETBUF;
return -1;
}
if (test->debug) {
printf("SNDBUF is %u, expecting %u\n", sndbuf_actual, test->settings->socket_bufsize);
}
if (test->settings->socket_bufsize && test->settings->socket_bufsize > sndbuf_actual) {
i_errno = IESETBUF2;
return -1;
}
if (test->settings->blksize > sndbuf_actual) {
Issue 496 (#498) * Dynamically determine an appropriate default UDP send size. We use the TCP MSS for the control connection as the default UDP sending length, if the --length parameter is not specified for a UDP test. This computation replaces the former hard-coded 8K default, which was way too large for non-jumbo-frame Ethernet networks. The concept for this solution was adapted from nuttcp. The iperf3 implementation is pretty easy since we already were getting the MSS for the control connection anyway (although we needed to get it slightly earlier in the setup process to be useful). Towards issue #496. While here, s/int/socklen_t/ in one place to fix a compile warning, and bump a few copyright dates. * Warn if doing a UDP test and the socket buffer isn't big enough. This is surprisingly an issue on FreeBSD and macOS, where the MTU over the loopback interface is actually larger than the default UDP socket buffer size. In these cases, doing a UDP test over the loopback interface (with the new UDP defaults) will fail unless a smaller --length or a larger --window size is set explicitly. Linux has larger UDP socket buffers by default (much larger than the largest possible MTU), but even in the case that the socket buffers are too small to hold an MTU-sized send, the kernel seems to do the send correctly anyway. Still working towards a good solution for issue #496. * Further refinement on UDP buffer size settings. If the default buffer size on a UDP test can't hold a packet, then increase the buffer size to be large enough to hold one packet payload. (If the buffer size was explicitly set, but too small to hold a packet payload, then warn but don't change the buffer size.) Minor code refactoring to...factor out some common code into a new iperf_udp_buffercheck() function. Still working towards issue #496.
2017-01-10 09:13:57 -08:00
char str[80];
snprintf(str, sizeof(str),
"Block size %d > sending socket buffer size %d",
test->settings->blksize, sndbuf_actual);
Issue 496 (#498) * Dynamically determine an appropriate default UDP send size. We use the TCP MSS for the control connection as the default UDP sending length, if the --length parameter is not specified for a UDP test. This computation replaces the former hard-coded 8K default, which was way too large for non-jumbo-frame Ethernet networks. The concept for this solution was adapted from nuttcp. The iperf3 implementation is pretty easy since we already were getting the MSS for the control connection anyway (although we needed to get it slightly earlier in the setup process to be useful). Towards issue #496. While here, s/int/socklen_t/ in one place to fix a compile warning, and bump a few copyright dates. * Warn if doing a UDP test and the socket buffer isn't big enough. This is surprisingly an issue on FreeBSD and macOS, where the MTU over the loopback interface is actually larger than the default UDP socket buffer size. In these cases, doing a UDP test over the loopback interface (with the new UDP defaults) will fail unless a smaller --length or a larger --window size is set explicitly. Linux has larger UDP socket buffers by default (much larger than the largest possible MTU), but even in the case that the socket buffers are too small to hold an MTU-sized send, the kernel seems to do the send correctly anyway. Still working towards a good solution for issue #496. * Further refinement on UDP buffer size settings. If the default buffer size on a UDP test can't hold a packet, then increase the buffer size to be large enough to hold one packet payload. (If the buffer size was explicitly set, but too small to hold a packet payload, then warn but don't change the buffer size.) Minor code refactoring to...factor out some common code into a new iperf_udp_buffercheck() function. Still working towards issue #496.
2017-01-10 09:13:57 -08:00
warning(str);
rc = 1;
}
/* Read back and verify the receiver socket buffer size */
optlen = sizeof(rcvbuf_actual);
if (getsockopt(s, SOL_SOCKET, SO_RCVBUF, &rcvbuf_actual, &optlen) < 0) {
i_errno = IESETBUF;
return -1;
}
if (test->debug) {
printf("RCVBUF is %u, expecting %u\n", rcvbuf_actual, test->settings->socket_bufsize);
}
if (test->settings->socket_bufsize && test->settings->socket_bufsize > rcvbuf_actual) {
i_errno = IESETBUF2;
return -1;
}
if (test->settings->blksize > rcvbuf_actual) {
Issue 496 (#498) * Dynamically determine an appropriate default UDP send size. We use the TCP MSS for the control connection as the default UDP sending length, if the --length parameter is not specified for a UDP test. This computation replaces the former hard-coded 8K default, which was way too large for non-jumbo-frame Ethernet networks. The concept for this solution was adapted from nuttcp. The iperf3 implementation is pretty easy since we already were getting the MSS for the control connection anyway (although we needed to get it slightly earlier in the setup process to be useful). Towards issue #496. While here, s/int/socklen_t/ in one place to fix a compile warning, and bump a few copyright dates. * Warn if doing a UDP test and the socket buffer isn't big enough. This is surprisingly an issue on FreeBSD and macOS, where the MTU over the loopback interface is actually larger than the default UDP socket buffer size. In these cases, doing a UDP test over the loopback interface (with the new UDP defaults) will fail unless a smaller --length or a larger --window size is set explicitly. Linux has larger UDP socket buffers by default (much larger than the largest possible MTU), but even in the case that the socket buffers are too small to hold an MTU-sized send, the kernel seems to do the send correctly anyway. Still working towards a good solution for issue #496. * Further refinement on UDP buffer size settings. If the default buffer size on a UDP test can't hold a packet, then increase the buffer size to be large enough to hold one packet payload. (If the buffer size was explicitly set, but too small to hold a packet payload, then warn but don't change the buffer size.) Minor code refactoring to...factor out some common code into a new iperf_udp_buffercheck() function. Still working towards issue #496.
2017-01-10 09:13:57 -08:00
char str[80];
snprintf(str, sizeof(str),
"Block size %d > receiving socket buffer size %d",
test->settings->blksize, rcvbuf_actual);
Issue 496 (#498) * Dynamically determine an appropriate default UDP send size. We use the TCP MSS for the control connection as the default UDP sending length, if the --length parameter is not specified for a UDP test. This computation replaces the former hard-coded 8K default, which was way too large for non-jumbo-frame Ethernet networks. The concept for this solution was adapted from nuttcp. The iperf3 implementation is pretty easy since we already were getting the MSS for the control connection anyway (although we needed to get it slightly earlier in the setup process to be useful). Towards issue #496. While here, s/int/socklen_t/ in one place to fix a compile warning, and bump a few copyright dates. * Warn if doing a UDP test and the socket buffer isn't big enough. This is surprisingly an issue on FreeBSD and macOS, where the MTU over the loopback interface is actually larger than the default UDP socket buffer size. In these cases, doing a UDP test over the loopback interface (with the new UDP defaults) will fail unless a smaller --length or a larger --window size is set explicitly. Linux has larger UDP socket buffers by default (much larger than the largest possible MTU), but even in the case that the socket buffers are too small to hold an MTU-sized send, the kernel seems to do the send correctly anyway. Still working towards a good solution for issue #496. * Further refinement on UDP buffer size settings. If the default buffer size on a UDP test can't hold a packet, then increase the buffer size to be large enough to hold one packet payload. (If the buffer size was explicitly set, but too small to hold a packet payload, then warn but don't change the buffer size.) Minor code refactoring to...factor out some common code into a new iperf_udp_buffercheck() function. Still working towards issue #496.
2017-01-10 09:13:57 -08:00
warning(str);
rc = 1;
}
if (test->json_output) {
cJSON_AddNumberToObject(test->json_start, "sock_bufsize", test->settings->socket_bufsize);
cJSON_AddNumberToObject(test->json_start, "sndbuf_actual", sndbuf_actual);
cJSON_AddNumberToObject(test->json_start, "rcvbuf_actual", rcvbuf_actual);
}
Issue 496 (#498) * Dynamically determine an appropriate default UDP send size. We use the TCP MSS for the control connection as the default UDP sending length, if the --length parameter is not specified for a UDP test. This computation replaces the former hard-coded 8K default, which was way too large for non-jumbo-frame Ethernet networks. The concept for this solution was adapted from nuttcp. The iperf3 implementation is pretty easy since we already were getting the MSS for the control connection anyway (although we needed to get it slightly earlier in the setup process to be useful). Towards issue #496. While here, s/int/socklen_t/ in one place to fix a compile warning, and bump a few copyright dates. * Warn if doing a UDP test and the socket buffer isn't big enough. This is surprisingly an issue on FreeBSD and macOS, where the MTU over the loopback interface is actually larger than the default UDP socket buffer size. In these cases, doing a UDP test over the loopback interface (with the new UDP defaults) will fail unless a smaller --length or a larger --window size is set explicitly. Linux has larger UDP socket buffers by default (much larger than the largest possible MTU), but even in the case that the socket buffers are too small to hold an MTU-sized send, the kernel seems to do the send correctly anyway. Still working towards a good solution for issue #496. * Further refinement on UDP buffer size settings. If the default buffer size on a UDP test can't hold a packet, then increase the buffer size to be large enough to hold one packet payload. (If the buffer size was explicitly set, but too small to hold a packet payload, then warn but don't change the buffer size.) Minor code refactoring to...factor out some common code into a new iperf_udp_buffercheck() function. Still working towards issue #496.
2017-01-10 09:13:57 -08:00
return rc;
}
Issue 496 (#498) * Dynamically determine an appropriate default UDP send size. We use the TCP MSS for the control connection as the default UDP sending length, if the --length parameter is not specified for a UDP test. This computation replaces the former hard-coded 8K default, which was way too large for non-jumbo-frame Ethernet networks. The concept for this solution was adapted from nuttcp. The iperf3 implementation is pretty easy since we already were getting the MSS for the control connection anyway (although we needed to get it slightly earlier in the setup process to be useful). Towards issue #496. While here, s/int/socklen_t/ in one place to fix a compile warning, and bump a few copyright dates. * Warn if doing a UDP test and the socket buffer isn't big enough. This is surprisingly an issue on FreeBSD and macOS, where the MTU over the loopback interface is actually larger than the default UDP socket buffer size. In these cases, doing a UDP test over the loopback interface (with the new UDP defaults) will fail unless a smaller --length or a larger --window size is set explicitly. Linux has larger UDP socket buffers by default (much larger than the largest possible MTU), but even in the case that the socket buffers are too small to hold an MTU-sized send, the kernel seems to do the send correctly anyway. Still working towards a good solution for issue #496. * Further refinement on UDP buffer size settings. If the default buffer size on a UDP test can't hold a packet, then increase the buffer size to be large enough to hold one packet payload. (If the buffer size was explicitly set, but too small to hold a packet payload, then warn but don't change the buffer size.) Minor code refactoring to...factor out some common code into a new iperf_udp_buffercheck() function. Still working towards issue #496.
2017-01-10 09:13:57 -08:00
/*
* iperf_udp_accept
*
* Accepts a new UDP "connection"
*/
int
iperf_udp_accept(struct iperf_test *test)
{
struct sockaddr_storage sa_peer;
int buf;
socklen_t len;
int sz, s;
int rc;
/*
* Get the current outstanding socket. This socket will be used to handle
* data transfers and a new "listening" socket will be created.
*/
s = test->prot_listener;
/*
* Grab the UDP packet sent by the client. From that we can extract the
* client's address, and then use that information to bind the remote side
* of the socket to the client.
*/
len = sizeof(sa_peer);
if ((sz = recvfrom(test->prot_listener, &buf, sizeof(buf), 0, (struct sockaddr *) &sa_peer, &len)) < 0) {
i_errno = IESTREAMACCEPT;
return -1;
}
if (connect(s, (struct sockaddr *) &sa_peer, len) < 0) {
i_errno = IESTREAMACCEPT;
return -1;
}
/* Check and set socket buffer sizes */
rc = iperf_udp_buffercheck(test, s);
if (rc < 0)
/* error */
return rc;
/*
* If the socket buffer was too small, but it was the default
* size, then try explicitly setting it to something larger.
*/
if (rc > 0) {
if (test->settings->socket_bufsize == 0) {
int bufsize = test->settings->blksize + UDP_BUFFER_EXTRA;
Issue 496 (#498) * Dynamically determine an appropriate default UDP send size. We use the TCP MSS for the control connection as the default UDP sending length, if the --length parameter is not specified for a UDP test. This computation replaces the former hard-coded 8K default, which was way too large for non-jumbo-frame Ethernet networks. The concept for this solution was adapted from nuttcp. The iperf3 implementation is pretty easy since we already were getting the MSS for the control connection anyway (although we needed to get it slightly earlier in the setup process to be useful). Towards issue #496. While here, s/int/socklen_t/ in one place to fix a compile warning, and bump a few copyright dates. * Warn if doing a UDP test and the socket buffer isn't big enough. This is surprisingly an issue on FreeBSD and macOS, where the MTU over the loopback interface is actually larger than the default UDP socket buffer size. In these cases, doing a UDP test over the loopback interface (with the new UDP defaults) will fail unless a smaller --length or a larger --window size is set explicitly. Linux has larger UDP socket buffers by default (much larger than the largest possible MTU), but even in the case that the socket buffers are too small to hold an MTU-sized send, the kernel seems to do the send correctly anyway. Still working towards a good solution for issue #496. * Further refinement on UDP buffer size settings. If the default buffer size on a UDP test can't hold a packet, then increase the buffer size to be large enough to hold one packet payload. (If the buffer size was explicitly set, but too small to hold a packet payload, then warn but don't change the buffer size.) Minor code refactoring to...factor out some common code into a new iperf_udp_buffercheck() function. Still working towards issue #496.
2017-01-10 09:13:57 -08:00
printf("Increasing socket buffer size to %d\n",
bufsize);
test->settings->socket_bufsize = bufsize;
Issue 496 (#498) * Dynamically determine an appropriate default UDP send size. We use the TCP MSS for the control connection as the default UDP sending length, if the --length parameter is not specified for a UDP test. This computation replaces the former hard-coded 8K default, which was way too large for non-jumbo-frame Ethernet networks. The concept for this solution was adapted from nuttcp. The iperf3 implementation is pretty easy since we already were getting the MSS for the control connection anyway (although we needed to get it slightly earlier in the setup process to be useful). Towards issue #496. While here, s/int/socklen_t/ in one place to fix a compile warning, and bump a few copyright dates. * Warn if doing a UDP test and the socket buffer isn't big enough. This is surprisingly an issue on FreeBSD and macOS, where the MTU over the loopback interface is actually larger than the default UDP socket buffer size. In these cases, doing a UDP test over the loopback interface (with the new UDP defaults) will fail unless a smaller --length or a larger --window size is set explicitly. Linux has larger UDP socket buffers by default (much larger than the largest possible MTU), but even in the case that the socket buffers are too small to hold an MTU-sized send, the kernel seems to do the send correctly anyway. Still working towards a good solution for issue #496. * Further refinement on UDP buffer size settings. If the default buffer size on a UDP test can't hold a packet, then increase the buffer size to be large enough to hold one packet payload. (If the buffer size was explicitly set, but too small to hold a packet payload, then warn but don't change the buffer size.) Minor code refactoring to...factor out some common code into a new iperf_udp_buffercheck() function. Still working towards issue #496.
2017-01-10 09:13:57 -08:00
rc = iperf_udp_buffercheck(test, s);
if (rc < 0)
return rc;
}
}
2021-09-03 13:24:55 +00:00
Squashed commit of the following: 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.
2016-05-26 09:47:48 -07:00
#if defined(HAVE_SO_MAX_PACING_RATE)
/* If socket pacing is specified, try it. */
if (test->settings->fqrate) {
Squashed commit of the following: 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.
2016-05-26 09:47:48 -07:00
/* Convert bits per second to bytes per second */
unsigned int fqrate = test->settings->fqrate / 8;
if (fqrate > 0) {
Squashed commit of the following: 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.
2016-05-26 09:47:48 -07:00
if (test->debug) {
printf("Setting fair-queue socket pacing to %u\n", fqrate);
Squashed commit of the following: 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.
2016-05-26 09:47:48 -07:00
}
if (setsockopt(s, SOL_SOCKET, SO_MAX_PACING_RATE, &fqrate, sizeof(fqrate)) < 0) {
warning("Unable to set socket pacing");
Squashed commit of the following: 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.
2016-05-26 09:47:48 -07:00
}
}
}
#endif /* HAVE_SO_MAX_PACING_RATE */
{
unsigned int rate = test->settings->rate / 8;
if (rate > 0) {
if (test->debug) {
printf("Setting application pacing to %u\n", rate);
}
}
}
Squashed commit of the following: 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.
2016-05-26 09:47:48 -07:00
/*
* Create a new "listening" socket to replace the one we were using before.
*/
test->prot_listener = netannounce(test->settings->domain, Pudp, test->bind_address, test->bind_dev, test->server_port);
if (test->prot_listener < 0) {
i_errno = IESTREAMLISTEN;
return -1;
}
2009-11-02 22:43:19 +00:00
FD_SET(test->prot_listener, &test->read_set);
test->max_fd = (test->max_fd < test->prot_listener) ? test->prot_listener : test->max_fd;
2009-11-02 22:43:19 +00:00
/* Let the client know we're ready "accept" another UDP "stream" */
buf = 987654321; /* any content will work here */
if (write(s, &buf, sizeof(buf)) < 0) {
i_errno = IESTREAMWRITE;
return -1;
2009-11-02 22:43:19 +00:00
}
return s;
}
2009-11-02 22:43:19 +00:00
/*
* iperf_udp_listen
*
* Start up a listener for UDP stream connections. Unlike for TCP,
* there is no listen(2) for UDP. This socket will however accept
* a UDP datagram from a client (indicating the client's presence).
*/
int
iperf_udp_listen(struct iperf_test *test)
{
int s;
if ((s = netannounce(test->settings->domain, Pudp, test->bind_address, test->bind_dev, test->server_port)) < 0) {
i_errno = IESTREAMLISTEN;
return -1;
}
/*
* The caller will put this value into test->prot_listener.
*/
return s;
}
/*
* iperf_udp_connect
*
* "Connect" to a UDP stream listener.
*/
int
iperf_udp_connect(struct iperf_test *test)
{
2013-05-02 15:18:07 -07:00
int s, buf, sz;
#ifdef SO_RCVTIMEO
struct timeval tv;
#endif
Issue 496 (#498) * Dynamically determine an appropriate default UDP send size. We use the TCP MSS for the control connection as the default UDP sending length, if the --length parameter is not specified for a UDP test. This computation replaces the former hard-coded 8K default, which was way too large for non-jumbo-frame Ethernet networks. The concept for this solution was adapted from nuttcp. The iperf3 implementation is pretty easy since we already were getting the MSS for the control connection anyway (although we needed to get it slightly earlier in the setup process to be useful). Towards issue #496. While here, s/int/socklen_t/ in one place to fix a compile warning, and bump a few copyright dates. * Warn if doing a UDP test and the socket buffer isn't big enough. This is surprisingly an issue on FreeBSD and macOS, where the MTU over the loopback interface is actually larger than the default UDP socket buffer size. In these cases, doing a UDP test over the loopback interface (with the new UDP defaults) will fail unless a smaller --length or a larger --window size is set explicitly. Linux has larger UDP socket buffers by default (much larger than the largest possible MTU), but even in the case that the socket buffers are too small to hold an MTU-sized send, the kernel seems to do the send correctly anyway. Still working towards a good solution for issue #496. * Further refinement on UDP buffer size settings. If the default buffer size on a UDP test can't hold a packet, then increase the buffer size to be large enough to hold one packet payload. (If the buffer size was explicitly set, but too small to hold a packet payload, then warn but don't change the buffer size.) Minor code refactoring to...factor out some common code into a new iperf_udp_buffercheck() function. Still working towards issue #496.
2017-01-10 09:13:57 -08:00
int rc;
/* Create and bind our local socket. */
if ((s = netdial(test->settings->domain, Pudp, test->bind_address, test->bind_dev, test->bind_port, test->server_hostname, test->server_port, -1)) < 0) {
i_errno = IESTREAMCONNECT;
return -1;
}
Issue 496 (#498) * Dynamically determine an appropriate default UDP send size. We use the TCP MSS for the control connection as the default UDP sending length, if the --length parameter is not specified for a UDP test. This computation replaces the former hard-coded 8K default, which was way too large for non-jumbo-frame Ethernet networks. The concept for this solution was adapted from nuttcp. The iperf3 implementation is pretty easy since we already were getting the MSS for the control connection anyway (although we needed to get it slightly earlier in the setup process to be useful). Towards issue #496. While here, s/int/socklen_t/ in one place to fix a compile warning, and bump a few copyright dates. * Warn if doing a UDP test and the socket buffer isn't big enough. This is surprisingly an issue on FreeBSD and macOS, where the MTU over the loopback interface is actually larger than the default UDP socket buffer size. In these cases, doing a UDP test over the loopback interface (with the new UDP defaults) will fail unless a smaller --length or a larger --window size is set explicitly. Linux has larger UDP socket buffers by default (much larger than the largest possible MTU), but even in the case that the socket buffers are too small to hold an MTU-sized send, the kernel seems to do the send correctly anyway. Still working towards a good solution for issue #496. * Further refinement on UDP buffer size settings. If the default buffer size on a UDP test can't hold a packet, then increase the buffer size to be large enough to hold one packet payload. (If the buffer size was explicitly set, but too small to hold a packet payload, then warn but don't change the buffer size.) Minor code refactoring to...factor out some common code into a new iperf_udp_buffercheck() function. Still working towards issue #496.
2017-01-10 09:13:57 -08:00
/* Check and set socket buffer sizes */
rc = iperf_udp_buffercheck(test, s);
if (rc < 0)
/* error */
return rc;
/*
Issue 496 (#498) * Dynamically determine an appropriate default UDP send size. We use the TCP MSS for the control connection as the default UDP sending length, if the --length parameter is not specified for a UDP test. This computation replaces the former hard-coded 8K default, which was way too large for non-jumbo-frame Ethernet networks. The concept for this solution was adapted from nuttcp. The iperf3 implementation is pretty easy since we already were getting the MSS for the control connection anyway (although we needed to get it slightly earlier in the setup process to be useful). Towards issue #496. While here, s/int/socklen_t/ in one place to fix a compile warning, and bump a few copyright dates. * Warn if doing a UDP test and the socket buffer isn't big enough. This is surprisingly an issue on FreeBSD and macOS, where the MTU over the loopback interface is actually larger than the default UDP socket buffer size. In these cases, doing a UDP test over the loopback interface (with the new UDP defaults) will fail unless a smaller --length or a larger --window size is set explicitly. Linux has larger UDP socket buffers by default (much larger than the largest possible MTU), but even in the case that the socket buffers are too small to hold an MTU-sized send, the kernel seems to do the send correctly anyway. Still working towards a good solution for issue #496. * Further refinement on UDP buffer size settings. If the default buffer size on a UDP test can't hold a packet, then increase the buffer size to be large enough to hold one packet payload. (If the buffer size was explicitly set, but too small to hold a packet payload, then warn but don't change the buffer size.) Minor code refactoring to...factor out some common code into a new iperf_udp_buffercheck() function. Still working towards issue #496.
2017-01-10 09:13:57 -08:00
* If the socket buffer was too small, but it was the default
* size, then try explicitly setting it to something larger.
*/
Issue 496 (#498) * Dynamically determine an appropriate default UDP send size. We use the TCP MSS for the control connection as the default UDP sending length, if the --length parameter is not specified for a UDP test. This computation replaces the former hard-coded 8K default, which was way too large for non-jumbo-frame Ethernet networks. The concept for this solution was adapted from nuttcp. The iperf3 implementation is pretty easy since we already were getting the MSS for the control connection anyway (although we needed to get it slightly earlier in the setup process to be useful). Towards issue #496. While here, s/int/socklen_t/ in one place to fix a compile warning, and bump a few copyright dates. * Warn if doing a UDP test and the socket buffer isn't big enough. This is surprisingly an issue on FreeBSD and macOS, where the MTU over the loopback interface is actually larger than the default UDP socket buffer size. In these cases, doing a UDP test over the loopback interface (with the new UDP defaults) will fail unless a smaller --length or a larger --window size is set explicitly. Linux has larger UDP socket buffers by default (much larger than the largest possible MTU), but even in the case that the socket buffers are too small to hold an MTU-sized send, the kernel seems to do the send correctly anyway. Still working towards a good solution for issue #496. * Further refinement on UDP buffer size settings. If the default buffer size on a UDP test can't hold a packet, then increase the buffer size to be large enough to hold one packet payload. (If the buffer size was explicitly set, but too small to hold a packet payload, then warn but don't change the buffer size.) Minor code refactoring to...factor out some common code into a new iperf_udp_buffercheck() function. Still working towards issue #496.
2017-01-10 09:13:57 -08:00
if (rc > 0) {
if (test->settings->socket_bufsize == 0) {
int bufsize = test->settings->blksize + UDP_BUFFER_EXTRA;
Issue 496 (#498) * Dynamically determine an appropriate default UDP send size. We use the TCP MSS for the control connection as the default UDP sending length, if the --length parameter is not specified for a UDP test. This computation replaces the former hard-coded 8K default, which was way too large for non-jumbo-frame Ethernet networks. The concept for this solution was adapted from nuttcp. The iperf3 implementation is pretty easy since we already were getting the MSS for the control connection anyway (although we needed to get it slightly earlier in the setup process to be useful). Towards issue #496. While here, s/int/socklen_t/ in one place to fix a compile warning, and bump a few copyright dates. * Warn if doing a UDP test and the socket buffer isn't big enough. This is surprisingly an issue on FreeBSD and macOS, where the MTU over the loopback interface is actually larger than the default UDP socket buffer size. In these cases, doing a UDP test over the loopback interface (with the new UDP defaults) will fail unless a smaller --length or a larger --window size is set explicitly. Linux has larger UDP socket buffers by default (much larger than the largest possible MTU), but even in the case that the socket buffers are too small to hold an MTU-sized send, the kernel seems to do the send correctly anyway. Still working towards a good solution for issue #496. * Further refinement on UDP buffer size settings. If the default buffer size on a UDP test can't hold a packet, then increase the buffer size to be large enough to hold one packet payload. (If the buffer size was explicitly set, but too small to hold a packet payload, then warn but don't change the buffer size.) Minor code refactoring to...factor out some common code into a new iperf_udp_buffercheck() function. Still working towards issue #496.
2017-01-10 09:13:57 -08:00
printf("Increasing socket buffer size to %d\n",
bufsize);
test->settings->socket_bufsize = bufsize;
Issue 496 (#498) * Dynamically determine an appropriate default UDP send size. We use the TCP MSS for the control connection as the default UDP sending length, if the --length parameter is not specified for a UDP test. This computation replaces the former hard-coded 8K default, which was way too large for non-jumbo-frame Ethernet networks. The concept for this solution was adapted from nuttcp. The iperf3 implementation is pretty easy since we already were getting the MSS for the control connection anyway (although we needed to get it slightly earlier in the setup process to be useful). Towards issue #496. While here, s/int/socklen_t/ in one place to fix a compile warning, and bump a few copyright dates. * Warn if doing a UDP test and the socket buffer isn't big enough. This is surprisingly an issue on FreeBSD and macOS, where the MTU over the loopback interface is actually larger than the default UDP socket buffer size. In these cases, doing a UDP test over the loopback interface (with the new UDP defaults) will fail unless a smaller --length or a larger --window size is set explicitly. Linux has larger UDP socket buffers by default (much larger than the largest possible MTU), but even in the case that the socket buffers are too small to hold an MTU-sized send, the kernel seems to do the send correctly anyway. Still working towards a good solution for issue #496. * Further refinement on UDP buffer size settings. If the default buffer size on a UDP test can't hold a packet, then increase the buffer size to be large enough to hold one packet payload. (If the buffer size was explicitly set, but too small to hold a packet payload, then warn but don't change the buffer size.) Minor code refactoring to...factor out some common code into a new iperf_udp_buffercheck() function. Still working towards issue #496.
2017-01-10 09:13:57 -08:00
rc = iperf_udp_buffercheck(test, s);
if (rc < 0)
return rc;
}
}
2021-09-03 13:24:55 +00:00
Squashed commit of the following: 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.
2016-05-26 09:47:48 -07:00
#if defined(HAVE_SO_MAX_PACING_RATE)
/* If socket pacing is available and not disabled, try it. */
if (test->settings->fqrate) {
Squashed commit of the following: 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.
2016-05-26 09:47:48 -07:00
/* Convert bits per second to bytes per second */
unsigned int fqrate = test->settings->fqrate / 8;
if (fqrate > 0) {
Squashed commit of the following: 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.
2016-05-26 09:47:48 -07:00
if (test->debug) {
printf("Setting fair-queue socket pacing to %u\n", fqrate);
Squashed commit of the following: 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.
2016-05-26 09:47:48 -07:00
}
if (setsockopt(s, SOL_SOCKET, SO_MAX_PACING_RATE, &fqrate, sizeof(fqrate)) < 0) {
warning("Unable to set socket pacing");
Squashed commit of the following: 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.
2016-05-26 09:47:48 -07:00
}
}
}
#endif /* HAVE_SO_MAX_PACING_RATE */
{
unsigned int rate = test->settings->rate / 8;
if (rate > 0) {
if (test->debug) {
printf("Setting application pacing to %u\n", rate);
}
}
}
Squashed commit of the following: 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.
2016-05-26 09:47:48 -07:00
#ifdef SO_RCVTIMEO
/* 30 sec timeout for a case when there is a network problem. */
tv.tv_sec = 30;
tv.tv_usec = 0;
setsockopt(s, SOL_SOCKET, SO_RCVTIMEO, (struct timeval *)&tv, sizeof(struct timeval));
#endif
/*
* Write a datagram to the UDP stream to let the server know we're here.
* The server learns our address by obtaining its peer's address.
*/
buf = 123456789; /* this can be pretty much anything */
if (write(s, &buf, sizeof(buf)) < 0) {
2021-09-03 13:24:55 +00:00
// XXX: Should this be changed to IESTREAMCONNECT?
i_errno = IESTREAMWRITE;
return -1;
}
2013-05-02 15:18:07 -07:00
/*
* Wait until the server replies back to us.
*/
2013-05-02 15:18:07 -07:00
if ((sz = recv(s, &buf, sizeof(buf), 0)) < 0) {
i_errno = IESTREAMREAD;
return -1;
}
return s;
2009-11-02 22:43:19 +00:00
}
/* iperf_udp_init
*
* initializer for UDP streams in TEST_START
*/
int
iperf_udp_init(struct iperf_test *test)
{
return 0;
}