Lets make wifi fast again!
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Tim Higgins <tim@smallnetbuilder.com>,
	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: Thu, 02 Apr 2020 12:20:32 +0200	[thread overview]
Message-ID: <87mu7ufatr.fsf@toke.dk> (raw)
In-Reply-To: <e9c57354-4653-955f-6416-16636c339cb9@smallnetbuilder.com>

Tim Higgins <tim@smallnetbuilder.com> 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 at
> 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


  parent reply	other threads:[~2020-04-02 10:20 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
2020-04-01 21:16   ` Bob McMahon
2020-04-02 10:20 ` Toke Høiland-Jørgensen [this message]
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=87mu7ufatr.fsf@toke.dk \
    --to=toke@redhat.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