From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id C99E43B29D for ; Wed, 16 Jun 2021 10:39:41 -0400 (EDT) Received: from smtpclient.apple (mobile-166-137-176-104.mycingular.net [166.137.176.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 788A022976 for ; Wed, 16 Jun 2021 14:39:40 +0000 (UTC) From: Dave Taht Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Message-Id: <80BF50E7-909B-4291-8CE3-6744DFF13420@teklibre.net> Date: Wed, 16 Jun 2021 07:39:38 -0700 To: starlink@lists.bufferbloat.net X-Mailer: Apple Mail (2.3654.80.0.2.43) Subject: [Starlink] some router hardware we use, stats, and test suites 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: Wed, 16 Jun 2021 14:39:42 -0000 One thing that=E2=80=99s not well understood about running the internet = at higher rates is that above 40Mbit, most of the bufferbloat shifts to = the wifi. eero=E2=80=99s prior to wifi 6 products had a good = implementation of fq_codel throughout, in particular. gfiber still does. = 1000s of other products shipping today have this in the 802.11ac and = prior wifi.=20 For the wifi device drivers that support fq_codel (ath9k, ath10k, mt76, = iwl(intel)), you can poll the =E2=80=9Caqm=E2=80=9D statistics for drops and rfc3168 ecn marks by = looking at the =E2=80=9Caqm=E2=80=9D files in, essentially,=20 find /sys/kernel/debug/iee*/phy*/ -name aqm Given all the interest in pretty plots around here, I=E2=80=99d hope we = could start showing those stats to users also. Being partially blind, I find = the color scheme y=E2=80=99all use so far as almost impossible to read, = but please carry on=E2=80=A6. Also useful (on ath9k) are the xmit and rc_stats files. retransmits and = AC queue usage are especially interesting. Not a lot of people deeply = understand wifi rate control, the best paper on =E2=80=9Cminstrel=E2=80=9D= I know of is here: http://blog.cerowrt.org/post/minstrel/ Our reference routers are the venerable wndr3800 and wndr3700 series = from netgear. We have several that have been up for 7+ years minus some = power failures, and they are entirely open source top to bottom. You can = still get =E2=80=98em off of ebay! We use ubuntu linux and openwrt as our main development platforms. We = really need to add more pi4s to our mix.=20 To drive multi-user wifi tests, we also tend to use old discarded = laptops off of ebay (the lenovo R61i has a wifi card that only does = 802.11a and thus is a good, simple test of 20Mbit wifi performance), a = bunch of random wifi products from apple, google, and others, the = pcengines apu2 with various wifi cards, several different qotom = products, evenroute v4 pro (unreleased as yet), the edgerouter X, the = archer c7v2 and the turris omnia.=20 The omnia is interesting because it has a powerful cpu and few offloads, = as well as an implementation of unbound rather than dnsmasq and a = routing protocol.=20 After coping with qualcomm for too many years[1], most of our still out = of tree fq_codel improvements like ack-filtering have shifted over to = the mediatek mt76 products. Mediatek may be #3, but they try harder. An = example off the shelf mt76 802.11x router you can reflash with the = current openwrt release candidate is here: = https://www.amazon.com/gp/product/B08LMQLG7X/ref=3Dppx_yo_dt_b_search_asin= _title?ie=3DUTF8&psc=3D1 We hope to slam this and a turris omnia into one of our starlink = testbeds on the 25th. Hope is also several more of our volunteers will = have sqm and cake up and running so we can resume p2p = multi-user/multi-client ipv6 testing on a variety of fronts. There are some really heavy duty tests left to run out of the cake, = fq_codel, and other test suites. these are linked to off the relevant cake and fq_codel papers on = https://bufferbloat-and-beyond.net/ as for more recent work (there have been 4 years of development since we = published that book and folded all the apis into the linux kernel), = repeating the enormous test series' of the =E2=80=9CL4S=E2=80=9D vs = =E2=80=9CSCE=E2=80=9D battle over high fidelity lossless congestion = signaling, on starlinks network, is on my mind, but we are running low = on resources to set all that up.=20 Ironically I am on neither side of that debate, as I think RFC3168 is =E2=80=9Cgood enough=E2=80=9D, and easiest to deploy more fully. I = mildly favor the SCE side as it=E2=80=99s fully backward compatible with = RFC3168 which is what=E2=80=99s in fq-codel, cake, and fq-pie, and after = 7 years of deployment rather hard to call back, but I do expect = surprising and interesting results from testing a real world 40ms rtt = LEO network with the test suites we have whenever we can get around to = it.=20 https://github.com/heistp/l4s-tests IMHO: A little lossless congestion control is nice, but too much, not so = much. [1] A few months back we had a pretty good meeting with one of QCA=E2=80=99= s subcontractors where we showed them their current driver design for = the ath11k was going wrong.=20=