From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 9B6AF3CB35 for ; Wed, 19 Aug 2020 23:21:00 -0400 (EDT) Received: by mail-ej1-x62b.google.com with SMTP id p24so842998ejf.13 for ; Wed, 19 Aug 2020 20:21:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=a17jEIuZhfXJauwk8oL0W4844ZbBSH+5A+GivYws7r0=; b=DU62AjbwWjec9aXV6fvckfJNyDzyk6I6lyCrih/EZsiigVDStAMBMZfDpSI3BfRdaj fnmuxAY3+TghGty5S1c+AGGWE2INcrMgdN6R9P/o1l1zGfteaeTR1DPQ5NpCVJUnxbiP wWGZ0nsNX7olffQEBCHutUa9dPVFGz/vlG5jM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=a17jEIuZhfXJauwk8oL0W4844ZbBSH+5A+GivYws7r0=; b=IAOdrI/M8Cb/IN1boERyGzk98nJ+0xTu5qwwCrWkQAMSDk7fXuN6CN11AJ3UP6UuWf sIKlst5LPtwFxKLWpkZGx5u6qhF4zLbCt74WH28P4gq/7mXqVG1/9fjsG9/J+Y9L7l+R XL+KnATqbG4YWNo13d844Y5JXgejRVItbs4ayFyHoHdqcJicyybScMDUUcAOShlVclVW qkFrMawARfDnRyyyrMndlKE9Z4beyuXoEkpxkNrKGSPphtUgFkMgwR9TShCf62/W8Ohw tWPOFbiiU4WbO8so4hVWQuznokUc4J8/xBAFqAMaSTOZE+NMwFWpEX5AlVapU1RpGGC2 QOrQ== X-Gm-Message-State: AOAM530RSlhOCZ/vt74yiaFWToPWHT8D144vrmjKCmJ8taE4hhvOXRrc i78coxRapw3mIYpqPT5eOBj0RDKchDYeSk5fvrZJUQ72OkYk0A== X-Google-Smtp-Source: ABdhPJxKncPAakbNwWK05nfW0gy9OMSrDdtQo1rGC0azz22sD3rW6txMEaP08xC6SO8yH5raTHVGF16hYfQgWptBOo0= X-Received: by 2002:a17:906:98c1:: with SMTP id zd1mr1390730ejb.410.1597893659289; Wed, 19 Aug 2020 20:20:59 -0700 (PDT) MIME-Version: 1.0 From: Bob McMahon Date: Wed, 19 Aug 2020 20:20:48 -0700 Message-ID: To: Make-Wifi-fast Content-Type: multipart/alternative; boundary="000000000000f3bf3805ad469bae" Subject: [Make-wifi-fast] iperf 2.0.14 --sum-only option and TCP client ending timestamp X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 03:21:00 -0000 --000000000000f3bf3805ad469bae Content-Type: text/plain; charset="UTF-8" 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() 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 --000000000000f3bf3805ad469bae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

We're=C2=A0adding a --sum-only option t= o iperf 2.0.14.=C2=A0 This is useful for scaling the number of traffic thre= ads to large values. Here is a sample output:

[rjmcmahon@localhost i= perf2-code]$ src/iperf -c 192.168.1.10 -i 1=C2=A0-P 1000 --sum-only
[SUM-1000] =C2=A00.0- 1.= 0 sec =C2=A01.57 GBytes =C2=A013.5 Gbits/sec
[SUM-1000] =C2=A01.0- 2.0 s= ec =C2=A01.12 GBytes =C2=A09.65 Gbits/sec
[SUM-1000] =C2=A02.0- 3.0 sec = =C2=A01.11 GBytes =C2=A09.50 Gbits/sec
[SUM-1000] =C2=A03.0- 4.0 sec =C2= =A01.11 GBytes =C2=A09.51 Gbits/sec
[SUM-1000] =C2=A04.0- 5.0 sec =C2=A0= 1.10 GBytes =C2=A09.41 Gbits/sec
[SUM-1000] =C2=A05.0- 6.0 sec =C2=A01.0= 9 GBytes =C2=A09.40 Gbits/sec
[SUM-1000] =C2=A06.0- 7.0 sec =C2=A01.10 G= Bytes =C2=A09.45 Gbits/sec
[SUM-1000] =C2=A07.0- 8.0 sec =C2=A01.09 GByt= es =C2=A09.40 Gbits/sec
[SUM-1000] =C2=A08.0- 9.0 sec =C2=A01.10 GBytes = =C2=A09.41 Gbits/sec
[SUM-1000] =C2=A09.0-10.4 sec =C2=A01.34 GBytes =C2= =A08.47 Gbits/sec
[SUM-1000] =C2=A00.0-10.4 sec =C2=A011.7 GBytes =C2=A0= 9.73 Gbits/sec

I also wanted to get feedback on iperf cl= ient timestamps. Particularly on what exactly constitutes=C2=A0a writer as = done?=C2=A0 Is it when the last write completes on the client host, when th= e writer issues a socket=C2=A0close(), or when the writer detects a reader = (server)=C2=A0shutdown()=C2=A0event,=C2=A0i.e. the FIN, FINACK handshake? None = of these are perfect as there are OS and network interactions=C2=A0in 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 soc= ket even though the application thread is done and destroyed.=C2=A0 We'= ve chosen to await for the FINACK per the following in the upcoming release= of iperf 2.0.14
	int<=
/span> rc =3D <=
span style=3D"box-sizing:inherit;margin:0px;padding:0px;border:0px;outline:=
0px;vertical-align:baseline;background:0px 0px">recv(mySocket, &x, 1, MSG_DONTWAIT|MSG_PEEK);

	if (rc=3D=3D0 || !NONFATALTCPREADERR(errno{

#ifdef HAVE_THREAD_DEBUG

	    thread_debug("Client detected server close %d", mySocket);

#endif

	    break;=C2=A0

More Back= ground:=C2=A0

We've implemented the --trip-times option so that = iperf server will be able to give end/end performance at the application le= vel.=C2=A0 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.
<= br>Thanks for thoughts and comments,
Bob
--000000000000f3bf3805ad469bae--