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 28FF93B2A4 for ; Thu, 2 Apr 2020 10:52:36 -0400 (EDT) Received: from [71.219.63.218] (port=7548 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 1jK1Cs-0007Sx-VH; Thu, 02 Apr 2020 09:52:35 -0500 To: Make-Wifi-fast References: <87mu7ufatr.fsf@toke.dk> From: Tim Higgins Message-ID: Date: Thu, 2 Apr 2020 10:52:40 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <87mu7ufatr.fsf@toke.dk> 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] Must a WiFi link be fully loaded to get an accurate latency measurement? 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, 02 Apr 2020 14:52:36 -0000

On 4/2/2020 6:20 AM, Toke H=C3=B8iland-J=C3=B8rgensen wrote:

Tim Higgins <tim@smalln=
etbuilder.com> writes:

One of the things I've bee=
n wondering about as I work on OFDMA testing is how
heavily a WiFi link needs to be loaded.
As far as I can tell, all (most/many) of the flent scripts basically have=

netperf TCP/IP streams running full tilt.

I guess put another way, how effective are the anti-bufferbloat methods a=
t
reducing latency on a moderately loaded link?

Well, the anti-bufferbloat mitigations aim at managing packet queues.
But if the link is not loaded to capacity, packets will generally be
sent out as soon as they arrive, so there won't *be* any queue to
manage. Which means that as far as queueing is concerned, it doesn't
really matter what you do. There are other factors that can impact the
latency of an idle link, of course, but we haven't really touched those
much when working on the bloat stuff..

In terms of WiFi, do I nee=
d to run a link at 90+ airtime congestion to
see OFDMA work it's magic? Or would the lack of available airtime
hinder it working?

Now this is a good question. I would expect that OFDMA to only kick in
if there is actually data queued for multiple stations. I mean,
otherwise it doesn't really gain you much? There is probably also a
tradeoff in how long you hold back packets while waiting for more data
to show up; wait too long and you're just wasting airtime, but if you
don't wait long enough you get no benefit. How the firmware scheduler
manages that is of course vital; but I guess that's what you're trying
to find out? :)

-Toke

Thanks everyone for the replies. OFDMA will be adding yet another layer of complexity to the current brew.
I'll post back after I do some experiments.