From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id CF00A3CB3C for ; Thu, 11 Apr 2019 19:38:55 -0400 (EDT) Received: by mail-io1-xd2b.google.com with SMTP id e13so6921779ioq.6 for ; Thu, 11 Apr 2019 16:38:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Go23T9PvJK6ngRAy7XCOgGK+Q5Gc02UJ2s7XEtjTnhE=; b=edAaHXBzxaIrNZIHltKa3526G9VxCK52s+W++3iQ0sf4b+2RCaPzMfJ3PHLx4VNXzN ap/rGukBUGAr1DpbEU/CEARDwbESps6dUb2rOGoFFg3Pi6oO0ddWBS6T9YmtPQu7HM2W dQ8Bkf0CWRglPPlcdTF7JVo+Cv/39RsZprR5RdZJSV5wLslrFbtE98MiqGrB8vxCOgre q5GAgNqZ/gHwZEhvEF7Whlh35XEIw7EhL+5FWmsU3sFvtG6m1/z7yD7KIy6dIaXRcVD/ x5z15QO7XVDiZ6t8Q35mi9xpBpF8GeKyrBsZJr6PBV+dQYAp4yqCWJx7J4KIysYKo49G A3LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Go23T9PvJK6ngRAy7XCOgGK+Q5Gc02UJ2s7XEtjTnhE=; b=Cy6W+fM1FS1dBUyS0DvtKhXSK5qkOsy98H6y55b3aw1JNyPFf2zFxv6DKdlI6tVNxv vqFOOh+7AavM7grWBtWN5J1gka08nQWmFDqBUsR+WrlUUZjLZMxE04OzfG7DFwLGAwVd O88ldPLMCmX8zzHUJ1FBXLMz7LFTAyXfuR3gxe318qUrPeQN0Aa9Gqp2fWnPFOibtZaN ekSvhpcMSd1LMDV4wEe+J1puFeaORNVHRFcFf2uly1TPUkqteEyTMsQbcTaiLxDPzJ1w ERI1U1pZ6e5+Rz+DWL2B06AIBI9qGJIileaBkIr+MfC/g0vR3uRdzfFpdSqxjXlnTdCW eSMw== X-Gm-Message-State: APjAAAU7ZPFLtsnPVlwnSxahYAMMEJZnIMdgvLC3+xPwWXLUC3X5+yUs pmy73r04ifc0eDfNWjilwfscYJdtpCoJIQOgvy45LFGWbBI= X-Google-Smtp-Source: APXvYqysx0mykVoN4g4Od0zJPS4rHNYITPip+oG/OZHg+wz8c7eXwOxnoYUsUu/eWMWxq3nppj8kcTxLAMSdPk1nSm8= X-Received: by 2002:a6b:6707:: with SMTP id b7mr29697693ioc.172.1555025934759; Thu, 11 Apr 2019 16:38:54 -0700 (PDT) MIME-Version: 1.0 From: Joshua Zhao Date: Thu, 11 Apr 2019 16:38:44 -0700 Message-ID: To: make-wifi-fast@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="000000000000753d69058649b0ef" X-Mailman-Approved-At: Thu, 11 Apr 2019 20:05:05 -0400 Subject: [Make-wifi-fast] tx queue stuck for many minutes X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 23:38:55 -0000 --000000000000753d69058649b0ef Content-Type: text/plain; charset="UTF-8" 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. The following dump shows an example that the backlog-packets count stays at 74 for around 30min after the TX had totally stopped. Here when video queue is stuck, other TID's traffic can go through. I wonder why it takes so long for the queue to clean up. Shouldn't packets be dropped quickly if they cannot be sent? Many thanks! cat /sys/kernel/debug/ieee80211/phy0/netdev:wlan3/stations/xx:xx:xx/aqm target 19999us interval 99999us ecn yes tid ac backlog-bytes backlog-packets new-flows drops marks overlimit collisions tx-bytes tx-packets 0 2 0 0 3 0 0 0 0 390 3 1 3 0 0 0 0 0 0 0 0 0 2 3 0 0 0 0 0 0 0 0 0 3 2 0 0 0 0 0 0 0 0 0 4 1 0 0 0 0 0 0 0 0 0 5 1 112344 74 1627 0 0 0 0 2373618 1632 6 0 0 0 0 0 0 0 0 0 0 7 0 0 0 1 0 0 0 0 32 1 8 2 0 0 0 0 0 0 0 0 0 9 3 0 0 0 0 0 0 0 0 0 10 3 0 0 0 0 0 0 0 0 0 11 2 0 0 0 0 0 0 0 0 0 12 1 0 0 0 0 0 0 0 0 0 13 1 0 0 0 0 0 0 0 0 0 14 0 0 0 0 0 0 0 0 0 0 15 0 0 0 0 0 0 0 0 0 0 --000000000000753d69058649b0ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
I run into a weird symptom that occasionally the a= qm tx queue can get stuck for quite long time (maybe around 30min).=C2=A0 W= hat 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=C2=A0+ 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 th= ough the link trouble had been gone or TX had been stopped). Only after qui= te a while, then the queue cleans up.
The following dump shows an= example that the backlog-packets count stays at 74 for around 30min after = the TX had totally stopped. Here when video queue is stuck, other TID's= traffic can go through.=C2=A0
I wonder why it takes so long for = the queue to clean up. Shouldn't packets be dropped quickly if they can= not be sent?

Many thanks!

cat /sys/kernel/d= ebug/ieee80211/phy0/netdev:wlan3/stations/xx:xx:xx/aqm

target 19999u= s interval 99999us ecn yes

tid ac backlog-bytes backlog-packets new-= flows drops marks overlimit collisions tx-bytes tx-packets

0 2 0 0 3= 0 0 0 0 390 3

1 3 0 0 0 0 0 0 0 0 0

2 3 0 0 0 0 0 0 0 0 0
3 2 0 0 0 0 0 0 0 0 0

4 1 0 0 0 0 0 0 0 0 0

5 1 112344 74 1627 0 0 0 0 2373618 1632<= /span>

6 0 0 0 0 0 0 0 0 0 0

7 0 0 0 1 0 0 0 0 32 1

8 = 2 0 0 0 0 0 0 0 0 0

9 3 0 0 0 0 0 0 0 0 0

10 3 0 0 0 0 0 0 0 = 0 0

11 2 0 0 0 0 0 0 0 0 0

12 1 0 0 0 0 0 0 0 0 0

13 1= 0 0 0 0 0 0 0 0 0

14 0 0 0 0 0 0 0 0 0 0

15 0 0 0 0 0 0 0 0 = 0 0



--000000000000753d69058649b0ef--