From: Joshua Zhao <swzhao@gmail.com>
To: "Toke Høiland-Jørgensen" <toke@redhat.com>
Cc: make-wifi-fast@lists.bufferbloat.net
Subject: Re: [Make-wifi-fast] tx queue stuck for many minutes
Date: Fri, 12 Apr 2019 10:26:00 -0700 [thread overview]
Message-ID: <CAKmTU=rS2p0hB+5h8mY9aC3_Bhqi88_JXxGVqjeyK3SXEMfFuw@mail.gmail.com> (raw)
In-Reply-To: <878swfshsk.fsf@toke.dk>
[-- Attachment #1: Type: text/plain, Size: 1877 bytes --]
Hi,
Thanks for the reply! I've also emailed the ath10k and linux-wireless list
and waiting to hear back suggestions.
In the meantime can you educate me how the aqm queue interacts with wifi
driver? Is that the driver pulls from the queue from time to time, instead
of aqm pushes to the network interface? How often or what triggers the
driver to pull?
I hope I can verify that if you can point me to the code to check that :)
And, for the queue itself, how long it's supposed to drop packets and clean
up? It seems that when it's full, it notifies back-pressure to the socket
instead of simply dropping the packets from the head or the tail of the
queue?
Many thanks!
Joshua
On Fri, Apr 12, 2019 at 2:18 AM Toke Høiland-Jørgensen <toke@redhat.com>
wrote:
> Joshua Zhao <swzhao@gmail.com> writes:
>
> > Hi,
> > I run into a weird symptom that occasionally the aqm tx queue can get
> stuck
> > for quite long time (maybe around 30min). What happened is that we're
> > sending a low bandwidth UDP traffic from the host to multiple peers over
> a
> > WiFi radio simultaneously. We're running opensource mac80211 + ath10k
> > driver. Very occasionally when there are temporary issues causing trouble
> > on the host sending to one of the peers, the queue to all peers can get
> > stuck and stay stuck for quite long (even though the link trouble had
> been
> > gone or TX had been stopped). Only after quite a while, then the queue
> > cleans up.
>
> This sorta sounds like a driver bug where the queue doesn't get
> restarted after the issue is resolved? I'd suggest you email the ath10k
> (ath10k@lists.infradead.org - maybe cc linux-wireless@vger.kernel.org
> and this list) with a description of the issue that triggers this bug,
> as well as system details (hardware model, firmware version and kernel
> version).
>
> -Toke
>
[-- Attachment #2: Type: text/html, Size: 2495 bytes --]
next prev parent reply other threads:[~2019-04-12 17:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-11 23:38 Joshua Zhao
2019-04-12 0:04 ` Joshua Zhao
2019-04-12 9:18 ` Toke Høiland-Jørgensen
2019-04-12 17:26 ` Joshua Zhao [this message]
2019-04-12 19:57 ` Toke Høiland-Jørgensen
2019-04-12 23:03 ` Joshua Zhao
2019-04-13 6:45 ` Toke Høiland-Jørgensen
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='CAKmTU=rS2p0hB+5h8mY9aC3_Bhqi88_JXxGVqjeyK3SXEMfFuw@mail.gmail.com' \
--to=swzhao@gmail.com \
--cc=make-wifi-fast@lists.bufferbloat.net \
--cc=toke@redhat.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