From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bobcat.rjmcmahon.com (bobcat.rjmcmahon.com [45.33.58.123]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id C44C53B29E; Mon, 13 Mar 2023 14:42:40 -0400 (EDT) Received: from mail.rjmcmahon.com (bobcat.rjmcmahon.com [45.33.58.123]) by bobcat.rjmcmahon.com (Postfix) with ESMTPA id 115E11EEE8; Mon, 13 Mar 2023 11:42:40 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bobcat.rjmcmahon.com 115E11EEE8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rjmcmahon.com; s=bobcat; t=1678732960; bh=0zz+br0+8iz1vHSK8GqtESp+lN9MEDXCaPA39F8XrCc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=DnMI/4xz/WvoQ+IhJxM5Hnhxn3J1SIZ2miBFLqiGBPusl6iK/g0Js8qFL9QFDpZC4 /g3mHYU5IZi/glzcKh0k+QLeWNOaAi0BsfmfanzTPr1DMIUSLCAvT1UBixayDW4Tn1 seSbw4Kz0LsJ8JOX+qZIRG1rEhIfOIqoaTCJw6Zg= MIME-Version: 1.0 Date: Mon, 13 Mar 2023 11:42:40 -0700 From: rjmcmahon To: Sebastian Moeller Cc: dan , Jeremy Austin , Rpm , libreqos , Dave Taht via Starlink , bloat In-Reply-To: <22C819FA-DDD7-4B9B-8C09-8008D4273287@gmx.de> 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> Message-ID: <5e7fac51071bdbb20837e72e7eedfc7c@rjmcmahon.com> X-Sender: rjmcmahon@rjmcmahon.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Starlink] [Rpm] [LibreQoS] [EXTERNAL] Re: Researchers Seeking Probe Volunteers in USA X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2023 18:42:40 -0000 > [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. [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=16.0 KByte) Enabled receive histograms bin-width=0.100 ms, bins=10000 (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=1.00s) (trip-times) (sock=4) (peer 2.1.9-rc2) (icwnd/mss/irtt=14/1448/5170) on 2023-03-13 11:37:24.500 (PDT) [ ID] Burst (start-end) Transfer Bandwidth XferTime (DC%) Reads=Dist NetPwr [ 1] 0.00-0.13 sec 10.0 MBytes 633 Mbits/sec 132.541 ms (13%) 209=29: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=34: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=33: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=27: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=29: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=36: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=42: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=20: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=36: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=41: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=327:325:252:768:93:22:50:197 [ 1] 0.00-10.00 sec F8(f)-PDF: bin(w=100us):cnt(10)=1067: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%=1067/1326/1326,Outliers=0,obl/obu=0/0) (132.541 ms/1678732644.500333) [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=16384) (trip-times) (sock=3) (icwnd/mss/irtt=14/1448/5489) (ct=5.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 ~]# 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. Bob