linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ping-Ke Shih <pkshih@realtek.com>
To: Bitterblue Smith <rtl8821cerfe2@gmail.com>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: RE: [PATCH rtw-next 4/4] wifi: rtw88: Don't set SUPPORTS_AMSDU_IN_AMPDU for RTL8814AU
Date: Mon, 17 Mar 2025 03:31:11 +0000	[thread overview]
Message-ID: <003857401c0245d7aa9a29c8806cb558@realtek.com> (raw)
In-Reply-To: <9f9a16a3-d326-4f48-9853-134751b63864@gmail.com>

Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> Sent: Friday, March 14, 2025 4:20 AM
> RTL8814AU doesn't work well with SUPPORTS_AMSDU_IN_AMPDU. The RX speed
> is noticeably lower and the VHT RX statistics are strange. Typical
> values with SUPPORTS_AMSDU_IN_AMPDU:
> 
> Reverse mode, remote host 192.168.0.1 is sending
> [  5] local 192.168.0.50 port 60710 connected to 192.168.0.1 port 5201
> [ ID] Interval           Transfer     Bitrate
> [  5]   0.00-1.00   sec  74.6 MBytes   626 Mbits/sec
> [  5]   1.00-2.00   sec  79.2 MBytes   665 Mbits/sec
> [  5]   2.00-3.00   sec  84.9 MBytes   712 Mbits/sec
> [  5]   3.00-4.00   sec  83.8 MBytes   703 Mbits/sec
> [  5]   4.00-5.00   sec  85.9 MBytes   720 Mbits/sec
> [  5]   5.00-6.00   sec  78.9 MBytes   662 Mbits/sec
> [  5]   6.00-7.00   sec  81.2 MBytes   682 Mbits/sec
> [  5]   7.00-8.00   sec  80.5 MBytes   675 Mbits/sec
> [  5]   8.00-9.00   sec  79.4 MBytes   666 Mbits/sec
> [  5]   9.00-10.00  sec  82.2 MBytes   689 Mbits/sec
> [  5]  10.00-11.00  sec  82.0 MBytes   688 Mbits/sec
> [  5]  11.00-12.00  sec  84.2 MBytes   707 Mbits/sec
> [  5]  12.00-13.00  sec  71.0 MBytes   596 Mbits/sec
> [  5]  13.00-14.00  sec  69.4 MBytes   582 Mbits/sec
> [  5]  14.00-15.00  sec  80.2 MBytes   673 Mbits/sec
> [  5]  15.00-16.00  sec  74.5 MBytes   625 Mbits/sec
> 
> [Rx Counter]:
>  * CCA (CCK, OFDM, Total) = (0, 2455, 2455)
>  * False Alarm (CCK, OFDM, Total) = (0, 69, 69)
>  * CCK cnt (ok, err) = (0, 0)
>  * OFDM cnt (ok, err) = (1239, 2)
>  * HT cnt (ok, err) = (0, 0)
>  * VHT cnt (ok, err) = (21, 12109)
> 
> The "VHT ok" number is not believable.

Since these counters are from BB, I don't doubt this is USB specific problem.
But really not sure what BB happens on receiving long packets.
So, let's take this workaround that improves over 100Mbits/sec.

> 
> And without SUPPORTS_AMSDU_IN_AMPDU:
> 
> Reverse mode, remote host 192.168.0.1 is sending
> [  5] local 192.168.0.50 port 50030 connected to 192.168.0.1 port 5201
> [ ID] Interval           Transfer     Bitrate
> [  5]   0.00-1.00   sec  70.5 MBytes   591 Mbits/sec
> [  5]   1.00-2.00   sec  86.9 MBytes   729 Mbits/sec
> [  5]   2.00-3.00   sec  98.6 MBytes   827 Mbits/sec
> [  5]   3.00-4.00   sec  97.4 MBytes   817 Mbits/sec
> [  5]   4.00-5.00   sec  98.6 MBytes   827 Mbits/sec
> [  5]   5.00-6.00   sec  96.9 MBytes   813 Mbits/sec
> [  5]   6.00-7.00   sec  98.2 MBytes   824 Mbits/sec
> [  5]   7.00-8.00   sec  98.0 MBytes   822 Mbits/sec
> [  5]   8.00-9.00   sec  99.9 MBytes   838 Mbits/sec
> [  5]   9.00-10.00  sec  99.2 MBytes   833 Mbits/sec
> [  5]  10.00-11.00  sec  98.0 MBytes   822 Mbits/sec
> [  5]  11.00-12.00  sec  98.1 MBytes   823 Mbits/sec
> [  5]  12.00-13.00  sec  97.0 MBytes   814 Mbits/sec
> [  5]  13.00-14.00  sec  98.2 MBytes   824 Mbits/sec
> [  5]  14.00-15.00  sec  98.5 MBytes   826 Mbits/sec
> [  5]  15.00-16.00  sec  97.4 MBytes   817 Mbits/sec
> 
> [Rx Counter]:
>  * CCA (CCK, OFDM, Total) = (0, 3860, 3860)
>  * False Alarm (CCK, OFDM, Total) = (0, 2, 2)
>  * CCK cnt (ok, err) = (0, 0)
>  * OFDM cnt (ok, err) = (1486, 0)
>  * HT cnt (ok, err) = (0, 0)
>  * VHT cnt (ok, err) = (7399, 9118)
> 
> Add a new member "amsdu_in_ampdu" in struct rtw_chip_info and use it
> to set SUPPORTS_AMSDU_IN_AMPDU only for the other chips.
> 
> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>

Acked-by: Ping-Ke Shih <pkshih@realtek.com>



      reply	other threads:[~2025-03-17  3:31 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-13 20:15 [PATCH rtw-next 0/4] Improve RTL8814AU performance Bitterblue Smith
2025-03-13 20:16 ` [PATCH rtw-next 1/4] wifi: rtw88: usb: Enable switching the RTL8814AU to USB 3 Bitterblue Smith
2025-03-17  2:52   ` Ping-Ke Shih
2025-03-13 20:17 ` [PATCH rtw-next 2/4] wifi: rtw88: usb: Enable RX aggregation for RTL8814AU Bitterblue Smith
2025-03-17  2:53   ` Ping-Ke Shih
2025-03-13 20:18 ` [PATCH rtw-next 3/4] wifi: rtw88: Set AMPDU factor to hardware Bitterblue Smith
2025-03-17  3:01   ` Ping-Ke Shih
2025-03-17 13:24     ` Bitterblue Smith
2025-03-18  2:06       ` Ping-Ke Shih
2025-03-18 18:41         ` Bitterblue Smith
2025-03-19  0:28           ` Ping-Ke Shih
2025-03-19 22:02             ` Bitterblue Smith
2025-03-20  0:38               ` Ping-Ke Shih
2025-03-21 17:36                 ` Bitterblue Smith
2025-03-24  0:39                   ` Ping-Ke Shih
2025-03-13 20:20 ` [PATCH rtw-next 4/4] wifi: rtw88: Don't set SUPPORTS_AMSDU_IN_AMPDU for RTL8814AU Bitterblue Smith
2025-03-17  3:31   ` Ping-Ke Shih [this message]

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=003857401c0245d7aa9a29c8806cb558@realtek.com \
    --to=pkshih@realtek.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=rtl8821cerfe2@gmail.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;
as well as URLs for NNTP newsgroup(s).