[Make-wifi-fast] Wi-Fi 6 - how many of our assumptions does it violate?
bob.mcmahon at broadcom.com
Thu Jan 30 20:20:09 EST 2020
It's part of the reasons iperf 2.0.14 has so many new latency, trip-time,
start-time, connect, etc related features. Peak avg throughput is no longer
a valid proxy for "performance."
>From a testing view, attenuation or range is no longer sufficient either.
Phase shifters are needed per things like VR/AR as truly optimizing the
number of spatial streams is needed too.
The loss function(s) to be optimized (minimized) is far from trivial in
both the definition and in [re]-computing in "real-time"
WiFi engineers have more work to do.
On Thu, Jan 30, 2020 at 2:28 PM Dave Taht <dave at taht.net> wrote:
> Rich Brown <richb.hanover at gmail.com> writes:
> >> On Jan 24, 2020, at 9:06 AM, Rich Brown <richb.hanover at gmail.com>
> >> I saw this overview of the now-in-testing Wi-Fi 6 at
> >> Its multiple MIMO streams and maybe talking to multiple devices at a
> >> time seem as if they might be outside the assumptions we use.
> > It's worse than I thought. I just watched this explainer video from
> > ExtremeNetworks: https://www.youtube.com/watch?v=owBrkFk9afM
> > If I understand correctly, they want the AP to solve a hard
> > (bin-packing) problem, in real-time, with unclear rules for maximizing
> > client goals (should the VoIP packet go first?). And no mention of
> > airtime fairness or latency...
> > Or am I missing something? Thanks.
> No, they punted on these things in the design.
> > Rich
> > _______________________________________________
> > Make-wifi-fast mailing list
> > Make-wifi-fast at lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/make-wifi-fast
> Make-wifi-fast mailing list
> Make-wifi-fast at lists.bufferbloat.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Make-wifi-fast