From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 AC9A73CB35 for ; Wed, 1 Apr 2020 17:16:29 -0400 (EDT) Received: by mail-wm1-x333.google.com with SMTP id d77so1265766wmd.3 for ; Wed, 01 Apr 2020 14:16:29 -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=QW9kDW2Cm/1MS2Ol+Ey7KsvaeqpinrNvtJRaDMeQcng=; b=An6mbIUGk/lQ9S6UeeHQ0pFhedkcKkYRbi4CO+FBymw7SRQssp8xdKP/xCyowXtrSx ED2lQe+/Y6CDm47PhkcuZtNfLeA1E+yW+CrDTrJzz+ieh120ondqwV0nYyLMpgWXXf1q /3v1w2choI4DA0F2FNgShWuzTvBzQ5dw2CdhE= 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=QW9kDW2Cm/1MS2Ol+Ey7KsvaeqpinrNvtJRaDMeQcng=; b=n/anzAMCNneAifrKlS95smT8fjNJ95cmKQzJ2m9dq0lZDQYw35bnDHYASyjKCsmVl7 UyE7rWJYVziCvyfckUnONwvlzm6MP1pEIIa1PeI1EYFSZCn5ont4+iq6M1sd7c4YyK7o KwoiLX4lJh/F5Llpl9ptXgh2VlkcggskfXGN/xAAPV7SnSWfWfWOve6lTWHpPra9ph1L a4Gd1/jL5fxnexHat/+M/ASljh5at10vHTki+lPvTsyDJX2Q9SAJ5B1Bc9Xl30AIkmaE RwHHXolJ9+1nbzLvBYN+fY/zlhdw2ZbfIBwbTtPLFdoCyegvko34CJ9Ey3LucGJcYirC bNxA== X-Gm-Message-State: AGi0PuYq6hgGlHL6s7JXeKK+yP7PkBvfw/W50iQBejKsBZWTDe8UyNky 0ODvKjJQym54tYCZBzJUiQhSLldEkk2cu4UEurtYwg== X-Google-Smtp-Source: APiQypLuMshEZktdGv6s3ezYipjXveKnfdQX63lGQuNux2NvvE3h0/KTliH1VscloSSCo4JpUloWupH3cGwj6drKoc8= X-Received: by 2002:a1c:6605:: with SMTP id a5mr370485wmc.32.1585775788655; Wed, 01 Apr 2020 14:16:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Bob McMahon Date: Wed, 1 Apr 2020 14:16:17 -0700 Message-ID: Subject: Re: [Make-wifi-fast] Must a WiFi link be fully loaded to get an accurate latency measurement? To: Aaron Wood Cc: Tim Higgins , Make-Wifi-fast Content-Type: multipart/alternative; boundary="00000000000093dabc05a24132bc" X-List-Received-Date: Wed, 01 Apr 2020 21:16:29 -0000 --00000000000093dabc05a24132bc Content-Type: text/plain; charset="UTF-8" A few notes: o) Bufferbloat is about queue depth and an input rate exceeding the service rate such that a queue becomes a standing queue. o) Latency is end/end and can mean different things. The base assumption by many in the network engineering community is that all queuing is in the network stack somewhere. But if the application is held back it's effectively a queue too. Things like RTT mostly affect TCP byte transfer. The amount of blocking by the application isn't measured. o) Aggregation and transmit "lazy" on a driver doesn't typically occur for the Voice access class. Many test driver latency with that AC as well as BE o) iperf 2.0.14 has a trip time latency which is write time (or start of burst/frame) vs final read time. This requires --trip-time as well as synchronized clocks. It also produces bytes in progress from an application end/end perspective using little's law . More iperf 2.0.14 videos here Bob On Wed, Apr 1, 2020 at 1:22 PM Aaron Wood wrote: > 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 > > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast --00000000000093dabc05a24132bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A few notes:

o) Bufferbloat is about queue depth a= nd an input rate exceeding the service rate such that a queue becomes a sta= nding queue.=C2=A0
o) Latency is end/end and can mean different t= hings. The base assumption by many in the network engineering=C2=A0communit= y is that all queuing is in the network stack somewhere.=C2=A0 But if the a= pplication is held back it's effectively a queue too. Things like RTT m= ostly affect TCP byte=C2=A0transfer.=C2=A0 The amount of blocking by the ap= plication isn't measured.=C2=A0
o) Aggregation and transmit "la= zy" on a driver doesn't typically occur for the Voice access class= .=C2=A0 Many test driver latency with that AC as well as BE
o) ip= erf 2.0.14 has a = trip time latency which is write time (or start of burst/frame) vs fina= l read time.=C2=A0 This requires --trip-time as well as synchronized clocks= . It also produces bytes in progress from an application end/end perspectiv= e using little'= ;s law.
<= div>Bob=C2=A0

On Wed, Apr 1, 2020 at 1:22 PM Aaron Wood <woody77@gmail.com> wrote:
I think that will depend on the wifi driver (on the tx side), and whethe= r or not it's not sending 802.11n/ac aggregate frames immediately (and = how long it's waiting).=C2=A0 Some drivers will buffer up packets for s= ome period of time before sending them out.=C2=A0 So on a lightly loading t= ransmitter, in a quiet RF airspace, the driver might add more latency than = is necessary.

One thing I've seen is that the wifi a= ggregates, because they are so large (64KB), can end up creating some odd R= TT sawtooth patterns as a full aggregate will contain packets with many sen= d times, all received at once.


-Aaron

On Wed, Apr 1, 2020 at 10:48 AM Tim Higgins <tim@smallnetbuilder.com> wrote:<= br>
=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
_______________________________________________
Make-wifi-fast mailing list
M= ake-wifi-fast@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/make-wif= i-fast
--00000000000093dabc05a24132bc--