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>,
	Bob McMahon <bob.mcmahon@broadcom.com>
Cc: Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net>
Subject: Re: [Make-wifi-fast] SmallNetBuilder article: Does OFDMA Really Work?
Date: Fri, 15 May 2020 22:24:17 +0200	[thread overview]
Message-ID: <87mu69q74e.fsf@toke.dk> (raw)
In-Reply-To: <f2df3e22-4300-1af4-c2c3-65919fa5c51f@smallnetbuilder.com>

Tim Higgins <tim@smallnetbuilder.com> writes:

> Thanks for the additional insights, Bob. How do you measure TCP connects?
>
> Does Dave or anyone else on the bufferbloat team want to comment on
> Bob's comment that latency testing under "heavy traffic" isn't ideal?

Well, it depends on what you want to measure. Loading the link with
heavy traffic is a good way to show the worst-case behaviour of the
system, as that will fill up the buffers and expose any latent
bufferbloat. Which, as Bob points out, will tend to drown out any other
source of latency, at least if all the queues are dumb FIFOs.

However, if you want to specifically study, say, the media access
latencies of the WiFi link, drowning it out with the order-of-magnitude
higher latencies of bloat in the layers above is obviously going to
obscure the signal somewhat. Which I think was basically Bob's point
about "testing under heavy traffic"?

> My impression is that the rtt_fair_var test I used in the article and
> other RRUL-related Flent tests fully load the connection under test.
> Am I incorrect?

Yeah, the RRUL test (and friends) are specifically designed to load up
the link to show the worst-case latency behaviour, including any
bufferbloat. And, as per the above, as long as the system you're testing
still has unresolved bloat issues, well, that is what you're going to be
seeing most of... :)

-Toke


  parent reply	other threads:[~2020-05-15 20:24 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-14 16:43 Tim Higgins
2020-05-14 21:38 ` Bob McMahon
2020-05-14 21:42   ` Bob McMahon
2020-05-15 15:20     ` Tim Higgins
2020-05-15 19:36       ` Bob McMahon
2020-05-15 19:50         ` Tim Higgins
2020-05-15 20:05           ` Bob McMahon
2020-05-15 20:24           ` Toke Høiland-Jørgensen [this message]
2020-05-15 20:30           ` Dave Taht
2020-05-15 21:35             ` Bob McMahon
2020-05-16  5:02               ` Dave Taht
     [not found]           ` <mailman.342.1589573120.24343.make-wifi-fast@lists.bufferbloat.net>
2020-05-15 20:38             ` Toke Høiland-Jørgensen
2020-05-15  6:47 ` Erkki Lintunen
2020-05-15 15:34   ` Tim Higgins
2020-05-15 16:25     ` Dave Taht
2020-05-15 16:41       ` Tim Higgins

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=87mu69q74e.fsf@toke.dk \
    --to=toke@redhat.com \
    --cc=bob.mcmahon@broadcom.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