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