From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 237F93CB38; Wed, 4 Aug 2021 16:51:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1628110262; bh=XM6jxdCbGfm7Wm2gKITfgr0XWqV1d+ExArsGOf48LTU=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=IuDAEbXPC3BAaJSk+dLSFSYbHRsKsaAYsCrxhvyY4N29tUgUn4kRCUGVvIk7Yjf8d b8zuuC8M8pN+PWbT/pCd29Zpslo2rCo8rFKpv0pCKKYhdqhx0BZDfi7ZdDwjEBItXu LJAdZ3yj+VORQhLHDl82s/6xVpF8W8AnclkXf7DY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.42.229] ([95.112.103.151]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MZCbB-1mgKrH1cG1-00VCqO; Wed, 04 Aug 2021 22:51:02 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) From: Sebastian Moeller In-Reply-To: Date: Wed, 4 Aug 2021 22:51:00 +0200 Cc: Mikael Abrahamsson , Mikael Abrahamsson via Bloat , starlink@lists.bufferbloat.net, dickroy@alum.mit.edu Content-Transfer-Encoding: quoted-printable Message-Id: <84E98266-8D5B-45DC-A59F-58F416AB65ED@gmx.de> References: <058681B8-89EB-42ED-8E82-4048BA3C9504@cable.comcast.com> <649DC4B024D74B8BA6926ABFCD52DC79@SRA6> <5C65BC6E-1ABD-4432-B2CE-AC8BACDA363D@gmx.de> <8393833B-BE11-4B97-92CC-95C2B48305B9@gmx.de> To: Jonathan Morton X-Mailer: Apple Mail (2.3445.104.21) X-Provags-ID: V03:K1:bruAmw0vH2epmiXrsEKB3LPpTwtlDQTVVzCu2jTi2L+UIyaD/AC NW0gY4pAHvwdmf0meBOrlN2+7GQps7/meCHUhVgpcowYnvxNTh0DoKlO90cwE1RAaUFtAoZ EeH7YUrF5QR7o1qHPbaZGeBuTybxGWD3TfuQ9/VJ2hS7jsnGwAedCTrhT/3N/FoxnpAcRVc lDzLQpuXGns97u98KwtoQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:gmcs8hfb4KY=:aK5SGk7tfgYdssPXuniRgc cI5p84PwGjHDNbZwUplJWnansaqz3Nmkwh7XNSjVCtsVS6W6xtCzVX+7cjvNanBbPTMN4F44y KtjBzmlB71LQotzdvO1wyoXur5K9F6JS26O9H5i0v+QNyLVGZejtX4lic41s1pjKL1Tu4HJcY 3pWV1vJysQVyfMSjifYaUKAxRTZD+zsgpHT/fnbBmMTcCdV9+tboCG4/BH5+9on+aM3eRZFp7 WfJkW2yw4Z9Y+pWhMXfIIeFafHbT1Uz8Qjl9l5uJJNq+bYs4eP9N/lH3m9/iY8oIDHORlu2ER S2KH5myzxSRxLCtuUeGrnMte4aHbI7RfO4+vpPKTgcnwy+RXPiA4RTNxO0Btv3IiqY4sKqlem DhgnYXAL63cNu/QfyAjbaPKFxZtuVDrrAosMte5tNlMPRv0TfUNz482TotQGiZ5i+xvJNeaDQ F7/Uk9vOdL2VkAAweStZqcs/qQYon8D50VEixZI0hDqm5pE4/W+6Tbqy1oA/S1vOR3qsBTGYs n8VTlVGI4SJgbXOBGAbWRduOx4mIumaOSWN/9kXI8+b0sd1ZpmglY5oJkBHFPq8ZCix5zUjug LRxJlh+9UwsMvrTM3lXiEIuU4RuuE0n1yuvJ19OQ9ZjsgwVd9wKM8gszYnGGvdzTgOXJ8ahY2 +Crd6r4lXcLFKqiu0qrh2FWOgVzDKr2VJcdirjZOu5sFzLwSp+JFgooDJxM8OLw0EPeM+5Wpa P7mt1n7vx8ov+6IeXsHgJyPFo1kAKdeQ02WVY1hSsVhTTVTPvPr990IO5sYHHuIN5fWsRve6X qmPuqwn64fTkkYjRS0iBPP5gQCcBViV+TnLLOsHrHwsg6Q0u25dpajdnXbykudQCAH3cxMA8W 4VpgGQbuFG/05VSvoKqAAnCVzd5jr85ceZ5fSGaWJrAiYvksXVWmy2ddkpU+zVQQ42XLL2yZI qWCCxHp2cYBnAR7povoiBj7QIOkmcnRcGD4rzS7eEvot63nXvTPfpafG+ajbYXz7iOPquxhII asESJ1SzUiUU6JiwAIT4zWalhX3ZyD4Jz6DwQ99DW02aoipvG34/pjSrEdXV/5Vi37s1i6zB4 rflOm74HUyAUjDbIHTYtxQ4ucV1FByInLoin4UJWLgQHr4T1hhA4w/1yg== Subject: Re: [Bloat] [Starlink] Of interest: Comcast AQM Paper X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2021 20:51:07 -0000 Hi Jonathan, > On Aug 4, 2021, at 20:28, Jonathan Morton = wrote: >=20 > I firmly believe this is due to an I/O bottleneck in the SoC between > the network complex and the CPU complex, not due to any limitation of > the CPU itself. It stems from the reliance on accelerated forwarding > hardware to achieve full line-rate throughput. Even so, I'd much > rather have 40Mbps with Cake than 400Mbps with a dumb FIFO. (Heck, > 40Mbps would be a big upgrade from what I currently have.) I think > some of the newer Atheros chipsets are less constrained in this > respect. >=20 > There are two reasonably good solutions to this problem in the hands > of the SoC vendors: >=20 > 1: Relieve that I/O bottleneck, so that the CPU can handle packets at > full line rate. I assume this is not hugely complicated to implement, > and just requires a sufficient degree of will to select the right > option from the upstream fabless IP vendor's design library. >=20 > 2: Implement good shaping, FQ, and AQM within the network complex. At > consumer broadband/LAN speeds, this shouldn't be too difficult (unlike > doing the same at 100+ Gbps), but it does require a significant amount > of hardware design and validation, and that tends to have long lead > times. >=20 > There is a third solution in the hands of us mere mortals: >=20 > 3: Leverage the Raspberry Pi ecosystem to build a CPE device that > meets our needs. This could be a Compute Module 4 (which has the > necessary I/O throughput) mounted on a custom PCB that provides > additional Ethernet ports and some reasonable Wifi AP. It could > alternatively be a standard Pi 4B with some USB Ethernet and Wifi > hardware plugged into it. Either will do the job withhout any > Ethernet bottlenecks, although the capabilities of USB Wifi dongles > are usually quite limited. Have a look at https://www.dfrobot.com/product-2242.html, which is a = small carrier for the raspberry pi4 compute module that offers two = gigabit ethernet ports, the one from the CM and an additional RTL81111 = one connected via the PCIe lanes. At $45 it is a bit pricy, but it sure is small and elegant. People on the OpenWrt Forum report traffic shaping at 1Gbps rates = without overloading the CPUs (this needs minimal configuration for = receive side packet steering, otherwise all network IRQ and qdisc = processing sticks to CPU0, in which case shaping does not reach Gbps = speeds, at least not for bi-directonal traffic). That still leaves the need for an AP and a switch (one might be able to = "abuse" an AP for switch ports if in a pinch). Regards Sebastian >=20 > - Jonathan Morton