<div dir="ltr">> There is probably also a tradeoff in how long you hold back packets while waiting for more data to show up;<br><br>Also recall that a transmit has to adhere EDCA and NAV.  If energy detect or virtual carrier are active the device "backs off" and arbitrates again. Then there is the encoding and number of spatial streams which influence propagation delay.<br><br>So packet queues aren't typically the bottleneck in uncongested scenarios and aren't the forcing function for end/end latency.  It's typically related to the RF conditions which includes energy by peers, same BSS or otherwise. Then there is OS related stuff with respect to writes and reads that can add latency per thread scheduling.  That's another reason why it helps to measure end/end latency which includes application level writes and reads.<br><br>The following components of latency might be helpful:<br><br>Propagation delay<br>Amount of time required for a message to travel from the sender to receiver, which is a function of distance over speed with which the signal propagates.<br><br>Transmission delay<br>Amount of time required to push all the packet’s bits into the link, which is a function of the packet’s length and data rate of the link.<br><br><div>Processing delay<br>Amount of time required to process the packet header, check for bit-level errors, and determine the packet’s destination.<br><br>Queuing delay<br>Amount of time the packet is waiting in the queue until it can be processed.<br><br>Bob <br><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 2, 2020 at 7:52 AM Tim Higgins <<a href="mailto:tim@smallnetbuilder.com">tim@smallnetbuilder.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    <br>
    <div>On 4/2/2020 6:20 AM, Toke
      Høiland-Jørgensen wrote:<br>
    </div>
    <blockquote type="cite">
      <pre>Tim Higgins <a href="mailto:tim@smallnetbuilder.com" target="_blank"><tim@smallnetbuilder.com></a> writes:

</pre>
      <blockquote type="cite">
        <pre>One of the things I've been wondering about as I work on OFDMA testing is how
heavily a WiFi link needs to be loaded.
As far as I can tell, all (most/many) of the flent scripts basically have
netperf TCP/IP streams running full tilt.

I guess put another way, how effective are the anti-bufferbloat methods at
reducing latency on a moderately loaded link?
</pre>
      </blockquote>
      <pre>Well, the anti-bufferbloat mitigations aim at managing packet queues.
But if the link is not loaded to capacity, packets will generally be
sent out as soon as they arrive, so there won't *be* any queue to
manage. Which means that as far as queueing is concerned, it doesn't
really matter what you do. There are other factors that can impact the
latency of an idle link, of course, but we haven't really touched those
much when working on the bloat stuff..

</pre>
      <blockquote type="cite">
        <pre>In terms of WiFi, do I need to run a link at 90+ airtime congestion to
see OFDMA work it's magic? Or would the lack of available airtime
hinder it working?
</pre>
      </blockquote>
      <pre>Now this is a good question. I would expect that OFDMA to only kick in
if there is actually data queued for multiple stations. I mean,
otherwise it doesn't really gain you much? There is probably also a
tradeoff in how long you hold back packets while waiting for more data
to show up; wait too long and you're just wasting airtime, but if you
don't wait long enough you get no benefit. How the firmware scheduler
manages that is of course vital; but I guess that's what you're trying
to find out? :)

-Toke

</pre>
    </blockquote>
    <font face="Times New Roman, Times, serif">Thanks everyone for the
      replies. OFDMA will be adding yet another layer of complexity to
      the current brew.<br>
      I'll post back after I do some experiments.<br>
    </font>
  </div>


_______________________________________________<br>
Make-wifi-fast mailing list<br>
<a href="mailto:Make-wifi-fast@lists.bufferbloat.net" target="_blank">Make-wifi-fast@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/make-wifi-fast" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/make-wifi-fast</a></blockquote></div>