From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id E08B73B29E; Mon, 13 Mar 2023 14:52:03 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1678733519; i=moeller0@gmx.de; bh=fbavzxIhZeObspjvkAjkIPnT6DXTdF2pALKOKm5cpAw=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=owwOZZYvmax55NRt9DcceI+S8sZIvrdcEs/AsQfX4dOnzRGNnVVw6TVkuPqeQ4w9y KetgTzF0dzmOdbyAHscoWO4ESr9AjcS/5waSACkJqfqJvevJd1RDuWr9Egfc3hKQVn vUzGUSPcsr0CDkr36CKITSqQK9VLrw+QTkUB5Jr/AUf7nMG6/FcZdVFG2PZL5todKc nnX3FP1GzgY6oJqnF8KQikW73uBq4N1mvdFDpxikRso9VCRfVQaR/4SaKz1CETC6+X N6f2UAwWChLfGNkfOC4hM3LLhjmi+Rx5FGVYnIkUxo8QUhK6ERLpJ/vnl9PnBYusPI ePvmB/yOyuLMg== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([134.76.241.253]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MF3HU-1pmkZr00To-00FTyC; Mon, 13 Mar 2023 19:51:59 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.2\)) From: Sebastian Moeller In-Reply-To: <5e7fac51071bdbb20837e72e7eedfc7c@rjmcmahon.com> Date: Mon, 13 Mar 2023 19:51:58 +0100 Cc: dan , Jeremy Austin , Rpm , libreqos , Dave Taht via Starlink , bloat Content-Transfer-Encoding: quoted-printable Message-Id: References: <1672786712.106922180@apps.rackspace.com> <77CCAD19-07E0-4F9E-88C1-D207CF7BF376@cable.comcast.com> <83ffc0dad19e3343e49271889369cefc@rjmcmahon.com> <3CD0B9E6-0B2A-4A70-8F53-ED0822DF77A6@gmx.de> <13DE6E53-665F-4C20-BBE2-70E685421E9D@gmx.de> <22C819FA-DDD7-4B9B-8C09-8008D4273287@gmx.de> <5e7fac51071bdbb20837e72e7eedfc7c@rjmcmahon.com> To: rjmcmahon X-Mailer: Apple Mail (2.3696.120.41.1.2) X-Provags-ID: V03:K1:VxszTwYrogxqecMH1aaUQmPAuTtWz95x2tZ/ltg8iXgn06QV7To 5bROQAoHk6FHIyHraSHlDmBEn8ZHpi/2o1EciCAuEkbRXRF/EUD5nnPZBDbBWw4+SICd9tU NjB5zrksBJPNbA6yoH8tGrNk/B9ZPM2fvs4R27D5HzixL6+itqJrg1Px+oNQEWUNlT8Q00r HA8BQcbFnJ6sI9OJYVhBQ== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:3KQOHScPvLo=;azZBixm+BTMCO1A7jasnCo8QADE B4J3tAUn2qlUJeLe9OnhyPolnO4Z+ib3kzl8ApOiIAKqxhkc5fzaCCjQBQCN9D1aLjcGz0csz DmM5XZ9lCXMQ1WppwiVZljzidBV8YVPe8WPxxSuEuNx1xMOmkMJQ50jmn9vSKZWQzhwsEbPce n5CZtRbh7BRjwrRlO7SCltEdCTACdVkOqqclqNJoFjkOWr+3sSjs5SBVyXwQ83KXiJIcx7BmJ AQaPzwOI0gUGD2uOgJ04wx9qx82HTuZ7GddKvMybi2q4isuW2M8Avfe5wSz49ZNkGctghbKAC iCBfAEBpLpdwYXmSKLOJ57MB789fhEr3NdxEBeyPNCYVXS3T1Mf1KaCEM7N+Ev+NGA2zfL8jg prCGSc1nRmE9SWkh38Gm8hx/R1qn6TPYLOQRTVuQaUmH6p8XjAyWwr9JzGWZEY1ga/LucErc2 zsNsJiWb1eyJ5JGZJavqo7yf7xxb/lHROmKT/B/Te5kpxbnKotZCPDVBreKrbGD83QZZm0miu ohsViOKw3wye/brc5ZQl5Se6sBUCfUtmYjHLVrScwhHeWWnJf/gY0bKPdSX/p0bzu9KJCZGpU MpLdXan5XSG8TuItWFSSWYP92E6UMvwKF0cAyjjToBciL46E4xkH3+n7KuAqsclYg+kRUEyXQ i05OEQ0RaWn+gYnEYFD82SKDq4SICdb06Q9ytspwPOPZKf5dcpXqjGl/NIYPaCTwlusT208Wn VNXwpxQs87SMVd7CemmJnE60CI6CSha49Yc2FYD6MzJfpFG4SfICXTcc8Z3eRQfnyeAQd8+QR pSwhhvAntFxctsnwCYIRzszJioJGjPe+19ZxlWsjlJCsGxSe+9n0FvtwYrWZPTPHUUzdRLjug VFiLqel/c2IHF9fCMbgXtIKtBSkqZ3aKtHZkoc+y4D2eg+oRXq7mlAcOVQaJ5k4nzs2H3TpJq g6aiOQ== Subject: Re: [LibreQoS] [Starlink] [Rpm] [EXTERNAL] Re: Researchers Seeking Probe Volunteers in USA X-BeenThere: libreqos@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Many ISPs need the kinds of quality shaping cake can do List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2023 18:52:04 -0000 Hi Bob, > On Mar 13, 2023, at 19:42, rjmcmahon wrote: >=20 >> [SM] not really, given enough capacity, typical streaming = protocols >> will actually not hit the ceiling, at least the one's I look at every >> now and then tend to stay well below actual capacity of the link. > I think DASH type protocol will hit link peaks. An example with iperf = 2's burst option a controlled WiFi test rig, server side first. [SM] I think that depends, each segment has only a finite length = and if this can delivered before slow start ends that burst might never = hit the capacity? Regards Sebastian >=20 >=20 > [root@ctrl1fc35 ~]# iperf -s -i 1 -e --histograms > ------------------------------------------------------------ > Server listening on TCP port 5001 with pid 23764 > Read buffer size: 128 KByte (Dist bin width=3D16.0 KByte) > Enabled receive histograms bin-width=3D0.100 ms, bins=3D10000 (clients = should use --trip-times) > TCP window size: 128 KByte (default) > ------------------------------------------------------------ > [ 1] local 192.168.1.15%enp2s0 port 5001 connected with 192.168.1.234 = port 34894 (burst-period=3D1.00s) (trip-times) (sock=3D4) (peer = 2.1.9-rc2) (icwnd/mss/irtt=3D14/1448/5170) on 2023-03-13 11:37:24.500 = (PDT) > [ ID] Burst (start-end) Transfer Bandwidth XferTime (DC%) = Reads=3DDist NetPwr > [ 1] 0.00-0.13 sec 10.0 MBytes 633 Mbits/sec 132.541 ms (13%) = 209=3D29:31:31:88:11:2:1:16 597 > [ 1] 1.00-1.11 sec 10.0 MBytes 755 Mbits/sec 111.109 ms (11%) = 205=3D34:30:22:83:11:2:6:17 849 > [ 1] 2.00-2.12 sec 10.0 MBytes 716 Mbits/sec 117.196 ms (12%) = 208=3D33:39:20:81:13:1:5:16 763 > [ 1] 3.00-3.11 sec 10.0 MBytes 745 Mbits/sec 112.564 ms (11%) = 203=3D27:36:30:76:6:3:6:19 828 > [ 1] 4.00-4.11 sec 10.0 MBytes 787 Mbits/sec 106.621 ms (11%) = 193=3D29:26:19:80:10:4:6:19 922 > [ 1] 5.00-5.11 sec 10.0 MBytes 769 Mbits/sec 109.148 ms (11%) = 208=3D36:25:32:86:6:1:5:17 880 > [ 1] 6.00-6.11 sec 10.0 MBytes 760 Mbits/sec 110.403 ms (11%) = 206=3D42:30:22:73:8:3:5:23 860 > [ 1] 7.00-7.11 sec 10.0 MBytes 775 Mbits/sec 108.261 ms (11%) = 171=3D20:21:21:58:12:1:11:27 895 > [ 1] 8.00-8.11 sec 10.0 MBytes 746 Mbits/sec 112.405 ms (11%) = 203=3D36:31:28:70:9:3:2:24 830 > [ 1] 9.00-9.11 sec 10.0 MBytes 748 Mbits/sec 112.133 ms (11%) = 228=3D41:56:27:73:7:2:3:19 834 > [ 1] 0.00-10.00 sec 100 MBytes 83.9 Mbits/sec = 113.238/106.621/132.541/7.367 ms 2034=3D327:325:252:768:93:22:50:197 > [ 1] 0.00-10.00 sec F8(f)-PDF: = bin(w=3D100us):cnt(10)=3D1067:1,1083:1,1092:1,1105:1,1112:1,1122:1,1125:1,= 1126:1,1172:1,1326:1 = (5.00/95.00/99.7%=3D1067/1326/1326,Outliers=3D0,obl/obu=3D0/0) (132.541 = ms/1678732644.500333) >=20 >=20 > [root@fedora ~]# iperf -c 192.168.1.15 -i 1 -t 10 --burst-size 10M = --burst-period 1 --trip-times > ------------------------------------------------------------ > Client connecting to 192.168.1.15, TCP port 5001 with pid 132332 (1 = flows) > Write buffer size: 131072 Byte > Bursting: 10.0 MByte every 1.00 second(s) > TOS set to 0x0 (Nagle on) > TCP window size: 16.0 KByte (default) > Event based writes (pending queue watermark at 16384 bytes) > ------------------------------------------------------------ > [ 1] local 192.168.1.234%eth1 port 34894 connected with 192.168.1.15 = port 5001 (prefetch=3D16384) (trip-times) (sock=3D3) = (icwnd/mss/irtt=3D14/1448/5489) (ct=3D5.58 ms) on 2023-03-13 = 11:37:24.494 (PDT) > [ ID] Interval Transfer Bandwidth Write/Err Rtry = Cwnd/RTT(var) NetPwr > [ 1] 0.00-1.00 sec 10.0 MBytes 83.9 Mbits/sec 80/0 0 = 5517K/18027(1151) us 582 > [ 1] 1.00-2.00 sec 10.0 MBytes 83.9 Mbits/sec 80/0 0 = 5584K/13003(2383) us 806 > [ 1] 2.00-3.00 sec 10.0 MBytes 83.9 Mbits/sec 80/0 0 = 5613K/16462(962) us 637 > [ 1] 3.00-4.00 sec 10.0 MBytes 83.9 Mbits/sec 80/0 0 = 5635K/19523(671) us 537 > [ 1] 4.00-5.00 sec 10.0 MBytes 83.9 Mbits/sec 80/0 0 = 5594K/10013(1685) us 1047 > [ 1] 5.00-6.00 sec 10.0 MBytes 83.9 Mbits/sec 80/0 0 = 5479K/14008(654) us 749 > [ 1] 6.00-7.00 sec 10.0 MBytes 83.9 Mbits/sec 80/0 0 = 5613K/17752(283) us 591 > [ 1] 7.00-8.00 sec 10.0 MBytes 83.9 Mbits/sec 80/0 0 = 5599K/17743(436) us 591 > [ 1] 8.00-9.00 sec 10.0 MBytes 83.9 Mbits/sec 80/0 0 = 5577K/11214(2538) us 935 > [ 1] 9.00-10.00 sec 10.0 MBytes 83.9 Mbits/sec 80/0 0 = 4178K/7251(993) us 1446 > [ 1] 0.00-10.01 sec 100 MBytes 83.8 Mbits/sec 800/0 0 = 4178K/7725(1694) us 1356 > [root@fedora ~]# >=20 > Note: Client side output is being updated to support outputs based = upon the bursts. This allows one to see that a DASH type protocol can = drive the bw bottleneck queue. >=20 > Bob >=20