<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <font face="Times New Roman, Times, serif">I take your point, Bob,
      and agree single-ended latency measurements like you produce with
      iperf would be more technically correct.<br>
      <br>
      I write and review for a consumer audience, where ping is the
      standard for latency aka lag measurement. So that's why I'm using
      ping.<br>
      That, and the fact that iperf isn't integrated into octoScope's
      toolset yet. But they're working on it and all their STA
      instruments are properly time-synced, so the measurements will be
      accurate.<br>
      <br>
      Thank your for all your work in iperf, BTW. The features you've
      added are a welcome improvement.<br>
    </font>
    <div class="moz-signature">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <div><font size="-1" face="Times New Roman, Times, serif">===========<br>
          Tim <br>
        </font></div>
    </div>
    <div class="moz-cite-prefix">On 4/29/2020 8:32 PM, Bob McMahon
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAHb6LvqmJvTxAy-H51qUiTmGRoNfi1vaz3Ux6z7CnNYWqNeH_w@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">I'm thinking ping may not be ideal for
        benchmarking OFDMA effects on latency.  Also, the end/end
        latency preferred seems to me the socket write() to final socket
        read() per that write(). Also, for TCP, there are the connect
        times. I realize network stack guys focus on stack related
        measurements, e.g. RTT, but the latencies users experience
        include the application level and system level os interactions.<br>
        <br>
        Just some food or thought.<br>
        <br>
        Bob<br>
        <br>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Wed, Apr 29, 2020 at 5:07
          PM Dave Taht <<a href="mailto:dave.taht@gmail.com"
            moz-do-not-send="true">dave.taht@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">throughput
          and latency are interrelated, whats the throughput?<br>
          <br>
          On Wed, Apr 29, 2020 at 2:40 PM Tim Higgins <<a
            href="mailto:tim@smallnetbuilder.com" target="_blank"
            moz-do-not-send="true">tim@smallnetbuilder.com</a>>
          wrote:<br>
          ><br>
          > Hi all,<br>
          ><br>
          > I finally have my testbed working the way I want and am
          starting to run tests to see if OFDMA does anything useful.<br>
          ><br>
          > This will all be covered in detail in an upcoming
          SmallNetBuilder article. But I wanted to sanity check
          something with this esteemed group.<br>
          ><br>
          > The tests are basically the flent rtt_fair_var up and
          down tests ported to the octoScope platform I use for WiFi
          testing.<br>
          > The initial work was done on flent, with a lot of
          hand-holding from Toke. (Thank you, Toke!)<br>
          ><br>
          > Using 4 Intel AX200 STAs on Win10. iperf3 is running
          traffic using TCP/IP with unthrottled bandwidth. I've taken
          Bjørn's idea and have each STA using a different DSCP priority
          level, but with TCP/IP traffic, not UDP. I'm sticking to using
          CS0-7 equivalents and confirmed that the iperf3 --dscp values
          properly translate to the intended WiFi priority levels.  Each
          STA has a different priority, either CS0,3,5 or 6 (best
          effort, excellent effort, video and voice).<br>
          ><br>
          > Ping is used to measure latency and always runs from AP
          to STA. Only TCP/IP traffic direction is reversed between the
          down and uplink tests.<br>
          ><br>
          > One thing that jumps out immediately is that uplink
          latencies are *much* lower than downlink, with either OFDMA on
          or off. Attached are three examples. The CDFs are average
          latency of the 4 STAs.<br>
          ><br>
          > The NETGEAR R7800 is a 4x4 AC Qualcomm-based. I'm using
          this as a baseline product.<br>
          ><br>
          > The NETGEAR RAX15 is 2x2 AX Broadcom-based. You can see
          what I mean when I say OFDMA doesn't help.<br>
          ><br>
          > Does this much difference between up and downlink latency
          pass the sniff test?<br>
          ><br>
          > ===<br>
          > Tim<br>
          > _______________________________________________<br>
          > Make-wifi-fast mailing list<br>
          > <a href="mailto:Make-wifi-fast@lists.bufferbloat.net"
            target="_blank" moz-do-not-send="true">Make-wifi-fast@lists.bufferbloat.net</a><br>
          > <a
            href="https://lists.bufferbloat.net/listinfo/make-wifi-fast"
            rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.bufferbloat.net/listinfo/make-wifi-fast</a><br>
          <br>
          <br>
          <br>
          -- <br>
          Make Music, Not War<br>
          <br>
          Dave Täht<br>
          CTO, TekLibre, LLC<br>
          <a href="http://www.teklibre.com" rel="noreferrer"
            target="_blank" moz-do-not-send="true">http://www.teklibre.com</a><br>
          Tel: 1-831-435-0729<br>
          _______________________________________________<br>
          Make-wifi-fast mailing list<br>
          <a href="mailto:Make-wifi-fast@lists.bufferbloat.net"
            target="_blank" moz-do-not-send="true">Make-wifi-fast@lists.bufferbloat.net</a><br>
          <a
            href="https://lists.bufferbloat.net/listinfo/make-wifi-fast"
            rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.bufferbloat.net/listinfo/make-wifi-fast</a></blockquote>
      </div>
    </blockquote>
    <br>
  </body>
</html>