From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from roobidoo.pudai.com (unknown [216.14.118.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 34A073B29D for ; Thu, 30 Apr 2020 10:18:07 -0400 (EDT) Received: from [71.219.88.243] (port=9751 helo=[10.168.3.100]) by roobidoo.pudai.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1jUA0t-0008M7-0b for make-wifi-fast@lists.bufferbloat.net; Thu, 30 Apr 2020 09:18:07 -0500 To: Make-Wifi-fast References:

From: Tim Higgins Message-ID: <5be92b82-ae44-e8f5-9a7a-64fea0093a23@smallnetbuilder.com> Date: Thu, 30 Apr 2020 10:18:12 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/html; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - roobidoo.pudai.com X-AntiAbuse: Original Domain - lists.bufferbloat.net X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - smallnetbuilder.com X-Get-Message-Sender-Via: roobidoo.pudai.com: authenticated_id: tim@timhiggins.com X-Authenticated-Sender: roobidoo.pudai.com: tim@timhiggins.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Make-wifi-fast] Uplink vs downlink latency X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2020 14:18:07 -0000 I take your point, Bob, and agree single-ended latency measurements like you produce with iperf would be more technically correct.

I write and review for a consumer audience, where ping is the standard for latency aka lag measurement. So that's why I'm using ping.
That, and the fact that iperf isn't integrated into octoScope's toolset yet. But they're working on it and all their STA instruments are properly time-synced, so the measurements will be accurate.

Thank your for all your work in iperf, BTW. The features you've added are a welcome improvement.

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
Tim

On 4/29/2020 8:32 PM, Bob McMahon wrote:

I'm thinking ping may not be ideal for benchmarking=C2=A0OFDMA effects on latency.=C2=A0 Also, the end/e= nd latency preferred seems to me the socket write() to final socket read() per that write(). Also, for TCP, there are the connect times. I realize network stack guys focus on stack related measurements, e.g. RTT, but the latencies users experience include the application level and system level os interactions.
Just some food=C2=A0or thought.

Bob

On Wed, Apr 29, 2020 at 5:0= 7 PM Dave Taht <dave.taht@gmail.com> wrote:

= throughput and latency are interrelated, whats the throughput?

On Wed, Apr 29, 2020 at 2:40 PM Tim Higgins <tim@smallnetbuilder.com> wrote:
>
> Hi all,
>
> I finally have my testbed working the way I want and am starting to run tests to see if OFDMA does anything useful.
= >
> This will all be covered in detail in an upcoming SmallNetBuilder article. But I wanted to sanity check something with this esteemed group.
>
> The tests are basically the flent rtt_fair_var up and down tests ported to the octoScope platform I use for WiFi testing.
> The initial work was done on flent, with a lot of hand-holding from Toke. (Thank you, Toke!)
>
> Using 4 Intel AX200 STAs on Win10. iperf3 is running traffic using TCP/IP with unthrottled bandwidth. I've taken Bj=C3=B8rn's idea and have each STA using a different DSCP prio= rity level, but with TCP/IP traffic, not UDP. I'm sticking to using CS0-7 equivalents and confirmed that the iperf3 --dscp values properly translate to the intended WiFi priority levels.=C2=A0 = Each STA has a different priority, either CS0,3,5 or 6 (best effort, excellent effort, video and voice).
>
> Ping is used to measure latency and always runs from AP to STA. Only TCP/IP traffic direction is reversed between the down and uplink tests.
>
> One thing that jumps out immediately is that uplink latencies are *much* lower than downlink, with either OFDMA on or off. Attached are three examples. The CDFs are average latency of the 4 STAs.
>
> The NETGEAR R7800 is a 4x4 AC Qualcomm-based. I'm using this as a baseline product.
>
> The NETGEAR RAX15 is 2x2 AX Broadcom-based. You can see what I mean when I say OFDMA doesn't help.
>
> Does this much difference between up and downlink latency pass the sniff test?
>
> =3D=3D=3D
> Tim
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast@lis= ts.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast

--
Make Music, Not War

Dave T=C3=A4ht
CTO, TekLibre, LLC
http://www.teklibr= e.com
Tel: 1-831-435-0729
_______________________________________________
Make-wifi-fast mailing list
Make-wifi-fast@lis= ts.bufferbloat.net
https://lists.bufferbloat.net/listinfo/make-wifi-fast