From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.lang.hm (unknown [66.167.227.145]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 120303B2A4 for ; Wed, 8 Jun 2022 20:21:11 -0400 (EDT) Received: from dlang-mobile (unknown [10.2.2.69]) by mail.lang.hm (Postfix) with ESMTP id 1A1C1135EDD; Wed, 8 Jun 2022 17:21:10 -0700 (PDT) Date: Wed, 8 Jun 2022 17:21:10 -0700 (PDT) From: David Lang To: Stuart Cheshire cc: warren ponder , starlink@lists.bufferbloat.net, "David P. Reed" In-Reply-To: <1223D984-F410-4457-A2F5-471C5F638BF9@apple.com> Message-ID: <60o9p77-4q39-nnr8-0n6-72q11s84444n@ynat.uz> References: <1654714026.72728578@apps.rackspace.com> <1223D984-F410-4457-A2F5-471C5F638BF9@apple.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="228850167-561034312-1654734070=:13569" Subject: Re: [Starlink] FQ_Codel 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: Thu, 09 Jun 2022 00:21:11 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --228850167-561034312-1654734070=:13569 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT multiple access points, good. Mesh can make the problem worse. The combination of hidden transmitters (station in the middle can hear stations on both ends, but they can't hear each other and so step on each other) and just more airtime needed ro relay the messages as there are more hops can make the congestion worse (however, it is possible that higher data rates could make the transmissions shorter, but since the inter-aggregate gaps and per-aggregate headers are fixed at a low data rate, I doubt that it works that way in practice) but get a few additional APs hooked together via wires, and you have a clear win that scales very well. It's what we do at the Scale conf with 100+ APs to support 3k+ geeks. David Lang On Wed, 8 Jun 2022, Stuart Cheshire wrote: > On 8 Jun 2022, at 12:12, warren ponder wrote: > >> So this is really helpful. Is it fair to say then that end users with SQM and fq_codel on a Starlink connection should essentially not turn on SQM.and.just leave it off? > > My advice is that people should have SQM (e.g., fq_codel) enabled anywhere it is available. For devices that aren’t the bottleneck hop on a path it won’t make any difference, but it won’t hurt. And if the network topology is such that it does become the bottleneck hop, even briefly, SQM will avoid having a big queue build up there. > > One example is Wi-Fi. If you have 50Mb/s Internet service and 802.11ac Wi-Fi in the house, your Wi-Fi is unlikely to be the bottleneck. But if you walk out to the garden and the Wi-Fi rate drops to 40Mb/s, then suddenly bufferbloat in the AP can bite you, leading to bi-modal network usability, that abruptly falls off a cliff the moment your Wi-Fi rate drops below your Internet service rate. I think this is a large part of the reason behind the enthusiasm these days for “mesh” Wi-Fi systems -- you need to blanket your home with sufficient density of Wi-Fi access points to ensure that they never become the bottleneck hop and expose their incompetent queue management. If you get 11Mb/s in the garden that should be plenty to stream music, but throw in some egregious bufferbloat and a perfectly good 11Mb/s rate becomes unusably bad. Ironically, if you pay more for faster Internet service then the problem gets worse, not better, because the effective usable range of your bufferbloate d Wi-Fi access points shrinks as the rate coming into the house goes up. > > Stuart Cheshire > > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink --228850167-561034312-1654734070=:13569--