From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) (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 99A953B29E for ; Tue, 13 Jul 2021 14:25:40 -0400 (EDT) X-Virus-Scanned: Proofpoint Essentials engine Received: from mx1-us1.ppe-hosted.com (unknown [10.7.65.202]) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id DC9E51C0069; Tue, 13 Jul 2021 18:25:38 +0000 (UTC) Received: from mail3.candelatech.com (mail2.candelatech.com [208.74.158.173]) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTP id 54D2F8006A; Tue, 13 Jul 2021 18:25:38 +0000 (UTC) Received: from [192.168.100.195] (50-251-239-81-static.hfc.comcastbusiness.net [50.251.239.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail3.candelatech.com (Postfix) with ESMTPSA id A49D113C2B1; Tue, 13 Jul 2021 11:25:37 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 mail3.candelatech.com A49D113C2B1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=candelatech.com; s=default; t=1626200737; bh=zmHtYZanBN20wdY9U3uifmb2GdZi84TedMDd8VE4nHM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=BVzC0sqFkqHeDusfV0qgAd1Qi8h6LqRm6rus1TWEVmgtXx9wWK3RGbzH9Re5nGAO5 u2Ym+8aA99MU8yYBW/IWcsGW7j5IkvE0b8JSzBjJXLxQhOlGKadCGvTH0S3x91U9SG 0NxpBtmCOfAbXRF6TwI6gppAUyTBbGpTKPd0H4sE= To: David Lang Cc: "Rodney W. Grimes" , starlink@lists.bufferbloat.net, "David P. Reed" References: <202107131239.16DCdq6D058102@gndrsh.dnsmgr.net> <616d0497-0d22-b8be-895b-bb57f2e82480@candelatech.com> From: Ben Greear Organization: Candela Technologies Message-ID: <157aed96-8f10-c4f9-a6cb-f1aeec7b433d@candelatech.com> Date: Tue, 13 Jul 2021 11:25:37 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-MDID: 1626200739-DfNjIUL2Wgrv 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:25:40 -0000 On 7/13/21 11:13 AM, David Lang wrote: > 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. Not exactly fixed though? With a few transmitters trying to get on medium, air-time may theoretically improve a bit for first few transmitters due to random backoff timers finding clear air after shorter over-all quiesce period, but I would image it gets pretty bad with several hundred radios detecting collisions and increasing their backoff before accessing medium again? > >> 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. Mucking with rate-ctrl typically involves hacking firmware in modern APs. Impossible for most due to lack of source, and tricky stuff even for those with source. And if you do it wrong, you can completely ruin a network. Maybe something like MTK AX chipset will someday offer a host-based rate-ctrl where experimenters could put some effort in this direction. I don't know of any other chipset that would have any chance of user-based rate-ctrl. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com