Testing rtw_8822bu, feed back. (Slow bitrate) #224
Comments
|
Thank you for your detailed report. Something is still wrong with this chip. Unfortunately I don't have a device to test. |
|
I have several usb wifi adapters based on the rtl8812bu chip. We can worry about how to put one in your hands as we have time but for now, tell me what you want me to do. FYI: I've been sick this week. Am starting to feel a little better now. |
|
Afterthought: The rtl8812bu chip is likely the most popular Realtek chip in the hands of Linux users so it is a priority...once rtw_8821au and rtw_8812au have gone in. |
|
Test system: Here are two runs with iperf3: Quick conclusion: Slow bitrate is only in one direction. Hopefully that is enough to help you know where to start looking. Let me know what specific tests to run.
That is a very old unsupported command. Recommend you discontinue use. Tell us what you want to do and we can recommend modern supported commands. You can start with |
|
@morrownr Something to check is the TX and RX rates in wavemon when you see the low speed with iperf3. |
|
$ iperf3 -c 192.168.1.1 wavemon shows: rx rate: 86 Mbps, tx rate: 866 Mbps while iperf3 is running. $ iperf3 -c 192.168.1.1 -R wavemon shows: rx rate: 19 Mbps, tx rate: 866 Mbps while iperf3 is running. |
|
@morrownr @dubhater : i'm also noticing slow bandwith using 8822bu. [ ID] Interval Transfer Bitrate Retr iperf Done. |
|
Bitrate continues to degrade over time: $ iw wlxbcec4322ff20 link |
|
Drivers comparison in AP mode: Hardware: Kernel: Successful test of 802.11r: Questions:
|
Probably the following is largely the cause: [1/4] wifi: rtw88: Init RX burst length for 8822cu/8822bu/8821cu You can find that patch series at: https://patchwork.kernel.org/project/linux-wireless/list/ It was sent in yesterday by Dubhater. My opinion is that Realtek did not do a very good job with rtw88 and they included no support for USB. That has all come from the community. By the time we see kernel 6.12 released, you should see better performance with rtw88_8822bu and the other drivers in rtw88.
Dubhater can certainly answer this better than me but I'd rather keep him busy prepping patches for upstreaming the numerous patches that need to go upstream such as for the new rtl8821au and rtl8812au drivers. It is a lot of work. While performance for rtw_8822bu is currently much better than rtw88_8822bu, performance is not symmetrical as shown in the last iperf3 testing I posted above. Why that is is not known to me at this time but if anyone can get to the bottom of it, Dubhater can we need to allow him time to get all of the patches that need to go upstream on their way right now and then we can make a plan and start gathering information. This project covers a lot of drivers and it is complicated work. It will be very nice to see the many patches that are going into 6.12 in place so we can begin the process if depreciating the Reaktek out-of-kernel drivers. |
|
@morrownr |
|
Let me make sure I did not mislead you. Any patches that have gone in to go into the kernel are already in this repo. You can look at that patch series right here. |
|
@morrownr, |
|
Not sure if the following information is at all relevant. The laptop that I was testing the rtl8822bu just happened to have a PCI rtl8822ce for its Wifi adapter. When I use iw link it shows the RX bit rate is 175 but the TX bit rate is 600. I would rather that be the other way around but there may be a wider issue with the rtl driver. |
|
When I use rtw88 as an AP, my client reports a rx bitrate of 6.0MBit/s, tx bitrate is 390.0 MBit/s. |
|
From my testing it appears to drop under load. So the bit rate may start at 216 or higher but immediately after placing a load it will drop to 39. And when the load stops the bit rate will rise back up. Even when there is only a load on transmission the RX rate will drop. But only the RX bit rate will change. The TX seems completely steady. |
|
yes,help the question please 。rtw88_8822cs According to the same situation |
|
The AP usb fixes are now merged into rtw-next (https://github.com/pkshih/rtw.git), so I decided to try the driver that repo. This repo: rtw-next: I observe the same when I use my rtl8812bu adapter in AP mode. |
|
I bought a RTL8822BU adapter a few days ago and did some tests, I found this problem only occurred when the adapter was plugged into a USB 3.0 port. OS: Arch Linux (kernel version: 6.6.51-1-lts) Results:
|
|
@a5a5aa555oo Is it the same if you turn off RX aggregation? diff --git a/rtw8822b.c b/rtw8822b.c
index a4ad554..5636343 100644
--- a/rtw8822b.c
+++ b/rtw8822b.c
@@ -1642,7 +1642,7 @@ static void rtw8822b_rx_aggregation(struct rtw_dev *rtwdev, bool enable)
{
u8 size, timeout;
u16 val16;
-
+enable = false;
rtw_write32_set(rtwdev, REG_RXDMA_AGG_PG_TH, BIT_EN_PRE_CALC);
rtw_write8_set(rtwdev, REG_TXDMA_PQ_MAP, BIT_RXDMA_AGG_EN);
rtw_write8_clr(rtwdev, REG_RXDMA_AGG_PG_TH + 3, BIT(7)); |
|
After turning off RX aggregation, the result is a little different. RTL8822BU connected to a USB 2.0 port RTL8822BU connected to a USB 3.0 port I will test it one more time later to ensure this result is correct. EDIT: I got the same result in the second test. |
Some relevant information in case this is not known. The rtl8822bu is a USB2 chipset. The rtl8812bu is a USB3 chipset. The rtl8822bu includes BT support so USB support was limited to USB2. |
|
@a5a5aa555oo That's an interesting result. I looked at the code again and I still don't know what's wrong.
Thank you, I added one to my wishlist. @morrownr I guess people see the module name rtw_8822bu and assume the chip is also 8822. |
@dubhater , agree. My experience tells me the 8822bu chip is not popular. The 8812bu chip is very popular. People took note of the USB2 restriction with the 8822bu and decided they would rather have USB3 instead of BT. I agree with them. |
@dubhater RTL8822BU works good enough in USB 2.0 mode for me, so this is not an urgent problem.
I only see a Type-C GBE adapter and a 8812BU adapter. @morrownr |
|
The rtw_8822BU driver supports both the rtl8822bu and rtl8812bu chips. Until @dubhater added USB3 support to rtw_8822BU recently, the driver did not support USB3. USB3 is only needed for the rtl8812bu chip. If you see 5000M, indicating USB3, then the chip is a rtl8812bu. |
I assume RTL8812BU has the same problem because that's what @morrownr was testing. It is the same chip as RTL8822BU, just without Bluetooth. |
|
@dubhater I tried the vendor driver in morrow's repo and the speed looks fine. RTL8822BU connected to an USB 2.0 port RTL8822BU connected to an USB 3.0 port (module parameter: rtw_switch_usb_mode=1) @morrownr |
|
Of course, the vendor driver works. I was referring to this test @morrownr did with rtw88 and a RTL8812BU device: #224 (comment) |
|
I can confirm the receive slowdown issue only occurs when the device is plugged into a USB3 port. When plugged into a USB2 it works better!!! It's more than 3 times faster in the USB2 port. But if you monitor the receive transmit rates they constantly drop and raise when used with USB2 but on USB3 the rate drops and stays down. |
That's not supposed to be there. Fixes slow download with RTL8822BU in USB 3 mode. #224 Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
|
This bug is actually my fault. I tried to be smarter than the original code and simplified it, changing the order of operations in the process. I didn't notice the original code is a little broken. These chips need the broken behaviour: enum halmac_ret_status
cfg_usb_rx_agg_88xx(struct halmac_adapter *adapter,
struct halmac_rxagg_cfg *cfg)
{
u8 dma_usb_agg;
u8 size;
u8 timeout;
u8 agg_enable;
u32 value32;
struct halmac_api *api = (struct halmac_api *)adapter->halmac_api;
PLTFM_MSG_TRACE("[TRACE]%s ===>\n", __func__);
dma_usb_agg = HALMAC_REG_R8(REG_RXDMA_AGG_PG_TH + 3); // read byte 3
agg_enable = HALMAC_REG_R8(REG_TXDMA_PQ_MAP);
// ..... modify dma_usb_agg
value32 = HALMAC_REG_R32(REG_RXDMA_AGG_PG_TH);
if (cfg->threshold.size_limit_en == 0)
HALMAC_REG_W32(REG_RXDMA_AGG_PG_TH, value32 & ~BIT_EN_PRE_CALC);
else
HALMAC_REG_W32(REG_RXDMA_AGG_PG_TH, value32 | BIT_EN_PRE_CALC); // modify byte 3
HALMAC_REG_W8(REG_TXDMA_PQ_MAP, agg_enable);
HALMAC_REG_W8(REG_RXDMA_AGG_PG_TH + 3, dma_usb_agg); // discard previous modification
HALMAC_REG_W16(REG_RXDMA_AGG_PG_TH,
(u16)(size | (timeout << BIT_SHIFT_DMA_AGG_TO_V1)));
PLTFM_MSG_TRACE("[TRACE]%s <===\n", __func__);
return HALMAC_RET_SUCCESS;
}I pushed the fix. |
|
@dubhater Thanks, download speed is much faster now! 8822BU (USB 2.0) 8822BU (USB 3.0) |
|
rx/tx rate in wavemon are still very low, does the driver report the wrong value?
|
|
I think the RX channel width is wrong sometimes (often). |
System information follows at end.
Testing the rtw_8822bu(Simplecom NW621 AC1200 USB2/3 Techkey Wifi Adapter) from rtw88 downstream.
Can confirm USB3 is now working.
Having a bit rate issue on all systems testing exhibiting slow bit rate after initial connection. The two systems:
Both systems start with a high bite rate but after several seconds drop to around 135-180mbits and then never raise under net load.
Following is the system info for 1):
$ uname -a
Linux WZ-MS-7B51 6.5.0-44-generic #44~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue Jun 18 14:36:16 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
$ lsusb
Bus 002 Device 003: ID 0bda:b812 Realtek Semiconductor Corp. RTL88x2bu [AC1200 Techkey]
$ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 10000M
|__ Port 6: Dev 3, If 0, Class=Vendor Specific Class, Driver=rtw_8822bu, 5000M
$ mokutil --sb-state
SecureBoot disabled
Platform is in Setup Mode
$ rfkill list all
1: phy3: Wireless LAN
Soft blocked: no
Hard blocked: no
$ dkms status
nvidia/555.42.06, 5.15.0-116-generic, x86_64: installed
nvidia/555.42.06, 6.5.0-44-generic, x86_64: installed
rtl8812au/4.3.8.12175.20140902+dfsg, 5.15.0-116-generic, x86_64: installed
rtl8812au/4.3.8.12175.20140902+dfsg, 6.5.0-44-generic, x86_64: installed
rtl8821ce/5.5.2.1, 5.15.0-116-generic, x86_64: installed
$ iwconfig
lo no wireless extensions.
eno1 no wireless extensions.
wlxbcec4322ff20 IEEE 802.11 ESSID:"TCS"
Mode:Managed Frequency:5.2 GHz Access Point: 74:83:C2:B5:56:CA
Bit Rate=180 Mb/s Tx-Power=20 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Power Management:on
Link Quality=63/70 Signal level=-47 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:923 Missed beacon:0
$ iw reg get
global
country AU: DFS-ETSI
(2400 - 2483 @ 40), (N/A, 36), (N/A)
(5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5470 - 5600 @ 80), (N/A, 27), (0 ms), DFS
(5650 - 5730 @ 80), (N/A, 27), (0 ms), DFS
(5730 - 5850 @ 80), (N/A, 36), (N/A)
(5925 - 6425 @ 160), (N/A, 24), (N/A), NO-OUTDOOR
(57000 - 66000 @ 2160), (N/A, 43), (N/A), NO-OUTDOOR
$ iw dev
phy#3
Interface wlxbcec4322ff20
ifindex 4
wdev 0x300000001
addr bc:ec:43:22:ff:20
ssid TCS
type managed
channel 40 (5200 MHz), width: 40 MHz, center1: 5190 MHz
txpower 20.00 dBm
multicast TXQ:
qsz-byt qsz-pkt flows drops marks overlmt hashcoltx-bytes tx-packets
0 0 0 0 0 0 0 00
$ iperf3 -c 192.168.10.152
Connecting to host 192.168.10.152, port 5201
[ 5] local 192.168.10.104 port 52594 connected to 192.168.10.152 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 3.86 MBytes 32.3 Mbits/sec 1 284 KBytes
[ 5] 1.00-2.00 sec 9.64 MBytes 80.9 Mbits/sec 0 672 KBytes
[ 5] 2.00-3.00 sec 7.50 MBytes 62.9 Mbits/sec 0 942 KBytes
[ 5] 3.00-4.00 sec 8.75 MBytes 73.4 Mbits/sec 0 1007 KBytes
[ 5] 4.00-5.00 sec 6.25 MBytes 52.4 Mbits/sec 0 1.03 MBytes
[ 5] 5.00-6.00 sec 7.50 MBytes 62.9 Mbits/sec 0 1.16 MBytes
[ 5] 6.00-7.00 sec 7.50 MBytes 62.9 Mbits/sec 0 1.23 MBytes
[ 5] 7.00-8.00 sec 7.50 MBytes 62.9 Mbits/sec 0 1.23 MBytes
[ 5] 8.00-9.00 sec 7.50 MBytes 62.9 Mbits/sec 2 980 KBytes
[ 5] 9.00-10.00 sec 6.25 MBytes 52.4 Mbits/sec 0 1.04 MBytes
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 72.2 MBytes 60.6 Mbits/sec 3 sender
[ 5] 0.00-10.67 sec 69.4 MBytes 54.5 Mbits/sec receiver
$ cat /etc/modprobe.d/88x2bu.conf
blacklist rtw88_8822bu
blacklist rtw88_usb
blacklist rtw88_8822b
blacklist rtw88_core
options 88x2bu rtw_switch_usb_mode=1 rtw_led_ctrl=1
$ lsmod | grep rtw
rtw_8822bu 12288 0
rtw_usb 28672 1 rtw_8822bu
rtw_8822b 233472 1 rtw_8822bu
rtw_core 356352 2 rtw_usb,rtw_8822b
mac80211 1724416 2 rtw_usb,rtw_core
cfg80211 1323008 2 rtw_core,mac80211
The text was updated successfully, but these errors were encountered: