<html>

  <head>

    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

  </head>

  <body>

    <font face="Times New Roman, Times, serif">I pinged Jonathan Foulkes

      @ Evenroute and he said basically the same thing you said, i.e.<br>

      <br>

      <blockquote type="cite">

        <pre class="moz-quote-pre" wrap="">The Wifi stack in the IQrouter is vanilla OpenWRT for the MT76, which does have the codel and airtime fairness work of the MakeWiFiFast group. but it’s not actively shaped beyond that.</pre>

      </blockquote>

      I have a V3, so I'll throw it in the chamber and see what happens.

      I already have data for my AC "standard" router, the NETGEAR

      R7800.<br>

    </font><br>

    <div class="moz-cite-prefix">On 5/15/2020 12:25 PM, Dave Taht wrote:<br>

    </div>

    <blockquote type="cite"

cite="mid:CAA93jw72nBDNxs3P6QiQn-HWnRdmrd4TDwiJYA6BVbgYkuHirA@mail.gmail.com">

      <pre class="moz-quote-pre" wrap="">On Fri, May 15, 2020 at 8:34 AM Tim Higgins <a class="moz-txt-link-rfc2396E" href="mailto:tim@timhiggins.com"><tim@timhiggins.com></a> wrote:

</pre>

      <blockquote type="cite">

        <pre class="moz-quote-pre" wrap="">

Hi Erkki,

Thanks for your comments.

A simple test is exactly what I'm after. The Part 1 article was basically a look behind the scenes to describe why I used the benchmark I did for the Part2 article. It will compare an AC router and multiple AX routers. If there's an off-the-shelf consumer router with that implements SQM/cake on Wi-Fi, I'm happy to try it. I have an evenroute IQrouter here, but I'm not sure if it implements SQM on Wi-Fi. I'll ask.

</pre>

      </blockquote>

      <pre class="moz-quote-pre" wrap="">

"SQM" isn't the thing. SQM is for better managing the ISP uplinks/downlinks.

it's the fq_codel and aqm scheduler for wifi. I'm under the impression

that the evenroute v2 production version now has some of the

aql/fq_codel related code backported to it. I've been off tuning that

up over here: <a class="moz-txt-link-freetext" href="https://forum.openwrt.org/t/aql-and-the-ath10k-is-lovely/">https://forum.openwrt.org/t/aql-and-the-ath10k-is-lovely/</a>

but that code has not made it back into mainline.

v3 has long had it, but was never optimized properly because I didn't

have one. Still I've never had a testbed as nice as yours,

it would be great, absolutely great, to get some feedback on your

methods you are applying to see how decent it is today! :)

The principal mis-feature in the current codebases for openwrt in

wifi's case is some code we left in there keeping the codel target

too high for 5ghz wifi, and far too large hw retries in the firmware

and driver for these two chipsets. However there is no express

supportfor mu-mimo in our versions as, like you, we discoverd the

concept didn't work - and couldn't ever work as designed - so we

discarded it in favor of better per station scheduling in the first

place.

<a class="moz-txt-link-freetext" href="https://arxiv.org/pdf/1703.00064.pdf">https://arxiv.org/pdf/1703.00064.pdf</a>

There were so many things left unfinished in that project. We could

have handled 802.11e much better than we do.

</pre>

    </blockquote>

    <br>

  </body>

</html>