[iccrg] iperf2 Android client: Bounceback fix and updated AP K
[email protected] Tue, 21 Jul 2026 15:56:48 -0700
| Newsgroups | gmane.ietf.irtf.iccrg,gmane.ietf.ippm,gmane.ietf.tsvwg |
|---|---|
| Message-ID | <[email protected]> |
--===============3046837900987804957== Content-Type: multipart/alternative; boundary="=_4457e1c2d3e266ef63c9e2a1632372ac" --=_4457e1c2d3e266ef63c9e2a1632372ac Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Hi All, Following up on the iperf2 Android client I shared earlier. Several testers found a Bounceback bug. During responsiveness and RPS testing under working load, the test would run for a few seconds and then fail. The issue is fixed and has been verified with a 50-second Bounceback run under load. (reminder, the public servers have a 60 second maximum - please keep your duration to lesser.) Install the updated APK Download this file from the SourceForge file listing: iperf2.2.2_21July2026_android.apk https://sourceforge.net/projects/iperf2/files/ Please select that exact filename rather than the green Download button, which may retrieve a different default file. You can install it over an existing version or use it for a new installation. Point the app at one of the default responde.* servers or your own iperf2 server, select a test mode, and press Start. Two features worth testing Bounceback RTT and RPS Bounceback now displays the minimum RTT reported by the kernel's TCP statistics for the connection. This is shown under the live RPS chart together with a theoretical RPS ceiling: 1000 / minimum TCP RTT in milliseconds The two measurements come from different layers. Minimum RTT is a TCP statistic, while observed RPS is measured from the application-level Bounceback request and reply exchanges. Because each Bounceback request waits for its reply before the next request is sent, the minimum TCP RTT provides a useful lower-bound reference for the request and reply cycle. The calculated value is therefore a theoretical ceiling, not an expected RPS result. Comparing it with observed RPS helps show how much additional time is being introduced by server processing, application scheduling, working load, and other path effects. IPv6 testing The public responde.* servers in Fremont, Vienna, and Newark now support IPv6. The app can use them normally through the Host field. A new Force IPv6 (-V) option is also available when you want to test the IPv6 path explicitly rather than allow the operating system to select the address family. Thanks again to everyone for helping with this and providing feedback. Bob --=_4457e1c2d3e266ef63c9e2a1632372ac Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset= =3DUTF-8" /></head><body style=3D'font-size: 10pt; font-family: Verdana,Gen= eva,sans-serif'> <p>Hi All,</p> <p>Following up on the iperf2 Android client I shared earlier.</p> <p>Several testers found a Bounceback bug. During responsiveness and RPS te= sting under working load, the test would run for a few seconds and then fai= l. The issue is fixed and has been verified with a 50-second Bounceback run= under load. (reminder, the public servers have a 60 second maximum - pleas= e keep your duration to lesser.)</p> <p><strong>Install the updated APK</strong></p> <p>Download this file from the SourceForge file listing:</p> <p><code>iperf2.2.2_21July2026_android.apk</code></p> <p><a href=3D"https://sourceforge.net/projects/iperf2/files/">https://sourc= eforge.net/projects/iperf2/files/</a></p> <p>Please select that exact filename rather than the green Download button,= which may retrieve a different default file.</p> <p>You can install it over an existing version or use it for a new installa= tion. Point the app at one of the default <code>responde.*</code> servers o= r your own iperf2 server, select a test mode, and press <strong>Start</stro= ng>.</p> <p><strong>Two features worth testing</strong></p> <p><strong>Bounceback RTT and RPS</strong></p> <p>Bounceback now displays the minimum RTT reported by the kernel’s T= CP statistics for the connection. This is shown under the live RPS chart to= gether with a theoretical RPS ceiling:</p> <p><code>1000 / minimum TCP RTT in milliseconds</code></p> <p>The two measurements come from different layers. Minimum RTT is a TCP st= atistic, while observed RPS is measured from the application-level Bounceba= ck request and reply exchanges.</p> <p>Because each Bounceback request waits for its reply before the next requ= est is sent, the minimum TCP RTT provides a useful lower-bound reference fo= r the request and reply cycle. The calculated value is therefore a theoreti= cal ceiling, not an expected RPS result. Comparing it with observed RPS hel= ps show how much additional time is being introduced by server processing, = application scheduling, working load, and other path effects.</p> <p><strong>IPv6 testing</strong></p> <p>The public <code>responde.*</code> servers in Fremont, Vienna, and Newar= k now support IPv6.</p> <p>The app can use them normally through the Host field. A new <strong>Forc= e IPv6 (-V)</strong> option is also available when you want to test the IPv= 6 path explicitly rather than allow the operating system to select the addr= ess family.</p> <p>Thanks again to everyone for helping with this and providing feedback.</= p> <p>Bob</p> </body></html> --=_4457e1c2d3e266ef63c9e2a1632372ac-- --===============3046837900987804957== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KaWNjcmcgbWFp bGluZyBsaXN0IC0tIGljY3JnQGlydGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg dG8gaWNjcmctbGVhdmVAaXJ0Zi5vcmcK --===============3046837900987804957==--