[LibreQoS] [Starlink] [Rpm] [EXTERNAL] Re: Researchers Seeking Probe Volunteers in USA

Sebastian Moeller moeller0 at gmx.de
Mon Mar 13 14:51:58 EDT 2023


Hi Bob,


> On Mar 13, 2023, at 19:42, rjmcmahon <rjmcmahon at rjmcmahon.com> wrote:
> 
>> 	[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


> 
> 
> [root at 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 at 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 at 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
> 



More information about the LibreQoS mailing list