Search Linux Wireless

Re: Slow RTL8822CE 802.11ac PCIe Wireless Network Adapter

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 4/5/23 00:42, Larry Finger wrote:
On 5/3/23 02:13, Alexey Kardashevskiy wrote:
Hi!

I am seeing dropouts in 5GHz and 2.5GHz wifi and seeking for help.

HP laptop with RTL8822CE 802.11ac PCIe Wireless Network Adapter, Fedora36 with 6.2.9-100.fc36.x86_64, the AP is Ubiquity, it is 5m away behind a thin wall, a house in low density area (I do not see neighbors APs in "iw dev scan").

Pinging a gateway (1gbit ethernet between AP and GW) suddenly goes from 3-5ms to  >1000ms. Good and bad "iw" output is below. Moving laptop by 2cm (or its lid) helps sometime.

These 2 observation made me suspect the linux driver:

1) If I reboot the laptop to Windows10 without moving/touching it after it went bad in linux - there pings are 1-2ms and occasionally may go up to hundreds but for a very short time, feels like the driver notices something and fixes it.

2) Two other laptops with Intel Wifi cards on the same spot with the same fedora on the same network do not show the problem at all.

Changing txpower 10..23dBm (where 2300 is the maximum) does not help, done via "iw dev wlp1s0 set txpower limit 2300", "iw dev wlp1s0 info" confirms that it changes.

I have these in /etc/modprobe.d/50-rtw88.conf
options rtw88_core disable_lps_deep=y
options rtw88_pci disable_aspm=y
no change either.

Is there anything else to try? Thanks,


64 bytes from _gateway (192.168.10.200): icmp_seq=26 ttl=64 time=6.97 ms
64 bytes from _gateway (192.168.10.200): icmp_seq=27 ttl=64 time=3.68 ms
64 bytes from _gateway (192.168.10.200): icmp_seq=28 ttl=64 time=3.44 ms
64 bytes from _gateway (192.168.10.200): icmp_seq=29 ttl=64 time=3.97 ms
64 bytes from _gateway (192.168.10.200): icmp_seq=30 ttl=64 time=3.68 ms
64 bytes from _gateway (192.168.10.200): icmp_seq=31 ttl=64 time=17.0 ms
64 bytes from _gateway (192.168.10.200): icmp_seq=32 ttl=64 time=33.1 ms
64 bytes from _gateway (192.168.10.200): icmp_seq=33 ttl=64 time=697 ms
64 bytes from _gateway (192.168.10.200): icmp_seq=34 ttl=64 time=1130 ms
64 bytes from _gateway (192.168.10.200): icmp_seq=35 ttl=64 time=114 ms
64 bytes from _gateway (192.168.10.200): icmp_seq=36 ttl=64 time=1796 ms
64 bytes from _gateway (192.168.10.200): icmp_seq=37 ttl=64 time=749 ms

Good status:

[root@aiemdeew wlp1s0]# iw dev wlp1s0 info ; iw wlp1s0 link
Interface wlp1s0
     ifindex 2
     wdev 0x1
     addr 50:c2:e8:5d:ba:fd
     type managed
     wiphy 0
     channel 36 (5180 MHz), width: 80 MHz, center1: 5210 MHz
     txpower 22.00 dBm
     multicast TXQ:
         qsz-byt    qsz-pkt    flows    drops    marks    overlmt hashcol tx-bytes    tx-packets
         0    0    0    0    0    0    0    0        0
Connected to f4:92:bf:04:1a:ce (on wlp1s0)
     SSID: aikhomenet
     freq: 5180
     RX: 37035326 bytes (60439 packets)
     TX: 2880943 bytes (14231 packets)
     signal: -53 dBm
     rx bitrate: 130.0 MBit/s VHT-MCS 7 VHT-NSS 2
     tx bitrate: 390.0 MBit/s VHT-MCS 4 80MHz short GI VHT-NSS 2

     bss flags:    short-slot-time
     dtim period:    2
     beacon int:    100


Bad status:

Interface wlp1s0
         ifindex 2
         wdev 0x1
         addr 50:c2:e8:5d:ba:fd
         type managed
         wiphy 0
         channel 36 (5180 MHz), width: 80 MHz, center1: 5210 MHz
         txpower 22.00 dBm
         multicast TXQ:
                 qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes        tx-packets
                 0    0    0    0    0    0    0    0               0
Connected to f4:92:bf:04:1a:ce (on wlp1s0)
         SSID: aikhomenet
         freq: 5180
         RX: 38078401 bytes (68758 packets)
         TX: 3039702 bytes (15006 packets)
         signal: -62 dBm
         rx bitrate: 117.0 MBit/s VHT-MCS 6 VHT-NSS 2
         tx bitrate: 433.3 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 1

         bss flags:    short-slot-time
         dtim period:    2
         beacon int:     100


Something certainly changed for your signal strength to drop from -53 to -62 dBm. The higher value is acceptable, but will not provide high data rates. The lower value is marginal.

Well, one of the other laptops (Intel nic) reports -68 dBm and pings are solid 2ms. The one with realtek reports -61dBm and pings are 3.5ms+. Never saw 2ms with Realtek in Fedora but I saw that in Windows10. But probably Windows' ping calculates times differently :)

There are some changes between kernel 6.2 and the current contents of the wireless-next repo, which is the code to be found in kernel 6.4 when it is released. Could you try the code in https://github.com/lwfinger/rtw88.git? This repo has the code found in wireless-next modified to build on older kernels. You would need to blacklist rtw88_8822ce. This sequence should do it for you:

sudo dnf install git kernel-headers kernel-devel
sudo dnf group install "C Development Tools and Libraries"
git clone https://github.com/lwfinger/rtw88.git
cd rtw88
make
sudo make install
sudo touch /usr/lib/modprobe.d/50-blacklist-8822ce.conf

As root, using your favorite editor, add the following line to the above file:
blacklist rtw88_8822ce

Then reboot. Report if there are any changes. This way, we will be able to determine if the problem has already been fixed.

My bad, I should have mentioned that I tried this one as well, https://github.com/lwfinger/rtw88/commit/75e2c81 3weeks old, no difference there.

And it does not look like there was any change related to my problem since then, is it still worth trying the very latest version? Btw reboot is not really required, it is Linux, not Windows, rmmod+modprobe should do ;) Thanks,


--
Alexey



[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux