[Make-wifi-fast] iperf 2.0.14 --sum-only option and TCP client ending timestamp

[Make-wifi-fast] iperf 2.0.14 --sum-only option and TCP client ending timestamp

[Bob McMahon]

[-- Attachment #1: Type: text/plain, Size: 2173 bytes --]

Hi All,

We're adding a --sum-only option to iperf 2.0.14.  This is useful for
scaling the number of traffic threads to large values. Here is a sample
output:

[rjmcmahon@localhost iperf2-code]$ src/iperf -c 192.168.1.10 -i 1 -P 1000
--sum-only
[SUM-1000]  0.0- 1.0 sec  1.57 GBytes  13.5 Gbits/sec
[SUM-1000]  1.0- 2.0 sec  1.12 GBytes  9.65 Gbits/sec
[SUM-1000]  2.0- 3.0 sec  1.11 GBytes  9.50 Gbits/sec
[SUM-1000]  3.0- 4.0 sec  1.11 GBytes  9.51 Gbits/sec
[SUM-1000]  4.0- 5.0 sec  1.10 GBytes  9.41 Gbits/sec
[SUM-1000]  5.0- 6.0 sec  1.09 GBytes  9.40 Gbits/sec
[SUM-1000]  6.0- 7.0 sec  1.10 GBytes  9.45 Gbits/sec
[SUM-1000]  7.0- 8.0 sec  1.09 GBytes  9.40 Gbits/sec
[SUM-1000]  8.0- 9.0 sec  1.10 GBytes  9.41 Gbits/sec
[SUM-1000]  9.0-10.4 sec  1.34 GBytes  8.47 Gbits/sec
[SUM-1000]  0.0-10.4 sec  11.7 GBytes  9.73 Gbits/sec

I also wanted to get feedback on iperf client timestamps. Particularly on
what exactly constitutes a writer as done?  Is it when the last write
completes on the client host, when the writer issues a socket close(), or
when the writer detects a reader (server) shutdown()
<https://linux.die.net/man/3/shutdown> event, i.e. the FIN, FINACK
handshake? None of these are perfect as there are OS and network
interactions in play for all of them which are difficult to decouple. The
first two will cause a timestamp to be a bit early as the OS hasn't
finished draining the socket even though the application thread is done and
destroyed.  We've chosen to await for the FINACK per the following in the
upcoming release of iperf 2.0.14

	int rc = recv(mySocket, &x, 1, MSG_DONTWAIT|MSG_PEEK);
	if (rc==0 || !NONFATALTCPREADERR(errno)) {
#ifdef HAVE_THREAD_DEBUG
	    thread_debug("Client detected server close %d", mySocket);
#endif
	    break;


More Background:

We've implemented the --trip-times option so that iperf server will be able
to give end/end performance at the application level.  With --trip-times
the start stamp is taken from the first write vs., without, it's taken from
the first read. Also, write timestamps go into bursts so the timing is
exactly what a customer will experience.

Thanks for thoughts and comments,
Bob

[-- Attachment #2: Type: text/html, Size: 9057 bytes --]