We (broadcom wifi) run many latency related tests though they're all
internal testing prior to customer release. Also, a suggestion is to
measure latency per the traffic of interest vs using an adjunct ping
stream. Finally, iperf 2.0.14 supports the trip-time option.  This gives
socket write to read or end/end latencies which an application will
experience.  It also supports the end/end queue depth per Little's law
(though there is a bug in the arrival rate that needs to be fixed per the
current git head.)

Bob

On Thu, Jan 30, 2020 at 5:29 PM Dave Taht <dave.taht@gmail.com> wrote:

> Are "RvR vs latency" tests part of any testing regime outside of google
> yet?
>
>
> http://flent-newark.bufferbloat.net/~d/Airtime%20based%20queue%20limit%20for%20FQ_CoDel%20in%20wireless%20interface.pdf
>
> On Thu, Jan 30, 2020 at 5:20 PM Bob McMahon via Make-wifi-fast
> <make-wifi-fast@lists.bufferbloat.net> wrote:
> >
> >
> >
> >
> > ---------- Forwarded message ----------
> > From: Bob McMahon <bob.mcmahon@broadcom.com>
> > To: Dave Taht <dave@taht.net>
> > Cc: Rich Brown <richb.hanover@gmail.com>, Make-Wifi-fast <
> make-wifi-fast@lists.bufferbloat.net>
> > Bcc:
> > Date: Thu, 30 Jan 2020 17:20:09 -0800
> > Subject: Re: [Make-wifi-fast] Wi-Fi 6 - how many of our assumptions does
> it violate?
> > 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.
> >
> > Bob
> >
> > On Thu, Jan 30, 2020 at 2:28 PM Dave Taht <dave@taht.net> wrote:
> >>
> >> Rich Brown <richb.hanover@gmail.com> writes:
> >>
> >> >> On Jan 24, 2020, at 9:06 AM, Rich Brown <richb.hanover@gmail.com>
> wrote:
> >> >>
> >> >> I saw this overview of the now-in-testing Wi-Fi 6 at
> >> >>
> https://www.howtogeek.com/368332/wi-fi-6-what%E2%80%99s-different-and-why-it-matters/
> >> >>
> >> >> 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@lists.bufferbloat.net
> >> > https://lists.bufferbloat.net/listinfo/make-wifi-fast
> >> _______________________________________________
> >> Make-wifi-fast mailing list
> >> Make-wifi-fast@lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/make-wifi-fast
> >
> >
> >
> >
> > ---------- Forwarded message ----------
> > From: Bob McMahon via Make-wifi-fast <
> make-wifi-fast@lists.bufferbloat.net>
> > To: Dave Taht <dave@taht.net>
> > Cc: Rich Brown <richb.hanover@gmail.com>, Make-Wifi-fast <
> make-wifi-fast@lists.bufferbloat.net>
> > Bcc:
> > Date: Thu, 30 Jan 2020 17:20:24 -0800 (PST)
> > Subject: Re: [Make-wifi-fast] Wi-Fi 6 - how many of our assumptions does
> it violate?
> > _______________________________________________
> > Make-wifi-fast mailing list
> > Make-wifi-fast@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/make-wifi-fast
>
>
>
> --
> Make Music, Not War
>
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-435-0729
>