From: Aaron Wood <woody77@gmail.com>
To: Tim Higgins <tim@smallnetbuilder.com>
Cc: Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net>
Subject: Re: [Make-wifi-fast] Must a WiFi link be fully loaded to get an accurate latency measurement?
Date: Wed, 1 Apr 2020 13:22:09 -0700 [thread overview]
Message-ID: <CALQXh-MWOcgttSgmYSufbhMHSZ+6aqk8+_nen20dKi00nNN1AA@mail.gmail.com> (raw)
In-Reply-To: <e9c57354-4653-955f-6416-16636c339cb9@smallnetbuilder.com>
[-- Attachment #1: Type: text/plain, Size: 1538 bytes --]
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 <tim@smallnetbuilder.com> 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
[-- Attachment #2: Type: text/html, Size: 2599 bytes --]
next prev parent reply other threads:[~2020-04-01 20:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-01 17:48 Tim Higgins
2020-04-01 20:22 ` Aaron Wood [this message]
2020-04-01 21:16 ` Bob McMahon
2020-04-02 10:20 ` Toke Høiland-Jørgensen
2020-04-02 14:52 ` Tim Higgins
2020-04-02 18:10 ` Bob McMahon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/make-wifi-fast.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALQXh-MWOcgttSgmYSufbhMHSZ+6aqk8+_nen20dKi00nNN1AA@mail.gmail.com \
--to=woody77@gmail.com \
--cc=make-wifi-fast@lists.bufferbloat.net \
--cc=tim@smallnetbuilder.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox