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 AD0A23B29E for ; Tue, 13 Jul 2021 14:13:25 -0400 (EDT) Received: from dlang-laptop.local (unknown [10.2.0.162]) by mail.lang.hm (Postfix) with ESMTP id 982C4FECF8; Tue, 13 Jul 2021 11:13:24 -0700 (PDT) Date: Tue, 13 Jul 2021 11:13:19 -0700 (PDT) From: David Lang X-X-Sender: dlang@dlang-laptop To: Ben Greear cc: David Lang , "Rodney W. Grimes" , starlink@lists.bufferbloat.net, "David P. Reed" In-Reply-To: <616d0497-0d22-b8be-895b-bb57f2e82480@candelatech.com> Message-ID: References: <202107131239.16DCdq6D058102@gndrsh.dnsmgr.net> <616d0497-0d22-b8be-895b-bb57f2e82480@candelatech.com> User-Agent: Alpine 2.21.1 (DEB 209 2017-03-23) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323328-1912029563-1626200004=:1440203" Subject: Re: [Starlink] SatNetLab: A call to arms for the next global> Internet testbed 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: Tue, 13 Jul 2021 18:13:25 -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. --8323328-1912029563-1626200004=:1440203 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 13 Jul 2021, Ben Greear wrote: > On 7/13/21 11:01 AM, David Lang wrote: >> On Tue, 13 Jul 2021, Rodney W. Grimes wrote: >> >>> It wasnt suggested "lowering the bit rate", it was suggested to make the >>> packets smaller, which actually does address the hidden transmitter >>> problem >>> to some degree as it *would* reduce your air time occupancy, but the damn >>> wifi LL aggregation gets in your way cause it blows them back up.  When I >>> am having to deal/use wifi in a hidden transmitter prone situation I >>> always >>> crank down the Fragmentation Threshold setting from the default of 2346 >>> bytes >>> to the often the minimum of 256 with good results. >> >> The problem is that with wifi at modern data rates, you have a header at a >> low data rate and then data at a much higher data rate (in extreme cases, a >> >50x difference), so the amount of data that you send has a pretty minor >> difference in the airtime used. So you really do want to send a large >> amount of data per transmission to minimize the overhead >> >> IT's not quite as bad if you have disabled 802.11b speeds on the entire >> network as that raises the header/housekeeping transmissions from 1Mb/s to >> 11Mb/s > > The quiesce period waiting for medium access also takes some time, so that is > another reason to try to put lots of frames on air in the same tx operation... yep, mentally I lump that into the header/housekeeping functionality as that's all fixed-time no matter how much data you are transmitting. > David, I'm curious about the rate-ctrl aspect of this. Have you found any > implementations of rate-ctrl that try harder to decrease amsdu groupings > and/or keep MCS higher (maybe based on RSSI?) in a congested environment to > deal better with hidden node problems? I have not experimented with that. I help run the network at the SCALE conference each year (3500 geeks with their gear over ~100k sq ft of conference center with >100 APs running openwrt), and I'm open to suggestions for monitoring/tweaking the network stack, as long as it's easy to revert to default if we run into grief. David Lang --8323328-1912029563-1626200004=:1440203--