From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id D51BD3B29E for ; Sat, 19 Sep 2020 03:33:25 -0400 (EDT) Received: by mail-ej1-x62b.google.com with SMTP id u21so11054197eja.2 for ; Sat, 19 Sep 2020 00:33:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4u/CQb5Da+N52qIvTbMxNOcoy1qb10Y9MWJwkWaZY98=; b=PwCA54pRI/n6arv2MNmQQcCwKTfd+fMgH2PJH9TKNKigsYRdmqR7Evb+fFtynhMxJj NYUwKEwV1+CkLhPsXiycEF5pU7s+bPd45c+rca+VJlSWGpBXMW4StfoNu6YhKcBMZb2s utf6VeAq4C5krJ8v6aL+MEmQI2rzlUjfL3Evw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4u/CQb5Da+N52qIvTbMxNOcoy1qb10Y9MWJwkWaZY98=; b=DWZwx2tEKMeFvSEufx1szA2vZiNdZ1eE2cP4KW5g81odJgneLxeneS4waLwCoKek5E RFcMOmfyBMNdKKJMk9pg96F0fMBXEpmlXQWUH9qN0yOZ4kMQ4eWhtdT9rRkM8fNj6NKK 5cI+ntK92qpcQDpV88CJPyrMk1KHVgepRYTfOXWLpdMk47hp4+RT11kAwfMxAVcCd8PX NwN0pkHdgwUe43KftkskzjJePCgkKYVUG8B11Hgbf4SkcBtTTxWKYB29r6CnV/dlr5PP kacIldMntXvJc64e1b7l3AQsQqnCId5OT7VVbK04Er8JxP+w6+Hp0kG7cS1+sB/6pgKa 8QAg== X-Gm-Message-State: AOAM5335E+NTYdGbnVLqfzFbFMG4+kWGiM+6DZ/Z5KoU60aX3rNYQBfZ +mdcZg2qnloKw3N67xzDqoQuIW0RJxD5pxFtm3yPPQ== X-Google-Smtp-Source: ABdhPJwfzVBoQyjMI/FFbNN/sS2Yb7KolxlBcQD/PyqEcJryWhLdlbcA0zblZlFHjFrThAG9D2xSYcPZpwT2FOpZa6M= X-Received: by 2002:a17:906:1186:: with SMTP id n6mr38431852eja.331.1600500804003; Sat, 19 Sep 2020 00:33:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Bob McMahon Date: Sat, 19 Sep 2020 00:33:12 -0700 Message-ID: To: Dave Taht Cc: Make-Wifi-fast Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000f19d7c05afa5a1cf" Subject: Re: [Make-wifi-fast] Make - fast - wifi project plan review from 2014.... X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2020 07:33:26 -0000 --000000000000f19d7c05afa5a1cf Content-Type: multipart/alternative; boundary="000000000000e31c2b05afa5a146" --000000000000e31c2b05afa5a146 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On the tools, iperf 2.0.14 is going through a lot of development. My hope is to have the code done soon so it can be tested internally at Broadcom. We're testing with WiFi , to 100G NICs and thousands of parallel threads. I've been able to find time for this refactoring per COVID-19 stay at home work. What I think the industry should move to is measuring both throughput and latency in a direct manner. 2.0.14 also supports full duplex traffic (as well as --reverse) TCP server output shows the following (these are 10G NICs) [rjmcmahon@localhost iperf2-code]$ src/iperf -s -i 1 ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 128 KByte (default) ------------------------------------------------------------ [ 4] local 192.168.1.10%enp2s0 port 5001 connected with 192.168.1.80 port 47420 (trip-times) (MSS=3D1448) (peer 2.0.14-alpha) [ ID] Interval Transfer Bandwidth Reads Dist(bin=3D16.0K) Burst Latency avg/min/max/stdev (cnt/size) inP NetPwr [ 4] 0.00-1.00 sec 1.09 GBytes 9.34 Gbits/sec 18733 2469:2552:2753:2456:2230:2272:1859:2142 2.988/ 0.971/ 3.668/ 0.370 ms (8908/131072) 3.34 MByte 390759.84 [ 4] 1.00-2.00 sec 1.10 GBytes 9.42 Gbits/sec 19844 2690:2984:3211:2858:2255:2039:1893:1914 3.000/ 2.320/ 3.704/ 0.346 ms (8979/131073) 3.37 MByte 392263.52 [ 4] 2.00-3.00 sec 1.10 GBytes 9.41 Gbits/sec 18897 2458:2668:2764:2412:2216:2300:2019:2060 3.003/ 2.310/ 3.665/ 0.347 ms (8978/131070) 3.37 MByte 391878.92 [ 4] 3.00-4.00 sec 1.10 GBytes 9.42 Gbits/sec 18389 2339:2542:2443:2268:2211:2232:2144:2210 3.009/ 2.315/ 3.659/ 0.347 ms (8979/131073) 3.38 MByte 391101.00 [ 4] 4.00-5.00 sec 1.10 GBytes 9.41 Gbits/sec 19468 2588:2889:3017:2623:2250:2221:1947:1933 2.971/ 2.259/ 3.671/ 0.364 ms (8979/131069) 3.33 MByte 396075.85 [ 4] 5.00-6.00 sec 1.10 GBytes 9.41 Gbits/sec 18547 2357:2596:2582:2344:2170:2192:2104:2202 2.971/ 2.276/ 3.699/ 0.365 ms (8978/131072) 3.34 MByte 396149.20 [ 4] 6.00-7.00 sec 1.10 GBytes 9.42 Gbits/sec 18479 2363:2598:2430:2332:2234:2184:2155:2183 2.976/ 2.279/ 3.667/ 0.363 ms (8978/131084) 3.34 MByte 395486.89 [ 4] 7.00-8.00 sec 1.10 GBytes 9.42 Gbits/sec 18506 2387:2549:2519:2339:2229:2183:2060:2240 2.971/ 2.266/ 3.667/ 0.365 ms (8979/131071) 3.33 MByte 396155.84 [ 4] 8.00-9.00 sec 1.10 GBytes 9.41 Gbits/sec 18732 2398:2640:2750:2352:2113:2286:2030:2163 2.973/ 2.271/ 3.691/ 0.364 ms (8979/131059) 3.34 MByte 395780.90 [ 4] 9.00-10.00 sec 1.10 GBytes 9.41 Gbits/sec 19585 2659:2901:3073:2619:2285:2221:1854:1973 2.976/ 2.264/ 3.666/ 0.361 ms (8978/131081) 3.34 MByte 395467.57 [ 4] 10.00-10.00 sec 3.17 MBytes 9.51 Gbits/sec 51 0:6:20:0:0:19:6:0 3.112/ 2.410/ 3.609/ 0.406 ms (26/127692) 2.92 MByte 381912.79 [ 4] 0.00-10.00 sec 11.0 GBytes 9.41 Gbits/sec 189231 24708:26925:27562:24603:22193:22149:20071:21020 2.983/ 0.971/ 3.704/ 0.360 ms (89741/131072) 3.35 MByte 394144.05 Some bidir output looks like: [rjmcmahon@localhost iperf2-code]$ src/iperf -c 192.168.1.10 --trip-times --bidir ------------------------------------------------------------ Client connecting to 192.168.1.10, TCP port 5001 with pid 4322 (1 flows) Write buffer size: 128 KByte TCP window size: 85.0 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.1.80%enp2s0 port 47928 connected with 192.168.1.10 port 5001 (bidir) (trip-times) (MSS=3D1448) (ct=3D0.37 ms) [ ID] Interval Transfer Bandwidth Write/Err Rtry Cwnd/RTT NetPwr [ 3] 0.00-10.00 sec 10.9 GBytes 9.35 Gbits/sec 89183/0 0 3021K/2079 us 562251.48 [ ID] Interval Transfer Bandwidth Reads Dist(bin=3D16.0K) Burst Latency avg/min/max/stdev (cnt/size) inP NetPwr [ 3] 0.00-10.00 sec 10.9 GBytes 9.39 Gbits/sec 174319 21097:23110:24661:21619:18723:17600:13153:34356 2.664/ 1.045/ 6.521/ 0.235 ms (89550/131072) 2.98 MByte 440455.93 [ ID] Interval Transfer Bandwidth [FD3] 0.00-10.00 sec 21.8 GBytes 18.7 Gbits/sec Man page notes: NOTES Numeric options: Some numeric options support format characters per 'c' (e.g. 10M) where the c format characters are k,m,g,K,M,G. Lowercase format characters are 10^3 based and uppercase are 2^n based, e.g. 1k =3D 1000, 1K =3D 1024, 1m =3D 1,000,000 and 1M =3D 1,048,576 Rate limiting: The -b option supports read and write rate limiting at the application level. The -b option on the client also supports variable offered loads through the , format, e.g. -b 100m,10m. The distribution used is log normal. Similar for the isochronous option. The -b on the server rate limits the reads. Socket based pacing is also supported using the --fq-rate long option. This will work with the --reverse and --bidir options as well. Synchronized clocks: The --trip-times option indicates that the client's and server's clocks are synchronized to a common reference. Network Time Protocol (NTP) or Precision Time Protocol (PTP) are commonly used for this. The reference clock(s) error and the synchronization protocols will affect the accuracy of any end to end latency measurements. Binding is done at the logical level (ip address or layer 3) using the -B option and at the device (or layer 2) level using the percent (%) separator for both the client and tne server. On the client, the -B option affects the bind(2) system call, and will set the source ip address and the source port, e.g. iperf -c -B 192.168.100.2:6002. This controls the packet's source values but not routing. These can be confusing in that a route or device lookup may not be that of the device with the configured source IP. So, for example, if the IP address of eth0 is used for -B and the routing table for the destination IP address resolves the output interface to be eth1, then the host will send the packet out device eth1 while using the source IP address of eth0 in the packet. To affect the physical output interface (e.g. dual homed systems) either use -c % (requires root) which bypasses this host route table lookup, or configure policy routing per each -B source address and set the output interface appropriately in the policy routes. On the server or receive, only packets destined to -B IP address will be received. It's also useful for multicast. For example, iperf -s -B 224.0.0.1%eth0 will only accept ip multicast packets with dest ip 224.0.0.1 that are received on the eth0 interface, while iperf -s -B 224.0.0.1 will receive those packets on any interface, Finally, the device specifier is required for v6 link-local, e.g. -c [v6addr]% -V, to select the output interface. Reverse and bidirectional traffic: The --reverse (-R) and --bidir options can be confusing when compared to the legacy options of -r and -d. It's suggested to use --reverse if you want to test through a NAT firewall (or -R on non-windows systems). This applies role reversal of the test after opening the full duplex socket. The latter two of -d and -r remain supported for legacy support and compatibility reasons. These open new sockets in the opposite direction vs treat the originating socket as full duplex. Firewall piercing is typically required to use -d and -r if a NAT gateway is in the path. That's part of the reason it's highly encouraged to use the newer --reverse and --bidir and deprecate the use of the -r and -d options. Also, the --reverse -b setting behaves differently for TCP and UDP. For TCP it will rate limit the read side, i.e. the iperf client (role reversed to act as a server) reading from the full duplex socket. This will in turn flow control the reverse traffic per standard TCP congestion control. The --reverse -b will be applied on transmit (i.e. the server role reversed to act as a client) for UDP since there is no flow control with UDP. There is no option to directly rate limit the writes with TCP testing when using --reverse. TCP Connect times: The TCP connect time (or three way handshake) can be seen on the iperf client when the -e (--enhancedreports) option is set. Look for the ct=3D in the connected message, e.g.in '[ 3] local 192.168.1.4 port 48736 connected with 192.168.1.1 port 5001 (ct=3D1.84 ms)' shows the 3WHS took 1.84 milliseconds. Little's Law in queueing theory is a theorem that determines the average number of items (L) in a stationary queuing system based on the average waiting time (W) of an item within a system and the average number of items arriving at the system per unit of time (lambda). Mathematically, it's L =3D lambda * W. As use= d here, the units are bytes. The arrival rate is taken from the writes. Network power: The network power (NetPwr) metric is experimental. It's a convenience function defined as throughput/delay. For TCP transmits, the delay is the sampled RTT times. For TCP receives, the delay is the write to read latency. For UDP the delay is the end/end latency. Don't confuse this with the physics definition of power (delta energy/delta time) but more of a measure of a desirable property divided by an undesirable property. Also note, one must use -i interval with TCP to get this as that's what sets the RTT sampling rate. The metric is scaled to assist with human readability. Fast Sampling: Use ./configure --enable-fastsampling and then compile from source to enable four digit (e.g. 1.0000) precision in reports' timestamps. Useful for sub-millisecond sampling. Bob On Fri, Sep 18, 2020 at 9:05 AM Dave Taht wrote: > I recently had cause to go review the original make-wifi-fast project > plan ( > https://docs.google.com/document/d/1Se36svYE1Uzpppe1HWnEyat_sAGghB3kE285L= ElJBW4/edit > ) > > (and related presentation: > https://www.youtube.com/watch?v=3DRb-UnHDw02o&t=3D25m30s had the fun bit) > > I'm glad that since that time ATF and mesh networking became > realities, fq_codel and per station queuing gained support in various > products, and AQL started to work on ath10k, but I'm pretty sure > things in that document like rate and power aware scheduling > (minstrel-bluse), excessive counter based hw retries, and other > problems we identified back then are still problems, not to mention > the recent ofdma work.... > > I have been observing pretty bad behavior with a lot of 802.11ac > access points around, (recently one that > went 4Mbits over 40 feet through glass outdoors, but 600 indoors and > 10 feet) but have nothing but guesses as to the causes. Infinite > retries? Everything on 160 mhz wide channels? > > Has there been any good news or good tools lately? > > I pulled my ax200s out of the box and was going to see if there was > any progress there. > > -- > "For a successful technology, reality must take precedence over public > relations, for Mother Nature cannot be fooled" - Richard Feynman > > dave@taht.net CTO, TekLibre, LLC Tel: 1-831-435-0729 > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast --000000000000e31c2b05afa5a146 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On the tools, iperf 2.0.14 is going through a lot of devel= opment.=C2=A0 My hope is to have the code done soon so it can be tested int= ernally at Broadcom.=C2=A0 We're testing with WiFi , to 100G NICs and t= housands of parallel threads.=C2=A0 I've been able to find=C2=A0time fo= r this refactoring per COVID-19 stay at home work.

What I think the = industry should move to is measuring both throughput and latency in a direc= t=C2=A0manner.=C2=A0 2.0.14 also supports full duplex traffic (as well as -= -reverse)=C2=A0 TCP server output shows the following (these are 10G NICs)<= br>
[rjm= cmahon@localhost iperf2-code]$ src/iperf -s -i 1
-----------------------= -------------------------------------
Server listening on TCP port 5001<= br>TCP window size: =C2=A0128 KByte (default)
--------------------------= ----------------------------------
[ =C2=A04] local 192.168.1.10%enp2s0 = port 5001 connected with 192.168.1.80 port 47420 (trip-times) (MSS=3D1448) = (peer 2.0.14-alpha)
[ ID] Interval =C2=A0 =C2=A0 =C2=A0 =C2=A0Transfer = =C2=A0 =C2=A0Bandwidth =C2=A0 =C2=A0 =C2=A0 Reads =C2=A0 Dist(bin=3D16.0K) = =C2=A0 =C2=A0 Burst Latency avg/min/max/stdev (cnt/size) inP NetPwr
[ = =C2=A04] 0.00-1.00 sec =C2=A01.09 GBytes =C2=A09.34 Gbits/sec =C2=A018733 = =C2=A0 =C2=A02469:2552:2753:2456:2230:2272:1859:2142 =C2=A0 =C2=A0 2.988/ 0= .971/ 3.668/ 0.370 ms (8908/131072) 3.34 MByte 390759.84
[ =C2=A04] 1.00= -2.00 sec =C2=A01.10 GBytes =C2=A09.42 Gbits/sec =C2=A019844 =C2=A0 =C2=A02= 690:2984:3211:2858:2255:2039:1893:1914 =C2=A0 =C2=A0 3.000/ 2.320/ 3.704/ 0= .346 ms (8979/131073) 3.37 MByte 392263.52
[ =C2=A04] 2.00-3.00 sec =C2= =A01.10 GBytes =C2=A09.41 Gbits/sec =C2=A018897 =C2=A0 =C2=A02458:2668:2764= :2412:2216:2300:2019:2060 =C2=A0 =C2=A0 3.003/ 2.310/ 3.665/ 0.347 ms (8978= /131070) 3.37 MByte 391878.92
[ =C2=A04] 3.00-4.00 sec =C2=A01.10 GBytes= =C2=A09.42 Gbits/sec =C2=A018389 =C2=A0 =C2=A02339:2542:2443:2268:2211:223= 2:2144:2210 =C2=A0 =C2=A0 3.009/ 2.315/ 3.659/ 0.347 ms (8979/131073) 3.38 = MByte 391101.00
[ =C2=A04] 4.00-5.00 sec =C2=A01.10 GBytes =C2=A09.41 Gb= its/sec =C2=A019468 =C2=A0 =C2=A02588:2889:3017:2623:2250:2221:1947:1933 = =C2=A0 =C2=A0 2.971/ 2.259/ 3.671/ 0.364 ms (8979/131069) 3.33 MByte 396075= .85
[ =C2=A04] 5.00-6.00 sec =C2=A01.10 GBytes =C2=A09.41 Gbits/sec =C2= =A018547 =C2=A0 =C2=A02357:2596:2582:2344:2170:2192:2104:2202 =C2=A0 =C2=A0= 2.971/ 2.276/ 3.699/ 0.365 ms (8978/131072) 3.34 MByte 396149.20
[ =C2= =A04] 6.00-7.00 sec =C2=A01.10 GBytes =C2=A09.42 Gbits/sec =C2=A018479 =C2= =A0 =C2=A02363:2598:2430:2332:2234:2184:2155:2183 =C2=A0 =C2=A0 2.976/ 2.27= 9/ 3.667/ 0.363 ms (8978/131084) 3.34 MByte 395486.89
[ =C2=A04] 7.00-8.= 00 sec =C2=A01.10 GBytes =C2=A09.42 Gbits/sec =C2=A018506 =C2=A0 =C2=A02387= :2549:2519:2339:2229:2183:2060:2240 =C2=A0 =C2=A0 2.971/ 2.266/ 3.667/ 0.36= 5 ms (8979/131071) 3.33 MByte 396155.84
[ =C2=A04] 8.00-9.00 sec =C2=A01= .10 GBytes =C2=A09.41 Gbits/sec =C2=A018732 =C2=A0 =C2=A02398:2640:2750:235= 2:2113:2286:2030:2163 =C2=A0 =C2=A0 2.973/ 2.271/ 3.691/ 0.364 ms (8979/131= 059) 3.34 MByte 395780.90
[ =C2=A04] 9.00-10.00 sec =C2=A01.10 GBytes = =C2=A09.41 Gbits/sec =C2=A019585 =C2=A0 =C2=A02659:2901:3073:2619:2285:2221= :1854:1973 =C2=A0 =C2=A0 2.976/ 2.264/ 3.666/ 0.361 ms (8978/131081) 3.34 M= Byte 395467.57
[ =C2=A04] 10.00-10.00 sec =C2=A03.17 MBytes =C2=A09.51 G= bits/sec =C2=A051 =C2=A0 =C2=A00:6:20:0:0:19:6:0 =C2=A0 =C2=A0 3.112/ 2.410= / 3.609/ 0.406 ms (26/127692) 2.92 MByte 381912.79
[ =C2=A04] 0.00-10.00= sec =C2=A011.0 GBytes =C2=A09.41 Gbits/sec =C2=A0189231 =C2=A0 =C2=A024708= :26925:27562:24603:22193:22149:20071:21020 =C2=A0 =C2=A0 2.983/ 0.971/ 3.70= 4/ 0.360 ms (89741/131072) 3.35 MByte 394144.05

Some bi= dir output looks like:

[rjmcmahon@localhost iperf2-code]$ src/iperf -c 192.168= .1.10 --trip-times --bidir
---------------------------------------------= ---------------
Client connecting to 192.168.1.10, TCP port 5001 with pi= d 4322 (1 flows)
Write buffer size: =C2=A0128 KByte
TCP window size: = 85.0 KByte (default)
---------------------------------------------------= ---------
[ =C2=A03] local 192.168.1.80%enp2s0 port 47928 connected with= 192.168.1.10 port 5001 (bidir) (trip-times) (MSS=3D1448) (ct=3D0.37 ms)[ ID] Interval =C2=A0 =C2=A0 =C2=A0 =C2=A0Transfer =C2=A0 =C2=A0Bandwidth = =C2=A0 =C2=A0 =C2=A0 Write/Err =C2=A0Rtry =C2=A0 =C2=A0 Cwnd/RTT =C2=A0 =C2= =A0 =C2=A0 =C2=A0NetPwr
[ =C2=A03] 0.00-10.00 sec =C2=A010.9 GBytes =C2=A09.35 Gbits/sec =C2=A0= 89183/0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00 =C2=A0 =C2=A0 3021K/2079 us =C2= =A0562251.48
[ ID] Interval =C2=A0 =C2=A0 =C2=A0 =C2=A0Transfer =C2=A0 = =C2=A0Bandwidth =C2=A0 =C2=A0 =C2=A0 Reads =C2=A0 Dist(bin=3D16.0K) =C2=A0 = =C2=A0 Burst Latency avg/min/max/stdev (cnt/size) inP NetPwr
[ =C2=A03] = 0.00-10.00 sec =C2=A010.9 GBytes =C2=A09.39 Gbits/sec =C2=A0174319 =C2=A0 = =C2=A021097:23110:24661:21619:18723:17600:13153:34356 =C2=A0 =C2=A0 2.664/ = 1.045/ 6.521/ 0.235 ms (89550/131072) 2.98 MByte 440455.93
[ ID] Interva= l =C2=A0 =C2=A0 =C2=A0 Transfer =C2=A0 =C2=A0 Bandwidth
[FD3] 0.00-10.00= sec =C2=A021.8 GBytes =C2=A018.7 Gbits/sec

Man page notes:=

NOTES
=C2=A0 =C2=A0 =C2=A0 =C2=A0Numeric options: Some nu= meric options support format characters per '<value>c' (e.g. = 10M) where the c format characters are k,m,g,K,M,G.=C2=A0 Lowercase format = characters are 10^3 based and uppercase are 2^n based, e.g. 1k =C2=A0=3D = =C2=A01000, =C2=A01K =C2=A0=3D =C2=A01024, =C2=A01m =C2=A0=3D
=C2=A0 =C2= =A0 =C2=A0 =C2=A01,000,000 and 1M =3D 1,048,576

=C2=A0 =C2=A0 =C2=A0= =C2=A0Rate =C2=A0limiting: The -b option supports read and write rate limi= ting at the application level.=C2=A0 The -b option on the client also suppo= rts variable offered loads through the <mean>,<standard deviation&= gt; format, e.g. =C2=A0-b 100m,10m. The distribution used
=C2=A0 =C2=A0 = =C2=A0 =C2=A0is log normal. Similar for the isochronous option. The -b on t= he server rate limits the reads. Socket based pacing is also supported usin= g the --fq-rate long option. This will work with the --reverse and --bidir = options as well.

=C2=A0 =C2=A0 =C2=A0 =C2=A0Synchronized clocks: The= --trip-times option indicates that the client's and server's clock= s are synchronized to a common reference.=C2=A0 Network Time Protocol (NTP)= or Precision Time Protocol (PTP) are commonly used for this.=C2=A0 The =C2= =A0reference =C2=A0clock(s)
=C2=A0 =C2=A0 =C2=A0 =C2=A0error and the syn= chronization protocols will affect the accuracy of any end to end latency m= easurements.

=C2=A0 =C2=A0 =C2=A0 =C2=A0Binding =C2=A0is done at the= logical level (ip address or layer 3) using the -B option and at the devic= e (or layer 2) level using the percent (%) separator for both the client an= d tne server. On the client, the -B option affects the bind(2) system call,=
=C2=A0 =C2=A0 =C2=A0 =C2=A0and will set the source ip address and the s= ource port, e.g. iperf -c <host> -B 192.168.100.2:6002. This controls the packet's source values b= ut not routing.=C2=A0 These can be confusing in that a route or device look= up may not be =C2=A0that =C2=A0of =C2=A0the =C2=A0device
=C2=A0 =C2=A0 = =C2=A0 =C2=A0with =C2=A0the configured source IP.=C2=A0 So, for example, if= the IP address of eth0 is used for -B and the routing table for the destin= ation IP address resolves the output interface to be eth1, then the host wi= ll send the packet out device eth1 while using
=C2=A0 =C2=A0 =C2=A0 =C2= =A0the source IP address of eth0 in the packet.=C2=A0 To affect the physica= l output interface (e.g. dual homed systems) either use -c <host>%<= ;dev> (requires root) which bypasses this host route table lookup, or co= nfigure policy routing per each =C2=A0-B =C2=A0source
=C2=A0 =C2=A0 =C2= =A0 =C2=A0address =C2=A0and set the output interface appropriately in the p= olicy routes. On the server or receive, only packets destined to -B IP addr= ess will be received. It's also useful for multicast. For example, iper= f -s -B 224.0.0.1%eth0 will only accept ip
=C2=A0 =C2=A0 =C2=A0 =C2=A0mu= lticast packets with dest ip 224.0.0.1 that are received on the eth0 interf= ace, while iperf -s -B 224.0.0.1 will receive those packets on any interfac= e, Finally, the device specifier is required for v6 link-local, e.g. -c =C2= =A0[v6addr]%<dev> =C2=A0-V, =C2=A0to
=C2=A0 =C2=A0 =C2=A0 =C2=A0se= lect the output interface.

=C2=A0 =C2=A0 =C2=A0 =C2=A0Reverse and bi= directional traffic: The --reverse (-R) and --bidir options can be confusin= g when compared to the legacy options of -r and -d.=C2=A0 It's suggeste= d to use --reverse if you want to test through a NAT firewall (or -R on non= -windows systems).
=C2=A0 =C2=A0 =C2=A0 =C2=A0This applies role reversal= of the test after opening the full duplex socket. The latter two of -d and= -r remain supported for legacy support and compatibility reasons.=C2=A0 Th= ese open new sockets in the =C2=A0opposite =C2=A0direction =C2=A0vs =C2=A0t= reat =C2=A0the =C2=A0originating
=C2=A0 =C2=A0 =C2=A0 =C2=A0socket as fu= ll duplex. Firewall piercing is typically required to use -d and -r if a NA= T gateway is in the path. That's part of the reason it's highly enc= ouraged to use the newer --reverse and --bidir and deprecate the use of the= -r and -d options.

=C2=A0 =C2=A0 =C2=A0 =C2=A0Also, =C2=A0the =C2= =A0--reverse -b <rate> setting behaves differently for TCP and UDP. F= or TCP it will rate limit the read side, i.e. the iperf client (role revers= ed to act as a server) reading from the full duplex socket.=C2=A0 This will= in turn flow control the
=C2=A0 =C2=A0 =C2=A0 =C2=A0reverse traffic per= standard TCP congestion control. The --reverse -b <rate> will be app= lied on transmit (i.e. the server role reversed to act as a client) for UDP= since there is no flow control with UDP. There is no option to directly = =C2=A0rate =C2=A0limit
=C2=A0 =C2=A0 =C2=A0 =C2=A0the writes with TCP te= sting when using --reverse.

=C2=A0 =C2=A0 =C2=A0 =C2=A0TCP =C2=A0Con= nect =C2=A0times: =C2=A0The TCP connect time (or three way handshake) can b= e seen on the iperf client when the -e (--enhancedreports) option is set. L= ook for the ct=3D<value> in the connected message, e.g.in '[ 3] local 192.168.1.4 port 48736 connected
=C2= =A0 =C2=A0 =C2=A0 =C2=A0with 192.168.1.1 port 5001 (ct=3D1.84 ms)' show= s the 3WHS took 1.84 milliseconds.

=C2=A0 =C2=A0 =C2=A0 =C2=A0Little= 's Law in queueing theory is a theorem that determines the average numb= er of items (L) in a stationary queuing system based on the average waiting= time (W) of an item within a system and the average number of items arrivi= ng at the system =C2=A0per
=C2=A0 =C2=A0 =C2=A0 =C2=A0unit of time (lamb= da). Mathematically, it's L =3D lambda * W. As used here, the units are= bytes. The arrival rate is taken from the writes.

=C2=A0 =C2=A0 =C2= =A0 =C2=A0Network =C2=A0power: =C2=A0The network power (NetPwr) metric is e= xperimental. It's a convenience function defined as throughput/delay.= =C2=A0 For TCP transmits, the delay is the sampled RTT times.=C2=A0 For TCP= receives, the delay is the write to read latency.=C2=A0 For UDP
=C2=A0 = =C2=A0 =C2=A0 =C2=A0the delay is the end/end latency.=C2=A0 Don't confu= se this with the physics definition of power (delta energy/delta time) but = more of a measure of a desirable property divided by an undesirable propert= y. Also note, one must use -i interval with =C2=A0TCP =C2=A0to
=C2=A0 = =C2=A0 =C2=A0 =C2=A0get this as that's what sets the RTT sampling rate.= The metric is scaled to assist with human readability.

=C2=A0 =C2= =A0 =C2=A0 =C2=A0Fast Sampling: Use ./configure --enable-fastsampling and t= hen compile from source to enable four digit (e.g. 1.0000) precision in rep= orts' timestamps. Useful for sub-millisecond sampling.
Bob


On Fri, Sep 18, 2020 at 9:05 AM Dave Taht <dave.taht@gmail.com> wrote:
<= /div>
I recently had cause= to go review the original make-wifi-fast project
plan ( https://d= ocs.google.com/document/d/1Se36svYE1Uzpppe1HWnEyat_sAGghB3kE285LElJBW4/edit= )

(and related presentation:
https://www.youtube.com/watch?v=3DRb-UnH= Dw02o&t=3D25m30s had the fun bit)

I'm glad that since that time ATF and mesh networking became
realities, fq_codel and per station queuing gained support in various
products, and AQL started to work on ath10k, but I'm pretty sure
things in that document like rate and power aware scheduling
(minstrel-bluse), excessive counter based hw retries, and other
problems we identified back then are still problems, not to mention
the recent ofdma work....

I have been observing pretty bad behavior with a lot of 802.11ac
access points around, (recently one that
went 4Mbits over 40 feet through glass outdoors, but 600 indoors and
10 feet) but have nothing but guesses as to the causes. Infinite
retries? Everything on 160 mhz wide channels?

Has there been any good news or good tools lately?

I pulled my ax200s out of the box and was going to see if there was
any progress there.

--
"For a successful technology, reality must take precedence over public=
relations, for Mother Nature cannot be fooled" - Richard Feynman

dave@taht.net <Da= ve T=C3=A4ht> CTO, TekLibre, LLC Tel: 1-831-435-0729
_______________________________________________
Make-wifi-fast mailing list
M= ake-wifi-fast@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/make-wif= i-fast
--000000000000e31c2b05afa5a146-- --000000000000f19d7c05afa5a1cf Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIQPwYJKoZIhvcNAQcCoIIQMDCCECwCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg2UMIIE6DCCA9CgAwIBAgIOSBtqCRO9gCTKXSLwFPMwDQYJKoZIhvcNAQELBQAwTDEgMB4GA1UE CxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMT Ckdsb2JhbFNpZ24wHhcNMTYwNjE1MDAwMDAwWhcNMjQwNjE1MDAwMDAwWjBdMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEzMDEGA1UEAxMqR2xvYmFsU2lnbiBQZXJzb25h bFNpZ24gMiBDQSAtIFNIQTI1NiAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA tpZok2X9LAHsYqMNVL+Ly6RDkaKar7GD8rVtb9nw6tzPFnvXGeOEA4X5xh9wjx9sScVpGR5wkTg1 fgJIXTlrGESmaqXIdPRd9YQ+Yx9xRIIIPu3Jp/bpbiZBKYDJSbr/2Xago7sb9nnfSyjTSnucUcIP ZVChn6hKneVGBI2DT9yyyD3PmCEJmEzA8Y96qT83JmVH2GaPSSbCw0C+Zj1s/zqtKUbwE5zh8uuZ p4vC019QbaIOb8cGlzgvTqGORwK0gwDYpOO6QQdg5d03WvIHwTunnJdoLrfvqUg2vOlpqJmqR+nH 9lHS+bEstsVJtZieU1Pa+3LzfA/4cT7XA/pnwwIDAQABo4IBtTCCAbEwDgYDVR0PAQH/BAQDAgEG MGoGA1UdJQRjMGEGCCsGAQUFBwMCBggrBgEFBQcDBAYIKwYBBQUHAwkGCisGAQQBgjcUAgIGCisG AQQBgjcKAwQGCSsGAQQBgjcVBgYKKwYBBAGCNwoDDAYIKwYBBQUHAwcGCCsGAQUFBwMRMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFGlygmIxZ5VEhXeRgMQENkmdewthMB8GA1UdIwQYMBaA FI/wS3+oLkUkrk1Q+mOai97i3Ru8MD4GCCsGAQUFBwEBBDIwMDAuBggrBgEFBQcwAYYiaHR0cDov L29jc3AyLmdsb2JhbHNpZ24uY29tL3Jvb3RyMzA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3Js Lmdsb2JhbHNpZ24uY29tL3Jvb3QtcjMuY3JsMGcGA1UdIARgMF4wCwYJKwYBBAGgMgEoMAwGCisG AQQBoDIBKAowQQYJKwYBBAGgMgFfMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8vd3d3Lmdsb2JhbHNp Z24uY29tL3JlcG9zaXRvcnkvMA0GCSqGSIb3DQEBCwUAA4IBAQConc0yzHxn4gtQ16VccKNm4iXv 6rS2UzBuhxI3XDPiwihW45O9RZXzWNgVcUzz5IKJFL7+pcxHvesGVII+5r++9eqI9XnEKCILjHr2 DgvjKq5Jmg6bwifybLYbVUoBthnhaFB0WLwSRRhPrt5eGxMw51UmNICi/hSKBKsHhGFSEaJQALZy 4HL0EWduE6ILYAjX6BSXRDtHFeUPddb46f5Hf5rzITGLsn9BIpoOVrgS878O4JnfUWQi29yBfn75 HajifFvPC+uqn+rcVnvrpLgsLOYG/64kWX/FRH8+mhVe+mcSX3xsUpcxK9q9vLTVtroU/yJUmEC4 OcH5dQsbHBqjMIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAwTDEgMB4G A1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzARBgNV BAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAwHgYDVQQL ExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMK R2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5BngiFvXAg7aE yiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X17YUhhB5 uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmmKPZpO/bL yCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hpsk+QLjJg 6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7DWzgVGkW qQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8w HQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBLQNvAUKr+ yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25sbwMpjjM5 RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV3XpYKBov Hd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyrVQ4PkX42 68NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E7gUJTb0o 2HLO02JQZR7rkpeDMdmztcpHWD9fMIIFQTCCBCmgAwIBAgIML7TfFWHfxluS5m0sMA0GCSqGSIb3 DQEBCwUAMF0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTMwMQYDVQQD EypHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAyIENBIC0gU0hBMjU2IC0gRzMwHhcNMjAwODMxMDgw OTQ5WhcNMjIwOTAxMDgwOTQ5WjCBjDELMAkGA1UEBhMCSU4xEjAQBgNVBAgTCUthcm5hdGFrYTES MBAGA1UEBxMJQmFuZ2Fsb3JlMRYwFAYDVQQKEw1Ccm9hZGNvbSBJbmMuMRQwEgYDVQQDEwtCb2Ig TWNNYWhvbjEnMCUGCSqGSIb3DQEJARYYYm9iLm1jbWFob25AYnJvYWRjb20uY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzK1kauAQxAkeif97AJqv3QgJVDztfPjduswFJbcT0VbZ hr+E3gpqCnUm9TM4HZ2aviVSu9A9SkcpQBOaiOUPUkMrD6PoviodpwV2C5W+i7e/lexjsUdSuTZe h7GRKEOlhPnsW7RgKFR5+3Rrm1kAyEJ2x2ueyn3UhupxoNrYxZOss/+dPwQJ28kP7ICHBBJbcfmh doMU83sfJazBMsp+pMArApFdMwXOBL3dT4ZPkniaMilO+q2y7xQ212K+KlhaRWCWcImC/+pqZCyH /b1zx6vfBbdB/WD9+oi9rnXyd2ikVU2bvJ15VinB52kz7Kpj4A1e7zHgKxqNjFFycWXn2QIDAQAB o4IBzzCCAcswDgYDVR0PAQH/BAQDAgWgMIGeBggrBgEFBQcBAQSBkTCBjjBNBggrBgEFBQcwAoZB aHR0cDovL3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvZ3NwZXJzb25hbHNpZ24yc2hhMmcz b2NzcC5jcnQwPQYIKwYBBQUHMAGGMWh0dHA6Ly9vY3NwMi5nbG9iYWxzaWduLmNvbS9nc3BlcnNv bmFsc2lnbjJzaGEyZzMwTQYDVR0gBEYwRDBCBgorBgEEAaAyASgKMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMAkGA1UdEwQCMAAwRAYDVR0fBD0w OzA5oDegNYYzaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9nc3BlcnNvbmFsc2lnbjJzaGEyZzMu Y3JsMCMGA1UdEQQcMBqBGGJvYi5tY21haG9uQGJyb2FkY29tLmNvbTATBgNVHSUEDDAKBggrBgEF BQcDBDAfBgNVHSMEGDAWgBRpcoJiMWeVRIV3kYDEBDZJnXsLYTAdBgNVHQ4EFgQUQ1s1Ocvee2Eh o0qY50aFmX9fHS0wDQYJKoZIhvcNAQELBQADggEBAFygcUiFPJ7uRXexxLYonpGCsztO0YcmuWCE jef/oS4oMYJyf+pv/dgdywaJ9U4FhYHg9wIPEcWwS1JpsUrEhx1zQ2JX8+HNHyuCiR11tgtzCr0z nxeMm3RAJPmM3cAy5mS7pDz1Ox081EqDQQzeesvMwwONjIpV1ORg17fpIHxz4KaKg8X5Yv6xYs0Z L+UVLQlmIJqoOHqzOelCjNTCSucYx/sYygzQcvUuX7qUgLOJq+o4JXhqu2dUJ6wu/NPApqyd8hSc YVBMvygG2Y3xBjxYC5Dr4+E1cmcOGEUQhkKo4cwv217+W4FXb4K4B/EM208EsUMXGTb7tV5zJ0rO IH4xggJvMIICawIBATBtMF0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNh MTMwMQYDVQQDEypHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAyIENBIC0gU0hBMjU2IC0gRzMCDC+0 3xVh38ZbkuZtLDANBglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgndfpyvgU5SmAOjVE tn71YWDeW/8cQQ1JaxIer+ljB0QwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMjAwOTE5MDczMzI0WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgB ZQMEARYwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcw CwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBALAT3+15AtERddSOaSJBydrrK20hh+Zcd3If 3xsU9+/zEysGLn7QwPGMvAUK4QeUj+9qZx7IyO3Li2jk094XzfUXuFyJ/JaY5EW58PGKIJg6dwxi K411DBDvVQTugXESBbKB4Un/oR5x4cSk3cK3VFJkfZR7YBqwIXNX9/HoSch7Yqevodwmm8P9NzHM HPgoPC4k+D5u/X+vlu3UyWn9a3sK7T8xTuxGGlb8O7wSX0gOoVJrL7Yk2RiquGbQ4GZPpE0m3oJr haZVb27/SbigutlL3oohXxK5y4rIJLON+j2dZ8mgtSGwiyoKa552HiG5p0KDZmlN4c+inRvrOhfP bAs= --000000000000f19d7c05afa5a1cf--