Re: Slow RTL8822CE 802.11ac PCIe Wireless Network Adapter

[Alexey Kardashevskiy <aik@amd.com>]

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