From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 CCB903B2A4 for ; Thu, 2 Apr 2020 14:11:08 -0400 (EDT) Received: by mail-wr1-x429.google.com with SMTP id h15so5350344wrx.9 for ; Thu, 02 Apr 2020 11:11:08 -0700 (PDT) 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=bHRBCmLCDHgq0pSRMu8dK0F9HkcPwr2Trvg+bA9QGo8=; b=iB6C90CQCBFr9tLIcztEu+JIiInT8aHNdH163ZaOFPYnM6+uoVt8+7t63ZrM5nSGDY 4797g2gV0NCnyh9k095XHYL7MaXADZ9thNyqu67QOTMA0uACY0GgAQJC3QkMTR4bgLPj FUOqiPXeI1U/5sPfQMhUtMOrPlwiQ3+GLwwDw= 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=bHRBCmLCDHgq0pSRMu8dK0F9HkcPwr2Trvg+bA9QGo8=; b=pg+Nyxwb1z00X7L1tLLdQAN4xMQ54Kv1snzRXFTA5aoD/qOdYRPVKlhL78540dVkUZ aw9+rAinHp65jNAYSPNsPmNQED8MtsYBX1iG/Uq5a4QnAhJwO0+GVbhYxZaX4a4pS3XH Vt2zJg6ACTeyvRwht1N8LaRutHHXAjHStuEW2q6orB/YFQkaI3OixgEYLfnyQmIhbIIq nwybHfO9Gd+oIZJjcjTMKwKRUlrg8vHc17eoMcLRTmkZMi0so8ay0YnIFt7syg+oQ8Rz V2rJ4a6GT7AiiuiU6ohWvQGfrzw10f6wu+12+RIH+kjnQWVaItaNu43zdqlS5LNi65/0 pLjQ== X-Gm-Message-State: AGi0PuavkNfZYRnT2efoM1K+CYQsR2QkxFSGArFip7YUFAqpy0ziun3M dj1m8/EZFdnURw6g+uUOv3xz1OxYoWI8ClZKSQKI8g== X-Google-Smtp-Source: APiQypJ7pmmKbidylpm2YXRnYDtBgjbLoW9INmKffQwMnlxs99iHOtdjexa1LaHxt/G/NxHK3yoe98T+eadWKFVSWS8= X-Received: by 2002:a5d:4345:: with SMTP id u5mr4637684wrr.417.1585851067777; Thu, 02 Apr 2020 11:11:07 -0700 (PDT) MIME-Version: 1.0 References: <87mu7ufatr.fsf@toke.dk> In-Reply-To: From: Bob McMahon Date: Thu, 2 Apr 2020 11:10:56 -0700 Message-ID: Subject: Re: [Make-wifi-fast] Must a WiFi link be fully loaded to get an accurate latency measurement? To: Tim Higgins Cc: Make-Wifi-fast Content-Type: multipart/alternative; boundary="0000000000008ff84a05a252b95a" X-List-Received-Date: Thu, 02 Apr 2020 18:11:09 -0000 --0000000000008ff84a05a252b95a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > There is probably also a tradeoff in how long you hold back packets while waiting for more data to show up; Also recall that a transmit has to adhere EDCA and NAV. If energy detect or virtual carrier are active the device "backs off" and arbitrates again. Then there is the encoding and number of spatial streams which influence propagation delay. So packet queues aren't typically the bottleneck in uncongested scenarios and aren't the forcing function for end/end latency. It's typically related to the RF conditions which includes energy by peers, same BSS or otherwise. Then there is OS related stuff with respect to writes and reads that can add latency per thread scheduling. That's another reason why it helps to measure end/end latency which includes application level writes and reads. The following components of latency might be helpful: Propagation delay Amount of time required for a message to travel from the sender to receiver, which is a function of distance over speed with which the signal propagates. Transmission delay Amount of time required to push all the packet=E2=80=99s bits into the link= , which is a function of the packet=E2=80=99s length and data rate of the link. Processing delay Amount of time required to process the packet header, check for bit-level errors, and determine the packet=E2=80=99s destination. Queuing delay Amount of time the packet is waiting in the queue until it can be processed= . Bob On Thu, Apr 2, 2020 at 7:52 AM Tim Higgins wrote: > > On 4/2/2020 6:20 AM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > Tim Higgins writes: > > > One of the things I've been 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 need 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 o= f > complexity to the current brew. > I'll post back after I do some experiments. > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast --0000000000008ff84a05a252b95a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> There is probably also a tradeoff in how long you hol= d back packets while waiting for more data to show up;

Also recall t= hat a transmit has to adhere EDCA and NAV.=C2=A0 If energy detect or virtua= l carrier are active the device "backs off" and arbitrates again.= Then there is the encoding and number of spatial streams which influence p= ropagation=C2=A0delay.

So packet queues aren't typically the bot= tleneck=C2=A0in uncongested scenarios and aren't the forcing function f= or end/end latency.=C2=A0 It's typically related to the RF conditions w= hich includes energy by peers, same BSS or otherwise. Then there is OS rela= ted stuff with respect to writes and reads that can add latency per thread = scheduling.=C2=A0 That's another reason why it helps to measure=C2=A0en= d/end latency which includes application=C2=A0level writes and reads.
The following components of latency might be helpful:

Propagation = delay
Amount of time required for a message to travel from the sender to= receiver, which is a function of distance over speed with which the signal= propagates.

Transmission delay
Amount of time required to push a= ll the packet=E2=80=99s bits into the link, which is a function of the pack= et=E2=80=99s length and data rate of the link.

Processing delay=
Amount of time required to process the packet header, check for bit-lev= el errors, and determine the packet=E2=80=99s destination.

Queuing d= elay
Amount of time the packet is waiting in the queue until it can be p= rocessed.

Bob=C2=A0


On Thu, Apr 2, 2020 at 7:52 AM Tim = Higgins <tim@smallnetbuilder.= com> wrote:
=20 =20 =20

On 4/2/2020 6:20 AM, Toke H=C3=B8iland-J=C3=B8rgensen wrote:
Tim Higgins <tim@smallnetbuilder.com> writes:


One of the things I've been wondering about as I work on O=
FDMA 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 at
reducing latency on a moderately loaded link?

Well, the anti-bufferbloat mitigations aim at managing packet qu=
eues.
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 need to run a link at 90+ airtime conge=
stion 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 k=
ick 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 try=
ing
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.
_______________________________________________
Make-wifi-fast mailing list
M= ake-wifi-fast@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/make-wif= i-fast
--0000000000008ff84a05a252b95a--