Lets make wifi fast again!
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Jon Pike <jonpike54@gmail.com>, make-wifi-fast@lists.bufferbloat.net
Subject: Re: [Make-wifi-fast] bloated ath10k, extra latency at lower rates?
Date: Sun, 10 Feb 2019 21:30:44 +0100	[thread overview]
Message-ID: <874l9bperv.fsf@toke.dk> (raw)
In-Reply-To: <CALukJKRUe-S7EFm_22AWyFd7pcG8j2EY3jJgtXnLrGkzCCXyGg@mail.gmail.com>

Jon Pike <jonpike54@gmail.com> writes:

> This might be a good time to mention an observation I've seen that's
> related to this.
>
> I have noticed about the same as reported, 10's down to single digits
> on my ath9k radios, and a similar 20ms-30ms on the ath10k's. Thats at
> high signal strength and the highest data rates. But, I've also
> noticed that it's different if you get farther out in range, and you
> end up on the slower signaling speeds.
>
> Under those conditions, I'm seeing the ath9k latency rise only
> slightly, maybe to 20-30ms, while the ath10k will go up more
> drastically, like a continuous 100-150ms or more. Been meaning to
> mention it to see if it should be considered as an issue.

Well yeah, I guess it should. To answer both you and Adrian: The
debloating of ath10k is only partial currently. It uses the intermediate
queueing system, but it still has quite a bit of buffering in the
firmware, which is not controlled by the driver. The actual latency
induced by this buffering varies by firmware version; but it sounds
quite likely that it would be worse as the rates drop.

The fix for this is to control the queue length in the firmware, similar
to what BQL does for Ethernet drivers. The ChromeOS people at Google
already has this as a patch for ath10k, which we are planning to port
upstream to live inside mac80211 on top of the airtime fairness
mechanism that is in the process of being merged.

So there is some hope that this situation will improve in the future :)

-Toke

  reply	other threads:[~2019-02-10 20:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-10 18:23 Jon Pike
2019-02-10 20:30 ` Toke Høiland-Jørgensen [this message]
2019-02-10 20:40   ` Dave Taht
     [not found]     ` <CALukJKSVVQXti=+2QfxUN_44vNU+Cn3co68JvY6_wgCTwS8O6Q@mail.gmail.com>
2019-02-27  6:23       ` Jon Pike
2019-03-03 16:41         ` Adrian Popescu

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=874l9bperv.fsf@toke.dk \
    --to=toke@redhat.com \
    --cc=jonpike54@gmail.com \
    --cc=make-wifi-fast@lists.bufferbloat.net \
    /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