lwfinger / rtl8723du

89 stars 43 forks source link

Periodic latency spikes #7

Closed mansr closed 3 years ago

mansr commented 3 years ago

I'm seeing a strange behaviour with the RTL8723DU. Every 2 seconds or so, there is a huge spike in latency, easily observable with a simple ping command:

PING 10.0.4.155 (10.0.4.155) 56(84) bytes of data.
64 bytes from 10.0.4.155: icmp_seq=1 ttl=64 time=719 ms
64 bytes from 10.0.4.155: icmp_seq=2 ttl=64 time=1.22 ms
64 bytes from 10.0.4.155: icmp_seq=3 ttl=64 time=800 ms
64 bytes from 10.0.4.155: icmp_seq=4 ttl=64 time=1.23 ms
64 bytes from 10.0.4.155: icmp_seq=5 ttl=64 time=878 ms
64 bytes from 10.0.4.155: icmp_seq=6 ttl=64 time=1.19 ms
64 bytes from 10.0.4.155: icmp_seq=7 ttl=64 time=956 ms
64 bytes from 10.0.4.155: icmp_seq=8 ttl=64 time=1.11 ms
64 bytes from 10.0.4.155: icmp_seq=9 ttl=64 time=1055 ms
64 bytes from 10.0.4.155: icmp_seq=10 ttl=64 time=36.9 ms

--- 10.0.4.155 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9023ms
rtt min/avg/max/mdev = 1.114/444.987/1054.864/444.541 ms, pipe 2

Notice how every second reply takes several hundred ms.

I have tried disabling every power management feature I could find without seeing any improvement, though I might have missed something. Any suggestions for fixing this would be appreciated.

kresa commented 3 years ago

I am experiencing exactly the same behaviour. I blamed my very slow notebook at first, but it seems like an issue with the wifi driver.

mansr commented 3 years ago

I did a little digging, and it appears that the latency is caused by incoming packets sitting in the device for some time before being received over USB. Is there a newer (or older) version of the firmware available anywhere? There seem to exist newer driver releases from Realtek, but I can't find anywhere to download them.

lwfinger commented 3 years ago

I sent a message to my contact at Realtek asking him if a newer version is available. I'll let you know his response.

mansr commented 3 years ago

Meanwhile, I tracked the problem down to the driver periodically initiating a roaming scan, blocking normal communication. This trivial change makes it not do that:

diff --git a/core/rtw_mlme.c b/core/rtw_mlme.c
index 364e819f59a7..789bfde9444f 100644
--- a/core/rtw_mlme.c
+++ b/core/rtw_mlme.c
@@ -102,8 +102,7 @@ static int  _rtw_init_mlme_priv(struct adapter *adapt)

        pmlmepriv->roam_flags = 0
                                | RTW_ROAM_ON_EXPIRED
-                               | RTW_ROAM_ON_RESUME
-                               | RTW_ROAM_ACTIVE;
+                               | RTW_ROAM_ON_RESUME;

        pmlmepriv->roam_scanr_exp_ms = RTW_ROAM_SCAN_RESULT_EXP_MS;
        pmlmepriv->roam_rssi_diff_th = RTW_ROAM_RSSI_DIFF_TH;
lwfinger commented 3 years ago

That leaves you with the problem that the device will not roam. For you, that might not be important, but perhaps it is for others.

My Realtek contact just came through and I just pushed v5.13.4 in a new branch. Please check that out and try it to see if Realtek fixed this.

mansr commented 3 years ago

Thanks. That version stalls in the same way only once every 30 seconds (instead of every 2 s). It's an improvement, but it's still not great.

lwfinger commented 3 years ago

If you do not want roaming, then change "y" to "n" in line 136 of the Makefile to disable that "feature". I hesitate to do it globally as some users might want to have roaming.

mansr commented 3 years ago

I'm fine with this as is. Will you be updating the master branch to this version?

lwfinger commented 3 years ago

No. The new code will remain in the v5.13.4 branch. That way users that found no problems with the master branch will have a stable source.