[CCWG] Re: [iccrg] iperf2 Android update: Bounceback fixes and IPv6 support

[Sebastian Moeller <[e-mail]>]

Hi Bob,

this is getting better and better, CDF and PDF of the RPS data and throughput traces of potential working loads are really helping understanding what is going on!

Regards
	Sebastian

> On Jul 24, 2026, at 08:38, bob.mcmahon=[e-mail] wrote:
> 
> Hi All,
> 
> I've updated the iperf 2 android bounceback test to display the histogram with a CDF overlay. UDP L4S bounce back is still beind coded up and tested.
> 
> 
> 
> On 2026-07-22 11:57, [e-mail] wrote:
>> Hi all,
>> An updated iperf2 Android build is available with two Bounceback fixes.
>> First, a bug that caused responsiveness and RPS tests under working load to fail after a few seconds has been fixed. The update has been verified with a 50-second Bounceback run under load.
>> Second, the selected congestion-control algorithm now applies at both ends of the Bounceback connection. Anyone comparing congestion-control algorithms should repeat those tests with this build.
>> The public responde.* servers support Reno, Cubic, and BBR, with Cubic as the default. They do not currently support Prague. Prague testing requires both a server and a device with Prague available.
>> The public servers have already been updated. If you use your own iperf2 server, please update it from the 2-2-2 branch.
>> The public servers limit tests to 60 seconds, so please select a shorter duration.
>> Android client presentation:
>> https://www.umbernetworks.com/IPPM_iperf2_Android_Pres.html
>> Install the updated APK
>> Download this exact file from the SourceForge file listing:
>> iperf2.2.2_21.bb_cca_fix.July2026_android.apk
>> https://sourceforge.net/projects/iperf2/files/
>> Please select the filename directly rather than using the green Download button, which may retrieve a different file. The APK can be installed over an existing version.
>> Features worth testing
>> Bounceback now displays the minimum RTT reported by the kernel's TCP statistics, together with a theoretical RPS ceiling:
>> Theoretical RPS ceiling = 1,000 ms / minimum TCP RTT
>> For example, a minimum TCP RTT of 20 ms gives a theoretical ceiling of 50 request-and-reply cycles per second.
>> Minimum RTT is a TCP statistic, while observed RPS is measured from the application-level Bounceback exchanges. Because each request waits for its reply before the next request is sent, actual RPS will normally be lower because of application processing, scheduling, working load, and other path effects.
>> The public responde.* servers in Fremont, Vienna, and Newark also support IPv6. The app can select IPv6 normally through the Host field, or you can enable Force IPv6 (-V) to test the IPv6 path explicitly. Your local network must also support IPv6.
>> Thanks again to everyone testing the app and providing feedback. It is very helpful.
>> Bob
> 
> _______________________________________________
> iccrg mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]