From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 460403CB35 for ; Wed, 1 Apr 2020 16:22:20 -0400 (EDT) Received: by mail-qk1-x733.google.com with SMTP id v7so1560049qkc.0 for ; Wed, 01 Apr 2020 13:22:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GF+AWT6SC4sGfdxpnvlFJw6NZuhTZRrs6ZriWIq649g=; b=u0h4JkwFrnqIo10bTusv4yi96j9PU0cUuxBQbhGtNbps+ey6yGmpWGT+12+8nYzPXc 9PYhsDhjrrrYFduvYBCimFc9EvX4eR8xGmgU91msR+HHJwL4vJR04pCUPa07dTM4cByP 91Uome6r2x0ulVTXe6iIIZx/i/3HXaLt0hcpMvJh1yuQdcLV4xwE2Tn+o8V6Cds+Mc1R 11MaBKlzdL84DRZlZZtXqgUbKqCHZyNa1UFc07CH1MD4cU6a6Kd5EEBSFfqAVLPAdh3Z ek2rPJJOsePneYqSgzHAGorQeI7wyBJOm+5Oy8uUcWv3EHiKJRYAhv+s8Pv46VvMCnK8 FBvQ== 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=GF+AWT6SC4sGfdxpnvlFJw6NZuhTZRrs6ZriWIq649g=; b=NOY+MfTolwX0WM9/26QnGLlqaTeUdzWrI7tJp7eZcDzdKGw3hVwu/6Bpc4Bk8MEQQn k2Snbj7El92g+Ij5NODvKWFReYiHH6bff/ZQZpULjpkcdhXAEgqwtrrBwB5Dy4aoX+JJ zYg7gfO3pFmoOa2F8lTJoWmfmjlrY1ZwgWu6q5zVWP8/i7qpv1KnDU5MdWl1QBUGvZT1 38lHBX9A3EyQszhcgWoLWAQtulqa5xHRZ1+1azUWaIbCisRuQxW0aRDZmES54fdM675g OZ7ocS3FHMChoWzCqDN6+5BcYcuW+Y4C2Lvz5Q0WJqiLsPg/Sjue3VyxWLnQ/umsAny9 3Ouw== X-Gm-Message-State: AGi0PuZ1Slp7A3IKcdNHOPsEpegwvlpAtUyF0leioU+Fd7md38TXLxld sx5RyZSPrGubrodP4IrURyCDxEe+hFpnoYA+Ny8= X-Google-Smtp-Source: APiQypJzD3/tqWYWOUfdCOpQyIUU4cAOeWnOVXt/e/rzQownKKzBcs9kBDnFANSlUErMS8p1gob/390IrP/qF7jGMf0= X-Received: by 2002:a37:393:: with SMTP id 141mr25849qkd.393.1585772539718; Wed, 01 Apr 2020 13:22:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Aaron Wood Date: Wed, 1 Apr 2020 13:22:09 -0700 Message-ID: To: Tim Higgins Cc: Make-Wifi-fast Content-Type: multipart/alternative; boundary="000000000000ecef3305a2407023" 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: Wed, 01 Apr 2020 20:22:20 -0000 --000000000000ecef3305a2407023 Content-Type: text/plain; charset="UTF-8" I think that will depend on the wifi driver (on the tx side), and whether or not it's not sending 802.11n/ac aggregate frames immediately (and how long it's waiting). Some drivers will buffer up packets for some period of time before sending them out. So on a lightly loading transmitter, in a quiet RF airspace, the driver might add more latency than is necessary. One thing I've seen is that the wifi aggregates, because they are so large (64KB), can end up creating some odd RTT sawtooth patterns as a full aggregate will contain packets with many send times, all received at once. Here's an excellent summary: https://datatracker.ietf.org/meeting/101/materials/slides-101-iccrg-an-update-on-bbr-work-at-google-00 -Aaron On Wed, Apr 1, 2020 at 10:48 AM Tim Higgins wrote: > 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 at > reducing latency on a moderately loaded link? > > 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? > > =========== > Tim > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast --000000000000ecef3305a2407023 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think that will depend on the wifi driv= er (on the tx side), and whether or not it's not sending 802.11n/ac agg= regate frames immediately (and how long it's waiting).=C2=A0 Some drive= rs will buffer up packets for some period of time before sending them out.= =C2=A0 So on a lightly loading transmitter, in a quiet RF airspace, the dri= ver might add more latency than is necessary.

One thing = I've seen is that the wifi aggregates, because they are so large (64KB)= , can end up creating some odd RTT sawtooth patterns as a full aggregate wi= ll contain packets with many send times, all received at once.

-A= aron

On Wed, Apr 1, 2020 at 10:48 AM Tim Higgins <tim@smallnetbuilder.com> wrote:
<= /div>
=20 =20 =20
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 at reducing latency on a moderately loaded link?

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?

=20
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
Tim
_______________________________________________
Make-wifi-fast mailing list
M= ake-wifi-fast@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/make-wif= i-fast
--000000000000ecef3305a2407023--