<div dir="ltr">A few notes:<div><br>o) Bufferbloat is about queue depth and an input rate exceeding the service rate such that a queue becomes a standing queue. </div><div>o) Latency is end/end and can mean different things. The base assumption by many in the network engineering community is that all queuing is in the network stack somewhere.  But if the application is held back it's effectively a queue too. Things like RTT mostly affect TCP byte transfer.  The amount of blocking by the application isn't measured. <br>o) Aggregation and transmit "lazy" on a driver doesn't typically occur for the Voice access class.  Many test driver latency with that AC as well as BE</div><div>o) iperf 2.0.14 has a <a href="https://www.youtube.com/watch?v=LOGpXiAk_cc">trip time latency</a> which is write time (or start of burst/frame) vs final read time.  This requires --trip-time as well as synchronized clocks. It also produces bytes in progress from an application end/end perspective using <a href="https://en.wikipedia.org/wiki/Little%27s_law">little's law</a>.</div><div><br><a href="https://www.youtube.com/channel/UCaqlH3a442xaZ9humrxRHGQ/videos">More iperf 2.0.14 videos here</a><br><br></div><div>Bob </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 1, 2020 at 1:22 PM Aaron Wood <<a href="mailto:woody77@gmail.com">woody77@gmail.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 dir="ltr"><div dir="ltr">I think that will depend on the wifi driver (on the tx side), and whether or not it's not sending 802.11n/ac aggregate frames immediately (and how long it's waiting).  Some drivers will buffer up packets for some period of time before sending them out.  So on a lightly loading transmitter, in a quiet RF airspace, the driver might add more latency than is necessary.<div><br></div><div>One thing I've seen is that the wifi aggregates, because they are so large (64KB), can end up creating some odd RTT sawtooth patterns as a full aggregate will contain packets with many send times, all received at once.</div><div><br></div><div>Here's an excellent summary: <a href="https://datatracker.ietf.org/meeting/101/materials/slides-101-iccrg-an-update-on-bbr-work-at-google-00" target="_blank">https://datatracker.ietf.org/meeting/101/materials/slides-101-iccrg-an-update-on-bbr-work-at-google-00</a></div><div><br></div><div>-Aaron</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 1, 2020 at 10:48 AM Tim Higgins <<a href="mailto:tim@smallnetbuilder.com" target="_blank">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>
    <font face="Times New Roman, Times, serif">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.<br>
      As far as I can tell, all (most/many) of the flent scripts
      basically have netperf TCP/IP streams running full tilt.<br>
      <br>
      I guess put another way, how effective are the anti-bufferbloat
      methods at reducing latency on a moderately loaded link?<br>
      <br>
      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?<br>
    </font>
    <div><br>
      
      <div><font size="-1" face="Times New Roman, Times, serif">===========<br>
          Tim <br>
        </font></div>
    </div>
  </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>
_______________________________________________<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>