rtw89
rtw89 copied to clipboard
lwfinger
poor latency performance
Lenovo legion 5 15ach6h, fresh new ubuntu install, didnt have wifi, so i installed the driver from here
description: Ethernet interface
product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
vendor: Realtek Semiconductor Co., Ltd.
physical id: 0
bus info: pci@0000:03:00.0
logical name: eno1
version: 15
serial: 38:f3:ab:b7:a4:33
capacity: 1Gbit/s
width: 64 bits
clock: 33MHz
capabilities: pm msi pciexpress msix bus_master cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=5.11.0-25-generic firmware=rtl8168h-2_0.0.2 02/26/15 latency=0 link=no multicast=yes port=twisted pair
resources: irq:42 ioport:3000(size=256) memory:d1704000-d1704fff memory:d1700000-d1703fff
*-network
description: Wireless interface
product: Realtek Semiconductor Co., Ltd.
vendor: Realtek Semiconductor Co., Ltd.
physical id: 0
bus info: pci@0000:04:00.0
logical name: wlp4s0
version: 00
serial: 74:4c:a1:d1:2e:8f
width: 64 bits
clock: 33MHz
capabilities: pm msi pciexpress bus_master cap_list ethernet physical wireless
configuration: broadcast=yes driver=rtw89_pci driverversion=5.11.0-25-generic firmware=N/A ip=192.168.1.147 latency=0 link=yes multicast=yes wireless=IEEE 802.11
resources: irq:78 ioport:2000(size=256) memory:d1600000-d16fffff
very noticable thing is the poor performance of WIFI when compared to Windows (i got two systems)
tried both 2.4 GHz/ 5.0 GHz, same results, on Windows ping is constantly in 32-36 ms range
Pinging off the Google nameserver I get for a 100 ping run: --- 8.8.8.8 ping statistics --- 100 packets transmitted, 99 received, 1% packet loss, time 99147ms rtt min/avg/max/mdev = 26.552/152.069/304.084/49.422 ms
Switching to my router I get: --- 192.168.1.1 ping statistics --- 100 packets transmitted, 100 received, 0% packet loss, time 99279ms rtt min/avg/max/mdev = 0.791/53.856/205.208/45.003 ms
I then tested ping with the -s 1023 so that 1031 bytes were in each paclet: --- 192.168.1.1 ping statistics --- 100 packets transmitted, 100 received, 0% packet loss, time 99142ms rtt min/avg/max/mdev = 1.672/53.424/115.303/30.384 ms
That does indeed look bad, but when I look at the performance against a LibreSpeed instance on my local network, I get ping 1.40 jitter 0.68 Download 596 Mbps Upload 482 Mbps
All results were obtained using an 802.11ac router at a distance of 1m and in the 5GHz band. Packet aggregation really helps.
I will pass this issue upstream to Realtek to see what they have to say. All I can say is that the driver seems to be better in real-life situations than when sending 84 byte packets.
Hello,
Just received and transfered my old Ubuntu 21.04 setup from ThinkPad T480s to brand new ThinkPad P14s AMD Gen2, and i'm also seeing similar behavior.
$ mtr --report -4 serveur.home
Start: 2021-09-01T21:59:43+0200
HOST: portable-alex Loss% Snt Last Avg Best Wrst StDev
1.|-- serveur.home 0.0% 10 66.7 108.9 1.3 259.4 99.9
$ mtr --report -4 livebox.home
Start: 2021-09-01T22:00:16+0200
HOST: portable-alex Loss% Snt Last Avg Best Wrst StDev
1.|-- livebox.home 0.0% 10 17.3 118.0 1.7 265.3 97.5
My WiFi setup is Ubiquiti-based, I'm just below the NanoHD AP, connected with good signal:
$ iw dev wlp3s0 link
Connected to xx:xx:xx:xx:xx:xx (on wlp3s0)
SSID: Livebox-xxxx
freq: 5200
RX: 948960108 bytes (442782 packets)
TX: 730634198 bytes (403251 packets)
signal: -39 dBm
rx bitrate: 866.7 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 2
tx bitrate: 866.7 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 2
bss flags: short-preamble short-slot-time
dtim period: 3
beacon int: 100
I do feel the latency a lot when connecting to remove hosts over SSH.
Setup was done two hours ago, using current v5 branch as documented.
dmesg while loading:
[ 18.375992] rtw89core: loading out-of-tree module taints kernel.
[ 18.385250] rtw89core: module verification failed: signature and/or required key missing - tainting kernel
[ 18.391541] rtw89_pci 0000:03:00.0: enabling device (0000 -> 0003)
[ 18.396413] rtw89_pci 0000:03:00.0: Firmware version 0.13.8.0, cmd version 0, type 1
[ 18.396417] rtw89_pci 0000:03:00.0: Firmware version 0.13.8.0, cmd version 0, type 3
[ 18.415400] rtw89_pci 0000:03:00.0: chip rfe_type is 1
[ 18.467795] rtw89_pci 0000:03:00.0 wlp3s0: renamed from wlan0
I am also seeing some firmware errors from time to time:
[ 811.007817] rtw89_pci 0000:03:00.0: FW status = 0x98008000
[ 811.007824] rtw89_pci 0000:03:00.0: FW BADADDR = 0x0
[ 811.007828] rtw89_pci 0000:03:00.0: FW EPC/RA = 0x0
[ 811.007831] rtw89_pci 0000:03:00.0: FW MISC = 0xb898faa3
[ 811.007834] rtw89_pci 0000:03:00.0: R_AX_HALT_C2H = 0x10
[ 811.007836] rtw89_pci 0000:03:00.0: R_AX_SER_DBG_INFO = 0x32000003
[ 811.007843] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb8990811
[ 811.007862] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb899090d
[ 811.007927] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb8990921
[ 811.007944] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb8990923
[ 811.007957] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb899081d
[ 811.007970] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb8990825
[ 811.007983] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb89908f7
[ 811.007997] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb8990833
[ 811.008010] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb89908fb
[ 811.008023] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb899081f
[ 811.008036] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb8990809
[ 811.008049] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb8990913
[ 811.008062] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb8990905
[ 811.008076] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb8990915
[ 811.008089] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb8990913
[ 811.008101] rtw89_pci 0000:03:00.0: --->
[ 811.008104] rtw89_pci 0000:03:00.0: R_AX_SER_DBG_INFO =0x32000003
[ 811.008106] rtw89_pci 0000:03:00.0: R_AX_CMAC_ERR_ISR =0x00000000
[ 811.008109] rtw89_pci 0000:03:00.0: R_AX_DMAC_ERR_ISR =0x00000000
[ 811.008111] rtw89_pci 0000:03:00.0: R_AX_RPQ_RXBD_IDX =0x00b600b6
[ 811.008114] rtw89_pci 0000:03:00.0: R_AX_DBG_ERR_FLAG=0x00000000
[ 811.008116] rtw89_pci 0000:03:00.0: R_AX_LBC_WATCHDOG=0x00000041
[ 811.008118] rtw89_pci 0000:03:00.0: <---
[ 811.008119] rtw89_pci 0000:03:00.0: ser event = 0x0010
[ 811.008393] rtw89_pci 0000:03:00.0: FW status = 0x98008000
[ 811.008402] rtw89_pci 0000:03:00.0: FW BADADDR = 0x0
[ 811.008405] rtw89_pci 0000:03:00.0: FW EPC/RA = 0x0
[ 811.008408] rtw89_pci 0000:03:00.0: FW MISC = 0xb898faa3
[ 811.008411] rtw89_pci 0000:03:00.0: R_AX_HALT_C2H = 0x1001
[ 811.008413] rtw89_pci 0000:03:00.0: R_AX_SER_DBG_INFO = 0x32000003
[ 811.008420] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb899081f
[ 811.008438] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb89908f9
[ 811.008452] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb8990821
[ 811.008465] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb899090f
[ 811.008478] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb8990831
[ 811.008492] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb8990811
[ 811.008505] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb8990921
[ 811.008518] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb89908ff
[ 811.008531] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb8990825
[ 811.008544] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb899080b
[ 811.008557] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb8990929
[ 811.008570] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb89908f7
[ 811.008583] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb899090f
[ 811.008596] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb8990827
[ 811.008610] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb899090d
[ 811.008621] rtw89_pci 0000:03:00.0: ser event = 0x1001
[ 811.008749] rtw89_pci 0000:03:00.0: FW status = 0x98008100
[ 811.008753] rtw89_pci 0000:03:00.0: FW BADADDR = 0x0
[ 811.008756] rtw89_pci 0000:03:00.0: FW EPC/RA = 0x0
[ 811.008759] rtw89_pci 0000:03:00.0: FW MISC = 0xb898efdb
[ 811.008762] rtw89_pci 0000:03:00.0: R_AX_HALT_C2H = 0x1002
[ 811.008764] rtw89_pci 0000:03:00.0: R_AX_SER_DBG_INFO = 0x32000003
[ 811.008770] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb893a607
[ 811.008807] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb89c21e9
[ 811.008824] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb897d2a5
[ 811.008838] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb893a66f
[ 811.008851] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb89c18e5
[ 811.008864] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb89c213d
[ 811.008877] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb893955d
[ 811.008891] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb89394cf
[ 811.008904] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb89c14ad
[ 811.008917] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb89b947f
[ 811.008931] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb893a66d
[ 811.008944] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb89c18e5
[ 811.008958] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb893a609
[ 811.008971] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb89b56cb
[ 811.008984] rtw89_pci 0000:03:00.0: [ERR]fw PC = 0xb8935657
[ 811.008996] rtw89_pci 0000:03:00.0: ser event = 0x1002
[ 811.085691] rtw89_pci 0000:03:00.0: c2h class 1 func 3 not support
I gave a try to disabling powersaving features when loading the rtw89core module via disable_ps_mode=Y, and so far, it seems to improve:
$ mtr --report -4 -n serveur.home
Start: 2021-09-01T22:32:54+0200
HOST: portable-alex Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.1.98 0.0% 10 1.8 5.2 1.1 38.7 11.8
Also getting this.
Brand new Lenovo L15 Gen 2 with Kubuntu 21.10 and Xanmod 5.14 kernel, rtw89 module cloned and installed today.
Ping to 8.8.8.8 with rtw89: 130ms
Typical ping to 8.8.8.8: 50-55ms (as measured from other laptop, android phone and other devices on local network)
Both tests carried out over 2 minutes and averages taken.
My results for a count of 100 packets: 8.8.8.8: rtt min/avg/max/mdev = 21.207/71.991/142.968/32.375 ms 192.168.1.51: rtt min/avg/max/mdev = 0.953/9.268/107.538/23.600 ms
Did you use a 2.4 or 5 GHz connection? How crowded is that band?
This type of issue is not one that I can handle. I did not write the driver, and I have no knowledge of the internals of the chip. You need to file a report at [email protected]. Note that that ML rejects all HTML mail. You need to submit plain text.
2.4 vs 5Ghz wouldn't produce a 60ms latency difference. Also there is no crowding on the band at all. 2 or 3 devices connected to the router at once.
Seeing as I and several others are experiencing latency errors with this driver, it seems a legitimate issue.
Did you log an issue upstream with Realtek as you wrote on 16 Aug? If so, do we also need to log this with [email protected]?
PS I'm not sure what your latest ping results are intended to show.
How many other routers are active in your environment? They count too.
Yes, you need to file all such complaints at linux-wireless. I did tell my contact about the problem, but I have not heard anything back. My ping results show that in a quiet environment at 5G, the ping return times are small.
There are zero other routers in my environment - I'm not in a built-up area. Also, even if there were routers or other external factors involved, those factors would also be present when running the Windows Realtek driver for the device, and they would also impact other devices (eg my HP notebook and my Android phone) when running the same ping test on the same network.
(If you have a Windows installation with this device, that is a good general comparison test to run against the rtw89 driver).
I have done isolated tests to verify the higher latency, and it confirms what multiple other technical users have demonstrated here.
(Note: I have noticed that it improves/degrades as the performance profile changes on the host - partially confirming what @lissyx reported. I don't have a replication scenario yet though.)
Therefore, I would consider this NOT to be a red herring, and it was definitely worthwhile submitting the issue to Realtek. I will register the issue with linux-wireless when I get a chance,.
@lwfinger I appreciate your effort on this project, and I hope things improve as the driver is merged into the upcoming mainline kernel (as I read is happening here: https://www.phoronix.com/scan.php?page=news_item&px=Realtek-802.11ax-rtw89).
FTR, uptodate Ubuntu/Hirsute on ThinkPad P14s Gen2 AMD, current v7 branch, I have removed the workaround for disable_ps_mode=Y and I am now seeing normal pings:
$ mtr --report -4 -n serveur.home
Start: 2021-11-15T10:56:39+0100
HOST: portable-alex Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.1.98 0.0% 10 1.7 1.6 0.9 2.1 0.4
Why had you added the PS mode workaround?
For the latency issues i reported above.
What fixed it? Anything else changed?
I am unsure exactly, but the first reports was done against main branch from the date of that time, I think it was some v5-based. There has been several kernel upgrades (majors ones when I upgraded from ubuntu 21.04 to 21.10). Firmware is still the same. I'm currently running on your current v7 branch.
At least, I can state that I was experiencing the issue on the older setup, and it is not there anymore. I'm sorry I can't be more definitive on the actual fix.
It seems to be back using the rtw89 module bundled in current 5.13.0-23 from Ubuntu 21.10, after a set of suspend/resume, even though the modules (core and pci) were both unloaded prior suspend and reloaded after resume. I'll make sure it is known to the distro packager, I can't remember for sure what commits they have in their tree, but I think it might be useful for others to know.
It also looks like it might be more visible over IPv6 (dont ask me why):
$ mtr --report -4 -n serveur.home
Start: 2021-12-10T13:24:39+0100
HOST: portable-alex Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.1.98 0.0% 10 5.5 3.7 1.1 5.5 2.0
$ mtr --report -6 -n serveur.home
Start: 2021-12-10T13:24:58+0100
HOST: portable-alex Loss% Snt Last Avg Best Wrst StDev
1.|-- 2a01:xxxx:xxxx:xxxx:bdf9: 0.0% 10 4.8 82.4 4.8 253.4 81.5
Then after a reboot:
$ mtr --report -6 -n serveur.home
Start: 2021-12-10T13:33:23+0100
HOST: portable-alex Loss% Snt Last Avg Best Wrst StDev
1.|-- 2a01:xxxx:xxxx:xxxx:bdf9: 0.0% 10 0.9 1.7 0.9 3.5 0.7
$ mtr --report -4 -n serveur.home
Start: 2021-12-10T13:34:03+0100
HOST: portable-alex Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.1.98 0.0% 10 2.2 1.7 1.0 3.7 0.8
I'm having the exact same issue and I've tried disable_ps_mode=Y and v7 branch in this repo.
I'm running Debian 11 on a ThinkPad P14s Gen 2a.
The only thing that did reduce the latency a little was commenting out the defines enabling debug output in the Makefile:
EXTRA_CFLAGS += -DCONFIG_RTW89_DEBUGMSG
EXTRA_CFLAGS += -DCONFIG_RTW89_DEBUGFS
It's still horrible, but the latency spikes went from 200-500ms to around 80-100ms.
Same issue here, Thinkpad L14 gen2, Linux Mint, kernel 5.13.0-1026-oem, but ONLY in 5 GHz mode:
PING dsldevice.lan (192.168.0.1) 56(84) bytes of data.
64 bytes from dsldevice.lan (192.168.0.1): icmp_seq=1 ttl=64 time=333 ms
64 bytes from dsldevice.lan (192.168.0.1): icmp_seq=2 ttl=64 time=98.3 ms
64 bytes from dsldevice.lan (192.168.0.1): icmp_seq=3 ttl=64 time=684 ms
64 bytes from dsldevice.lan (192.168.0.1): icmp_seq=4 ttl=64 time=128 ms
64 bytes from dsldevice.lan (192.168.0.1): icmp_seq=5 ttl=64 time=1226 ms
64 bytes from dsldevice.lan (192.168.0.1): icmp_seq=6 ttl=64 time=215 ms
64 bytes from dsldevice.lan (192.168.0.1): icmp_seq=7 ttl=64 time=342 ms
64 bytes from dsldevice.lan (192.168.0.1): icmp_seq=8 ttl=64 time=380 ms
64 bytes from dsldevice.lan (192.168.0.1): icmp_seq=9 ttl=64 time=914 ms
64 bytes from dsldevice.lan (192.168.0.1): icmp_seq=10 ttl=64 time=326 ms
64 bytes from dsldevice.lan (192.168.0.1): icmp_seq=11 ttl=64 time=756 ms
While in 2.4 GHz mode, ping looks quite good:
64 bytes from dsldevice.lan (192.168.0.1): icmp_seq=1 ttl=64 time=3.56 ms
64 bytes from dsldevice.lan (192.168.0.1): icmp_seq=2 ttl=64 time=2.44 ms
64 bytes from dsldevice.lan (192.168.0.1): icmp_seq=3 ttl=64 time=6.90 ms
64 bytes from dsldevice.lan (192.168.0.1): icmp_seq=4 ttl=64 time=6.77 ms
64 bytes from dsldevice.lan (192.168.0.1): icmp_seq=5 ttl=64 time=12.4 ms
64 bytes from dsldevice.lan (192.168.0.1): icmp_seq=6 ttl=64 time=2.58 ms
64 bytes from dsldevice.lan (192.168.0.1): icmp_seq=7 ttl=64 time=3.09 ms
64 bytes from dsldevice.lan (192.168.0.1): icmp_seq=8 ttl=64 time=1.99 ms
This is an excerpt from lswh:
*-network
description: Wireless interface
product: Realtek Semiconductor Co., Ltd.
vendor: Realtek Semiconductor Co., Ltd.
physical id: 0
bus info: pci@0000:03:00.0
logical name: wlp3s0
version: 00
serial: 74:4c:a1:de:c4:99
width: 64 bits
clock: 33MHz
capabilities: pm msi pciexpress bus_master cap_list ethernet physical wireless
configuration: broadcast=yes driver=rtw89_pci driverversion=5.13.0-1026-oem firmware=N/A ip=192.168.0.39 latency=0 l
ink=yes multicast=yes wireless=IEEE 802.11
resources: irq:80 ioport:2000(size=256) memory:fd500000-fd5fffff
Edit: in the same LAN, other devices work well at 5 GHz.
Regards Aldo
I have no idea what is wrong. On the 5G band, I get
--- 192.168.1.1 ping statistics --- 50 packets transmitted, 50 received, 0% packet loss, time 49060ms rtt min/avg/max/mdev = 0.927/1.580/3.257/0.652 ms
Those are good statistics. I am running the latest code from this repo. There are no special kernel commands, nor am I loading with any module parameters.
Keeping an eye on that, updated to latest main yesterday alongside with latest 1.15 UEFI (P14s AMD Gen2 ; Ubuntu 21.10 with 5.13.0-38-generic) especially since release notes mentions Linux S3 improvements, I'm always connected on 5GHz, roaming seems not to be an issue.
I have not yet had the chance to give a try to a cycle of suspend/resume with this new setup.
I've disabled the hack to disable power sleep:
$ cat /etc/modprobe.d/rtw89_thinkpad.conf
#options rtw89core disable_ps_mode=Y
And so far, under similar conditions as before, it seems to behave adequately:
$ mtr --report -6 serveur.home; mtr --report -4 serveur.home
Start: 2022-03-25T09:41:48+0100
HOST: portable-alex Loss% Snt Last Avg Best Wrst StDev
1.|-- serveur.home 0.0% 10 1.6 1.6 1.2 2.2 0.3
Start: 2022-03-25T09:42:04+0100
HOST: portable-alex Loss% Snt Last Avg Best Wrst StDev
1.|-- serveur.home 0.0% 10 1.2 1.5 1.1 2.1 0.3
And the link level info:
$ iw dev wlp3s0 link
Connected to xx (on wlp3s0)
SSID: yy
freq: 5200
RX: 3252619435 bytes (3857915 packets)
TX: 931251294 bytes (3859778 packets)
signal: -37 dBm
rx bitrate: 866.7 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 2
tx bitrate: 866.7 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 2
bss flags: short-slot-time
dtim period: 3
beacon int: 100
Using AUR repo (on Manjaro kernel 5.19), and also experiencing random latency spikes. I've noticed that running iperf3 actually reduces the latency. I've used Waveform Bufferbloat test, since it shows detailed latency tests (ignore bufferbloat results):
Without running iperf in background
With running iperf in background
As you can see, the overall latency results (mean values) are better when I have iperf3 running in the background. Basically, the "warm up" latency is the issue which is far greater in first test than second. Iperf3 is running with limited bandwidth -b 600K, when running below 500K, the results start to become worse, but didn't test more thoroughly.
I've seen people reporting the issues are fixed in recent commits, but I'm not sure which branch should I use? Any clarification on v5,6,7 branches vs main? I believe AUR uses main:
# Maintainer: Jerry Xiao <aur at mail.jerryxiao.cc>
_pkgbase=rtw89
_srcname=rtw89
_branch=main
pkgname=${_pkgbase}-dkms-git
pkgver=r178.f3ea327
pkgrel=1
epoch=1
pkgdesc="Driver for Realtek 8852AE, an 802.11ax device"
arch=('x86_64')
url="https://github.com/lwfinger/rtw89"
license=('GPL2')
makedepends=('git' 'xz')
depends=('dkms')
provides=("${_pkgbase}")
conflicts=("${_pkgbase}")
source=("$_srcname::git+https://github.com/lwfinger/rtw89.git#branch=${_branch}"
'dkms.conf')
sha256sums=('SKIP'
'3261b90709a41e7d1030d2365d8ee0d821275f8deba4825307c4de35013dbf8e')
install='rtw89-dkms-git.install'
build() {
cd "$srcdir/${_srcname}"
rm -fv dkms.conf
}
pkgver() {
cd "$srcdir/${_srcname}"
printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
}
package() {
# Copy dkms.conf
install -Dt "${pkgdir}/usr/src/${_pkgbase}-${pkgver}" -m644 dkms.conf
# Set name and version
sed -e "s/@_PKGBASE@/${_pkgbase}/" \
-e "s/@PKGVER@/${pkgver}/" \
-i "${pkgdir}"/usr/src/${_pkgbase}-${pkgver}/dkms.conf
# Copy sources (including Makefile)
cp -rT "$_srcname" "${pkgdir}/usr/src/${_pkgbase}-${pkgver}"
# This isn't the best solution but it works
# and does not require additional dependencies
rm -rfv "${pkgdir}/usr/src/${_pkgbase}-${pkgver}"/{.git,debian,.gitignore,README.md}
}
Branch main is the only one up to date.
This kind of problem is beyond my abilities to fix and should be reported in the manner stated in the last paragraph of README.md
Horrible interactive performance on ssh, still looking for a solution, on lenovo thinkpad using linux-oem-22.04a (5.17) kernel on ubuntu.
*-network
description: Wireless interface
product: RTL8852AE 802.11ax PCIe Wireless Network Adapter
vendor: Realtek Semiconductor Co., Ltd.
physical id: 0
bus info: pci@0000:03:00.0
logical name: wlo1
version: 00
serial: 14:5a:fc:01:c2:xx
width: 64 bits
clock: 33MHz
capabilities: pm msi pciexpress bus_master cap_list ethernet physical wireless
configuration: broadcast=yes driver=rtw89_pci driverversion=5.17.0-1014-oem firmware=N/A ip=192.168.x.x latency=0 link=yes multicast=yes wireless=IEEE 802.11
resources: irq:64 ioport:2000(size=256) memory:d1600000-d16fffff
```
So far I've had the best latency results with rtw89_8852ae with kernel 6.0.0rc6 and all modprobe options for the module removed.
01:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8852AE 802.11ax PCIe Wireless Network Adapter
I own a Lenovo legion 5 15ach6h as well, been watching this issue for a bit over a year now. After a few months of annoyances I bought an Intel WiFi NIC last year for about €20 and called it a day, never had any issues since.
same issue with rtl8852be wireless module on my new Xiaomi Redmi Book i have very unstable ping latency with my Mikrotik router located in 2m. I had never this issue with other devices and wireless controllers in the same environment. also I have very poor download performance (5-10Mb/s) in comparison upload performance (50-60Mb/s) in 2.4Ghz networks Some users reported that these issues is happen with some old routers especially with 2.4 band. Also they have the same issue in Windows. As I see, there are some specificity of working Realtek wifi module with some routers and some wireless configurations that explains why some users have this issues but some not Some users say that changing some options in windows driver solve the problem with performance partially: roaming aggressiveness -> disable, 802.11d -> off
I see a lot of options in Linux kernel module, and think we can solve the problem by just tuning some options, but I don't see options description and I don't know where to start
If you see a lot of options, then you are running the obsolete driver from https://github.com/lwfinger/rtw8852be.git. There are very few options for this repo - https://githib.com/lwfinger/rtw89.git, and all are documented in modinfo. The former driver will be deleted next week due to its inferior design and performance.
If your rtw89 driver does not see the firmware for the 8852be, then sudo {apt,dnf,zypper} install *firmware-realtek. If that repo does not exist, complain to your distro. The firmware for rtw8852be has been in the linux-firmware repo at vger.kernel.org since October 27. An alternative source is https://lwfinger.com/download/rtw8852b_fw.bin.
Noticing the same bad performance with this driver on the 8852BE (Haven't installed the obsolete driver). https://i.imgur.com/TbdyAji.png
Reported signal strength is 100% on the AC access point I am very close to (The AP tries to force 5GHz, so while KDE doesn't show it it is very likely to be using the 5GHz band).
I have a dual-boot with Windows on my machine and on the windows partition the loss, high ping and high jitter isn't present.
Turning powersafe off as suggested above decreased the latency and jitter, but the loss remains high in this speed.cloudflare.com test. The jitter is also still higher than in Windows. https://i.imgur.com/eW4uFcO.png
Its worth noting that the ping times are consistently small on my end when testing with regular pings, I think "high ping" is a redherring for the jitter and the loss. When less is going on the real ping times are as expected.
And here is the Windows result by comparison : https://i.imgur.com/CrnLPVv.png
That is cloudflare's speedtest available at speed.cloudflare.com, interestingly enough after taking the Windows screenshot and using Windows for a bit I booted back to Linux to see if I could resolve the issue but was unable to reproduce it afterwards, despite having rebooted prior between the different screenshots. So for now it is behaving correctly (With the powersafe still off) and I do not yet know what the difference is between the two test runs.
Got an update on the situation, the remaining difference in loss could be explained by a firefox vs chrome difference. Using the same browser engine with the disable_ps_mode=Y tweak results in a stable experience. I no longer experience the loss and latency issues I was having in games. Neither do I have the constant buffering I had on videos. It has been stable all evening now.
So the disable_ps_mode=Y is a must, and I do recommend to make this the default value (or tweak the powersaving mode if possible) since without it the experience is very poor for the end user.
Which browser is better?
You would have to take up the disable_ps_mode issue with the authors through the linux-wireless mailing list [email protected], but as this is not a problem for most people, and battery life is a bigger concern, I doubt that they will agree with you. In any case, my code follows the upstream driver as present in the wireless-next repo at vger.kernel.org. The only differences are those needed to build on older kernels. The repo always has the code for the next kernel. It now has v6.2 wireless stuff.