From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) (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 02CD53B29D for ; Mon, 16 Dec 2019 16:05:19 -0500 (EST) Received: by mail-wm1-x342.google.com with SMTP id m24so787914wmc.3 for ; Mon, 16 Dec 2019 13:05:19 -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=gc4VzFRtoYe6FzCiiQKG/H15+yo8acO1kaxesgsUMVc=; b=Adnl+dAvL+iHkvnQsIMvq8rqev9IOE0yjtP55oRT7LUatFe7j8avTUw3/lWbZvtIJ4 0iM963Hki2ZZ/UnBtjDCXgXkS0oo2cF1RhVD4sueLgR7NDRTNcTkyT6tQM0ZuxvmvpPf YYdS/7MaXPOxb+Dbf8AOXHadiucLbCKIdLgrk= 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=gc4VzFRtoYe6FzCiiQKG/H15+yo8acO1kaxesgsUMVc=; b=QVBi7cUb03DzSkUkwIv/C/24IDIUosWlr6J3a+BaOAuOuoJK/CRJOC9ubrnlK48wqP F+ZQdJFN1AkoraKZvvClffHIYb4JT0zdCf6tgvGISiqSUBXKZaHchovtPXwbyQ562jj5 d42PhtDYL4LKiM6D+JhAEn+mQq+pZDPUrL65d+MJPqpIxOw1zHc2HRqzjQ9u6vNXQebe 4FU002Jnv/OFmFgWuCwnn084yLxfJIP6fLsUfwInAusl4bQPD4i21KwCYlbpO4QxWnae EurgD2YLTBn5kd2OjH1D/1vxg1ahSoreiqI2uZtV0AdtYT3rlixg4ymtStIosztde/lf 485w== X-Gm-Message-State: APjAAAXbYlF2n3EIXHTSeRsp7teFVI3mS/QI+8zz831IbitlQUTKkmUt BA3X6BBS7CQmMkUqxGDKK/9heW+lYV1L7R+GWqVRew== X-Google-Smtp-Source: APXvYqxjjmOOZy3nL23G3yNYeS4C/ts2XfmAtBU+JukP7PbHpt/LPICo5LdfaiGru2vmtvY2rnOaqNIZ2fYgVtvFagQ= X-Received: by 2002:a05:600c:210e:: with SMTP id u14mr1087935wml.28.1576530318472; Mon, 16 Dec 2019 13:05:18 -0800 (PST) MIME-Version: 1.0 References: <2844d909-e0f3-da85-2647-a3df88721791@smallnetbuilder.com> <87pngo883u.fsf@toke.dk> <0db6ac35-04b6-bf65-ebde-4066d69f771a@smallnetbuilder.com> In-Reply-To: <0db6ac35-04b6-bf65-ebde-4066d69f771a@smallnetbuilder.com> From: Bob McMahon Date: Mon, 16 Dec 2019 13:05:06 -0800 Message-ID: Subject: Re: [Make-wifi-fast] AX latency testing To: Tim Higgins Cc: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Make-Wifi-fast Content-Type: multipart/alternative; boundary="0000000000009c8bf60599d89188" X-List-Received-Date: Mon, 16 Dec 2019 21:05:20 -0000 --0000000000009c8bf60599d89188 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable iperf 2.0.13 and iperf 2.0.14a (currently in development) have support for end/end or write to read latencies in both mean/min/max/stdev and histogram formats. It does require realtime clock sync which can be done if a few ways. There is also support for clock_nanosleep() based burst scheduling. We use programmable attenuators to affect the distances and programmable phase shifter to affect the channel mixing or MIMO mixing. Don't know if any of this helps or not. Bob On Mon, Dec 16, 2019 at 12:54 PM Tim Higgins wrote: > > On 12/16/2019 12:59 PM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > Tim Higgins writes: > > > Hi all, > > Dave T=C3=A4ht suggested that I post the discussion we've started to this= broader > group. > > I've been spending the past few months trying to develop methods to verif= y one > of the key promises of OFDMA; improved efficiency. > The tests have mostly focused on trying to see improvement in total throu= ghput > using various traffic mixes using four OFDMA STAs. > > I've been using Samsung S10e's as STAs and primarily iperf3 TCP/IP and UD= P > traffic. I did some work with the Intel AX200 as a STA using both Window= s 10 > and Linux for RvR testing and found the Linux driver basically broken for > uplink. (See the Win10/Linux comparison in the RAX40 section ofhttps://ww= w.smallnetbuilder.com/wireless/wireless-reviews/33220-wi-fi-6-performance-r= oundup-five-routers-tested?start=3D1 > > FWIW, Johannes was debugging some TCP issues on Intel 802.11ax the other > day, and was getting ~1.4Gbps of throughput:https://lore.kernel.org/linux= -wireless/90485ecbfa2a13c4438b840c8a9d37677e833ea5.camel@sipsolutions.net/T= / > > So I guess maybe there are improvements coming in that space? > > TH: Yes, I'm monitoring that thread. I'm about to try a 5.2.14 kernel wit= h > this patch > https://patchwork.kernel.org/patch/11253471/ > > I think there are others in the works. Hope the end product will be > available in a backport. > > So, for now, I'm limited to using the Samsung S10 as STAs. > > ANYWAY, I haven't been having much luck finding total throughput gains, s= o > thought I'd bang my head against a different wall for awhile, which bring= s me > to latency. > > My initial work was pretty simple, just running pings to four OFDMA STAs = with > OFDMA on/off on the AP, which showed no improvement. That's once I realiz= ed > the large ping times and variation I was seeing initially was due to > aggressive power-save kicking in on the STAs with no traffic running. So = I > also tried various TCP rates starting at 1 Mbps per STA to keep the STA a= wake. > > Coincidentally, Dave reached out the other day and suggested I look at th= e > toolsets used for the make-wifi-fast project. > > I've spent a few hours looking at the flent and rrul sites and I'm inter= ested > in exploring using the tools/techniques used for the make-wifi-fast work = to > date to see if AX adds anything to the latency improvement party. If any= one > is willing to provide some pointers on the proper use of the tools, I'd > appreciate it. > > I think the Flent batch file used to run the tests are part of the data > file at the bottom of this page:https://www.cs.kau.se/tohojo/airtime-fair= ness/ > > TH: Thanks for the reference, I'll look into that > > The setup I was using had a server that ran the tests, which was one > Ethernet hop from the AP. The clients were passive, run running > 'netserver' so the server could run 'netperf' against each of them. This > flips up/down in the tests but otherwise works fairly well. I used a > separate (wired) control network for telling the clients to > connect/disconnect... > > More details about the setup here:https://blog.tohojo.dk/2017/11/building= -a-wireless-testbed-with-wires.html > > TH: Again, thanks. > > For example, I didn't see mention of the bitrates used for the traffic st= reams > in the tests. Do I just tell each stream to run full blast (1 Gbps)? > > Well for TCP tests, yeah. The only UDP tests I did were flood tests, > where I just had iperf blasting away at way above the link rate, then > measured how many packets made it through. > > TH: Got it. Blast away on both TCP and UDP. Not sure how that will work > with OFDMA trying to split that bandwidth into multiple RUs that have > smaller bandwidth, but guess I'll find out. > > Also, since most implementations of (consumer at least) OFDMA require mul= tiple > STAs to trigger OFDMA frames, I could use some help understanding whether > multiple streams should be applied per STA, or spread among the 4 STAs I'= m > using in my testing. > > Why not just try both and see what works? :) > > TH: Why didn't I think of that? :) OK. > > Also (2), has anyone used Android STAs for make-wifi-fast testing? > > Nope. But if you can get netperf cross-compiled it should be simple > enough to run 'netserver' on them, I would think? > > TH: Unfortunately, that requires more skills than I have. Maybe someone > else on this list has already done it? > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast --0000000000009c8bf60599d89188 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
iperf= 2.0.13 and iperf 2.0.14a (currently in development) have support for e= nd/end or write to read latencies in both mean/min/max/stdev and histogram = formats. It does require realtime clock sync which=C2=A0can be done if a fe= w ways.=C2=A0 There is also support for clock_nanosleep() based burst sched= uling.

We use programmable attenuators to affect the distances and p= rogrammable phase shifter to affect the channel mixing or MIMO mixing.=C2= =A0 =C2=A0

Don't know if any of this helps or not.

Bob
On = Mon, Dec 16, 2019 at 12:54 PM Tim Higgins <tim@smallnetbuilder.com> wrote:
=20 =20 =20

On 12/16/2019 12:59 PM, Toke H=C3=B8iland-J=C3=B8rgensen wrote:
Tim Higgins <tim@smallnetbuilder.com> writes:


Hi all,

Dave T=C3=A4ht suggested that I post the discussion we've started to th=
is broader
group.

I've been spending the past few months trying to develop methods to ver=
ify one
of the key promises of OFDMA; improved efficiency.
The tests have mostly focused on trying to see improvement in total through=
put
using various traffic mixes using four OFDMA STAs.

I've been using Samsung S10e's as STAs and primarily iperf3 TCP/IP =
and UDP
traffic.  I did some work with the Intel AX200 as a STA using both Windows =
10
and Linux for RvR testing and found the Linux driver basically broken for
uplink. (See the Win10/Linux comparison in the RAX40 section of
https://www.smallnetbuilder.com/wireless/wireless-reviews/33220-wi-fi-6-p=
erformance-roundup-five-routers-tested?start=3D1

FWIW, Johannes was debugging some TCP issues on Intel 802.11ax t=
he other
day, and was getting ~1.4Gbps of throughput:
https://lore.k=
ernel.org/linux-wireless/90485ecbfa2a13c4438b840c8a9d37677e833ea5.camel@sip=
solutions.net/T/

So I guess maybe there are improvements coming in that space?
TH: Yes, I'm monitoring that thread. I'm about to try a 5.2.14 kernel with this patch
https://patchwork.kernel.org/patch/11253471/

I think there are others in the works. Hope the end product will be available in a backport.

      

        
So, for now, I'm limited to using the Samsung S10 as STAs.=
=20

ANYWAY, I haven't been having much luck finding total throughput gains,=
 so
thought I'd bang my head against a different wall for awhile, which bri=
ngs me
to latency.=20

My initial work was pretty simple, just running pings to four OFDMA STAs wi=
th
OFDMA on/off on the AP, which showed no improvement. That's once I real=
ized
the large ping times and variation I was seeing initially was due to
aggressive power-save kicking in on the STAs with no traffic running. So I
also tried various TCP rates starting at 1 Mbps per STA to keep the STA awa=
ke.

Coincidentally, Dave reached out the other day and suggested I look at the
toolsets used for the make-wifi-fast project. =20

I've spent a few hours looking at the flent and rrul sites and  I'm=
 interested
in exploring using the tools/techniques used for the make-wifi-fast work to
date to see if AX adds anything to the latency improvement party.  If anyon=
e
is willing to provide some pointers on the proper use of the tools, I'd
appreciate it.


      

      
I think the Flent batch file used to run the tests are part of t=
he data
file at the bottom of this page:
https://www.cs.kau.se/tohojo/airtime-fairness/


    

    TH: Thanks for the reference, I'll look into that

    

      
The setup I was using had a server that ran the tests, which was=
 one
Ethernet hop from the AP. The clients were passive, run running
'netserver' so the server could run 'netperf' against each =
of them. This
flips up/down in the tests but otherwise works fairly well. I used a
separate (wired) control network for telling the clients to
connect/disconnect...

More details about the setup here:
https://blog.tohojo.dk/2017/11/building-a-wir=
eless-testbed-with-wires.html


    

    TH: Again, thanks.

    

      

      

        
For example, I didn't see mention of the bitrates used for=
 the traffic streams
in the tests. Do I just tell each stream to run full blast (1 Gbps)?


      

      
Well for TCP tests, yeah. The only UDP tests I did were flood te=
sts,
where I just had iperf blasting away at way above the link rate, then
measured how many packets made it through.


    

    TH: Got it. Blast away on both TCP and UDP. Not sure how that will
    work with OFDMA trying to split that bandwidth into multiple RUs
    that have smaller bandwidth, but guess I'll find out.

    

      

      

        
Also, since most implementations of (consumer at least) OFDMA =
require multiple
STAs to trigger OFDMA frames, I could use some help understanding whether
multiple streams should be applied per STA, or spread among the 4 STAs I=
9;m
using in my testing.


      

      
Why not just try both and see what works? :)


    

    TH: Why didn't I think of that? :) OK.

    

      

      

        
Also (2), has anyone used Android STAs for make-wifi-fast test=
ing?


      

      
Nope. But if you can get netperf cross-compiled it should be sim=
ple
enough to run 'netserver' on them, I would think?

    

    TH: Unfortunately, that requires more skills than I have. Maybe
    someone else on this list has already done it?

  



_______________________________________________

Make-wifi-fast mailing list

M=
ake-wifi-fast@lists.bufferbloat.net

https://lists.bufferbloat.net/listinfo/make-wif=
i-fast


--0000000000009c8bf60599d89188--