Re: [Make-wifi-fast] [Cake] [Rpm] [Bloat] The most wonderful video ever about bufferbloat

[David Lang <david@lang.hm>]

Thanks, and how long does it take to transmit the wifi header (at 1Mb/s and at 
11Mb/s)? That's also airtime that's not availalbe to transmit user data.

And then compare that to the time it takes to transmit a 1500 byte ethernet 
packet worth of data over a 160MHz wide channel

Going back to SM's question, there is per-transmission overhead that you want to 
amatorize across multiple ethernet packets, not pay for each packet.

David Lang

On Wed, 19 Oct 2022, David P. Reed wrote:

> 4 microseconds!
> 
> On Wednesday, October 19, 2022 3:23pm, "David Lang via Cake" <cake@lists.bufferbloat.net> said:
>
>
>
>> you have to listen and hear nothing for some timeframe before you transmit, that
>> listening time is define in the standard. (isn't it??)
>> 
>> David Lang
>> 
>> On Wed, 19 Oct 2022, Bob McMahon wrote:
>> 
>> > I'm not sure where the gap in milliseconds is coming from. EDCA gaps are
>> > mostly driven by probabilities
>> > <https://link.springer.com/article/10.1007/s10270-020-00817-2>. If
>> > energy detect (ED) indicates the medium is available then the gap prior to
>> > transmit, assuming no others competing & winning at that moment in time, is
>> > driven by AIFS and the CWMIN - CWMAX back offs which are simple probability
>> > distributions. Things change a bit with 802.11ax and trigger frames but the
>> > gap is still determined by the backoff and should be less than milliseconds
>> > per that. Things like NAVs will impact the gap too but that happens when
>> > another is transmitting.
>> >
>> >
>> > [image: image.png]
>> >
>> > Agreed that the PLCP preamble is at low MCS and the payload can be orders
>> > of magnitude greater (per different QAM encodings and other signal
>> > processing techniques.)
>> >
>> > Bob
>> >
>> > On Wed, Oct 19, 2022 at 12:09 AM David Lang <david@lang.hm> wrote:
>> >
>> >> On Tue, 18 Oct 2022, Sebastian Moeller wrote:
>> >>> Hi Bob,
>> >>>
>> >>>> Many network engineers typically, though incorrectly, perceive a
>> >> transmit
>> >>>> unit as one ethernet packet. With WiFi it's one Mu transmission
>> or one
>> >> Su
>> >>>> transmission, with aggregation(s), which is a lot more than one
>> ethernet
>> >>>> packet but it depends on things like MCS, spatial stream powers,
>> Mu
>> >> peers,
>> >>>> etc. and is variable. Some data center designs have optimized the
>> >>>> forwarding plane for flow completion times so their equivalent
>> transmit
>> >>>> unit is a mouse flow.
>> >>>
>> >>> [SM] Is this driven more by the need to aggregate packets to amortize
>> >> some cost over a larger payload or to reduce the scheduling overhead or
>> to
>> >> regularize things (as in fixed size DTUs used in DSL with G.INP
>> >> retransmissions)?
>> >>
>> >> it's to amortize costs over a larger payload.
>> >>
>> >> the gap between transmissions is in ms, and the transmission header is
>> >> transmitted at a slow data rate (both for backwards compatibility with
>> >> older
>> >> equipment that doesn't know about the higher data rate modulations)
>> >>
>> >> For a long time, the transmission header was transmitted at 1Mb (which is
>> >> still
>> >> the default in most equipment), but there is now an option to no longer
>> >> support
>> >> 802.11b equipment, which raises the header transmission time to 11Mb.
>> >>
>> >> These factors are so imbalanced compared to the top data rates available
>> >> that
>> >> you need to transmit several MB of data to have actual data use 50% of
>> the
>> >> airtime.
>> >>
>> >> David Lang
>> >>
>> >
>> >
>> _______________________________________________
>> Cake mailing list
>> Cake@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cake
>>