From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id C92AE3B2A4 for ; Mon, 3 Feb 2020 13:45:59 -0500 (EST) Received: by mail-wr1-x42b.google.com with SMTP id z9so7415764wrs.10 for ; Mon, 03 Feb 2020 10:45:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lFPaV2XaJhKcOcvAicW5JRP4xZYwJeUwDKXz8IiPWhw=; b=A09kIzV2fjrm3pAYSiPTDtGdWl1VY0zQ+r9EpgQBTOZ7DaiAw2MXZRGDy4xoGa2PZM 8XbVctxUblP44qF63C43/bigf3ko0RJD8ErzoySDRyP8xf+kifqcvyuzQJqmwXMH6u6Z dItaIIGVTDIJoFTs5AecsZxg1qRgPVp1NUW3E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lFPaV2XaJhKcOcvAicW5JRP4xZYwJeUwDKXz8IiPWhw=; b=FlWhkcweBn1/cXHQu73ngigSOiNMLsvB6CfGXhQi/Ub5yIuE30kFrdQdlFdQfoNOk+ zSa+5F/QHoQArLOCu4s57pMpDaIfPurux6FlTwCgE120K3HF+nCNFY+Jgz+y1u7dDjnK 0l1/ceHoTbacrkof8762ksy5xg6PAg6p5LCHWVB5qQ4t0QS9ERgmJZJVr+5AP0HcLrfh fTVJaqN69vk895TiTe2/C689sr5XsD0c46duSO7uSWYhKw21zLJ0Pn3BwOoOFypIzbXn KfdZWO63A/ZyvWw7WK2q7Q0ZNYKSYKgwcYALjxxriBKbKe9yKicD/d5bIcPA1FKNkwH7 21HQ== X-Gm-Message-State: APjAAAV2B8YySLbUOsaR43fW4/d1NIeizEGIHg0NpUZ83C4zedNbMQMr oWNO6vUsFxV9KILyVfLbvZn/1Gdcjj10yBJC3ivzaA== X-Google-Smtp-Source: APXvYqyTYcN6ZQwlP1OgwNtdeT98sMoxeQ8oj6SZlvkDzppb/w92gLGet02ZtM2SypKz1ft2UWU/SnJlbteM9jSXuEc= X-Received: by 2002:a5d:6ca1:: with SMTP id a1mr16622004wra.36.1580755558743; Mon, 03 Feb 2020 10:45:58 -0800 (PST) MIME-Version: 1.0 References: <69103D46-8F04-4468-802B-142CC2DABF0F@gmail.com> <0928D44A-4F3A-462D-854E-91B653E40B1C@gmail.com> <87a764ziiy.fsf@taht.net> In-Reply-To: From: Bob McMahon Date: Mon, 3 Feb 2020 10:45:47 -0800 Message-ID: Subject: Re: [Make-wifi-fast] Wi-Fi 6 - how many of our assumptions does it violate? To: Dave Taht Cc: Dave Taht , Rich Brown , Make-Wifi-fast Content-Type: multipart/alternative; boundary="0000000000008e75f6059db055d3" X-List-Received-Date: Mon, 03 Feb 2020 18:46:00 -0000 --0000000000008e75f6059db055d3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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%20= for%20FQ_CoDel%20in%20wireless%20interface.pdf > > On Thu, Jan 30, 2020 at 5:20 PM Bob McMahon via Make-wifi-fast > wrote: > > > > > > > > > > ---------- Forwarded message ---------- > > From: Bob McMahon > > To: Dave Taht > > Cc: Rich Brown , 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 doe= s > 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 wrote: > >> > >> Rich Brown writes: > >> > >> >> On Jan 24, 2020, at 9:06 AM, Rich Brown > 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=3DowBrkFk9afM > >> > > >> > If I understand correctly, they want the AP to solve a hard > >> > (bin-packing) problem, in real-time, with unclear rules for maximizi= ng > >> > 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 > > Cc: Rich Brown , 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 doe= s > 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=C3=A4ht > CTO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-831-435-0729 > --0000000000008e75f6059db055d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We (broadcom wifi) run many latency related tests though t= hey're all internal testing prior to customer release. Also, a suggesti= on is to measure latency per the traffic of interest vs using an adjunct pi= ng stream. Finally, iperf 2.0.14 supports the trip-time option.=C2=A0 This = gives socket write to read or end/end latencies which an application will e= xperience.=C2=A0 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 t= he 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%2= 0queue%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 <d= ave@taht.net>
> Cc: Rich Brown <richb.hanover@gmail.com>, Make-Wifi-fast <make-wifi-fa= st@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 do= es it violate?
> It's part of the reasons iperf 2.0.14 has so many new latency, tri= p-time, start-time, connect, etc related features. Peak avg throughput is n= o longer a valid proxy for "performance."
>
> From a testing view, attenuation or range is no longer sufficient eith= er.=C2=A0 Phase shifters are needed per things like VR/AR as truly optimizi= ng the number of spatial streams is needed too.
>
> The loss function(s) to be optimized (minimized) is far from trivial i= n 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-wh= y-it-matters/
>> >>
>> >> Its multiple MIMO streams and maybe talking to multiple d= evices 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.co= m/watch?v=3DowBrkFk9afM
>> >
>> > If I understand correctly, they want the AP to solve a hard >> > (bin-packing) problem, in real-time, with unclear rules for m= aximizing
>> > client goals (should the VoIP packet go first?). And no menti= on 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/lis= tinfo/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.bufferblo= at.net>
> To: Dave Taht <d= ave@taht.net>
> Cc: Rich Brown <richb.hanover@gmail.com>, Make-Wifi-fast <make-wifi-fa= st@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 do= es it violate?
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/ma= ke-wifi-fast



--
Make Music, Not War

Dave T=C3=A4ht
CTO, TekLibre, LLC
ht= tp://www.teklibre.com
Tel: 1-831-435-0729
--0000000000008e75f6059db055d3--