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
Comments
Pinging off the Google nameserver I get for a 100 ping run: Switching to my router I get: I then tested ping with the -s 1023 so that 1031 bytes were in each paclet: That does indeed look bad, but when I look at the performance against a LibreSpeed instance on my local network, I get 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.
My WiFi setup is Ubiquiti-based, I'm just below the NanoHD AP, connected with good signal:
I do feel the latency a lot when connecting to remove hosts over SSH. Setup was done two hours ago, using current
I am also seeing some firmware errors from time to time:
I gave a try to disabling powersaving features when loading the
|
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 Both tests carried out over 2 minutes and averages taken. |
My results for a count of 100 packets: 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. |
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? 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. (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. @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
|
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 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 It also looks like it might be more visible over IPv6 (dont ask me why):
Then after a reboot:
|
I'm having the exact same issue and I've tried The only thing that did reduce the latency a little was commenting out the defines enabling debug output in the Makefile:
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:
While in 2.4 GHz mode, ping looks quite good:
This is an excerpt from lswh:
Edit: in the same LAN, other devices work well at 5 GHz. Regards |
I have no idea what is wrong. On the 5G band, I get --- 192.168.1.1 ping statistics --- 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 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:
And so far, under similar conditions as before, it seems to behave adequately:
And the link level info:
|
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 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:
|
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.
|
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.
|
I own a Lenovo legion 5 15ach6h as well, been watching this issue for a bit over a year now. |
same issue with rtl8852be wireless module on my new Xiaomi Redmi Book 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). 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. 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 |
What utility produces those graphs? That is new for me. |
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 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. |
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. |
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. |
In 2023, using the
On Ubuntu, Pre- |
Lenovo legion 5 15ach6h, fresh new ubuntu install, didnt have wifi, so i installed the driver from here
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
The text was updated successfully, but these errors were encountered: