From: Ben Greear <greearb@candelatech.com>
To: David Lang <david@lang.hm>,
"Rodney W. Grimes" <starlink@gndrsh.dnsmgr.net>
Cc: starlink@lists.bufferbloat.net, "David P. Reed" <dpreed@deepplum.com>
Subject: Re: [Starlink] SatNetLab: A call to arms for the next global> Internet testbed
Date: Tue, 13 Jul 2021 11:06:34 -0700 [thread overview]
Message-ID: <616d0497-0d22-b8be-895b-bb57f2e82480@candelatech.com> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.2107131056020.1440203@qynat-yncgbc>
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...
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?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2021-07-13 18:06 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.5.1626019201.21244.starlink@lists.bufferbloat.net>
2021-07-13 1:23 ` David P. Reed
2021-07-13 1:27 ` Vint Cerf
2021-07-13 1:57 ` David Lang
2021-07-13 12:39 ` Rodney W. Grimes
2021-07-13 18:01 ` David Lang
2021-07-13 18:06 ` Ben Greear [this message]
2021-07-13 18:13 ` David Lang
2021-07-13 18:25 ` Ben Greear
2021-07-13 21:23 ` David Lang
2021-07-09 19:19 [Starlink] SatNetLab: A call to arms for the next global " Dave Taht
2021-07-10 11:49 ` Rodney W. Grimes
2021-07-10 20:27 ` David Lang
2021-07-19 15:50 ` George Burdell
2021-12-11 9:18 ` Ankit Singla
2021-12-13 1:16 ` Dave Taht
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/starlink.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=616d0497-0d22-b8be-895b-bb57f2e82480@candelatech.com \
--to=greearb@candelatech.com \
--cc=david@lang.hm \
--cc=dpreed@deepplum.com \
--cc=starlink@gndrsh.dnsmgr.net \
--cc=starlink@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox