Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

poor latency performance #36

Closed
paulmil1 opened this issue Aug 16, 2021 · 33 comments
Closed

poor latency performance #36

paulmil1 opened this issue Aug 16, 2021 · 33 comments

Comments

@paulmil1
Copy link

paulmil1 commented Aug 16, 2021

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)
image
tried both 2.4 GHz/ 5.0 GHz, same results, on Windows ping is constantly in 32-36 ms range

@lwfinger
Copy link
Owner

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.

@lissyx
Copy link

lissyx commented Sep 1, 2021

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

@danryu
Copy link

danryu commented Oct 28, 2021

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.

@lwfinger
Copy link
Owner

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 linux-wireless@vger.kernel.org. Note that that ML rejects all HTML mail. You need to submit plain text.

@danryu
Copy link

danryu commented Oct 29, 2021

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 linux-wireless@vger.kernel.org?

PS I'm not sure what your latest ping results are intended to show.

@lwfinger
Copy link
Owner

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.

@danryu
Copy link

danryu commented Oct 30, 2021

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).

@lissyx
Copy link

lissyx commented Nov 15, 2021

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

@lwfinger
Copy link
Owner

Why had you added the PS mode workaround?

@lissyx
Copy link

lissyx commented Nov 15, 2021

Why had you added the PS mode workaround?

For the latency issues i reported above.

@lwfinger
Copy link
Owner

What fixed it? Anything else changed?

@lissyx
Copy link

lissyx commented Nov 15, 2021

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.

@lissyx
Copy link

lissyx commented Dec 10, 2021

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

@lammas
Copy link

lammas commented Jan 7, 2022

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.

@ldx63
Copy link

ldx63 commented Jan 15, 2022

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

@lwfinger
Copy link
Owner

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.

@lissyx
Copy link

lissyx commented Mar 25, 2022

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

@shudza
Copy link

shudza commented Jul 23, 2022

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}
}

@lwfinger
Copy link
Owner

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

@aathan
Copy link

aathan commented Aug 2, 2022

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
       ```

@mikaelhg
Copy link

mikaelhg commented Sep 25, 2022

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

@gfokkema
Copy link

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.

@archer-v
Copy link

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

@lwfinger
Copy link
Owner

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.

@lwfinger
Copy link
Owner

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.

@henk717
Copy link

henk717 commented Dec 1, 2022

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

@lwfinger
Copy link
Owner

lwfinger commented Dec 1, 2022

What utility produces those graphs? That is new for me.

@henk717
Copy link

henk717 commented Dec 1, 2022

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.

@henk717
Copy link

henk717 commented Dec 2, 2022

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.

@lwfinger
Copy link
Owner

lwfinger commented Dec 2, 2022

Which browser is better?

You would have to take up the disable_ps_mode issue with the authors through the linux-wireless mailing list linux-wireless@vger.kernel.org, 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.

@henk717
Copy link

henk717 commented Dec 2, 2022

Chrome based browsers are better on that speedtest, i think firefox just struggles with the test rather than it being an actual issue in the wifi on firefox.

The issues are pretty extreme on the power saving mode, in game I saw constant loss, but I could also not properly watch a livestream because of the constant long buffering. With the power saving mode disabled that was no issue.

On the windows driver I do not see a power saving ability like some other network cards have so I think on Windows its already taken out.

I thought your repository was the one being upstreamed, if that is not the case the only relevant info for this repo is that the power management disabling indeed worked.

@lwfinger
Copy link
Owner

lwfinger commented Dec 3, 2022

You have it a little backwards. There is a Linux group at Realtek that writes the drivers for inclusion in Linux. I have a good working arrangement with their leader - I'm kind of like a grandfather to him. I take that code, add the modifications needed to build on older kernels and post it here. Without this repo, users of RTW8852BE would need to wait until kernel 6.2 came out roughly 2 months from now.

The module parameters is these drivers are also part of the upstream drivers. Thus parameter disable_ps_mode applied to driver rtw89core from this repo will do exactly the same with rtw89_core from kernel 6.2. If your system needs that option with drivers from this repo, it will need it with kernel 6.2. The drivers are essentially identical!

My contact did send me their code before it was sent to the kernel, and I did some beta-level debugging for them, but I did not post it here until they submitted it to wireless-next. They also provided me with the 8852be hardware.

So there is a connection between upstream and this repo, but upstream is the source for this code.

@mikaelhg
Copy link

mikaelhg commented Jul 18, 2023

In 2023, using the rtw89_8852ae driver with the 6.4.2-060402-generic kernel, the factors which allowed me to minimize the latency of the wifi connection were:

  1. Upgrading to a 6.2+ kernel.

  2. Disabling NetworkManager's enabling of WiFi powersaving.

On Ubuntu, NetworkManager's configuration file was /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf, and the correct setting wifi.powersave = 2. Then sudo systemctl restart NetworkManager.

Pre-6.2, there were weekly kernel lockups requiring a REISUB restart, associated with very long-running Cisco VPN connections. Disabling wifi power saving also gave a noticeable boost to wifi throughput.

@lwfinger lwfinger closed this as completed Nov 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests