Bug 219173 - mt7921e relatively low WiFi speed and signal strength in Linux vs. Windows
Summary: mt7921e relatively low WiFi speed and signal strength in Linux vs. Windows
Status: RESOLVED IMPLEMENTED
Alias: None
Product: Drivers
Classification: Unclassified
Component: network-wireless (show other bugs)
Hardware: All Linux
: P3 high
Assignee: drivers_network-wireless@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks: 219429
  Show dependency tree
 
Reported: 2024-08-18 13:55 UTC by Artem S. Tashkinov
Modified: 2024-12-27 15:14 UTC (History)
1 user (show)

See Also:
Kernel Version:
Subsystem:
Regression: No
Bisected commit-id:


Attachments
iperf3 log from sending data from my local server to my laptop (which uses MT7922) (15.78 KB, text/plain)
2024-09-18 16:33 UTC, Daniel Gibson
Details

Description Artem S. Tashkinov 2024-08-18 13:55:46 UTC
I'm running Linux 6.9.12/6.10.5 and the latest firmware.

The device is MEDIATEK Corp. MT7922 802.11ax PCI Express Wireless Network Adapter [14c3:0616].

Under Linux the average connection speed is ~576 Mb/s (108-720).
Under Windows the constant connection speed is 1200 Mb/s. The Windows drivers used are version 3.3.0.972.

My laptop is stationary and there's a single 5GHz 80MHz access point.

dmesg messages:
mt7921e 0000:01:00.0: enabling device (0000 -> 0002)
mt7921e 0000:01:00.0: ASIC revision: 79220010
mt7921e 0000:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20240716163242a
mt7921e 0000:01:00.0: WM Firmware Version: ____000000, Build Time: 20240716163327

Please fix.

For Linux:
$ md5sum *bin
01e6eb558cd8911d8646ae6f0e833b14  BT_RAM_CODE_MT7922_1_1_hdr.bin
d058aaa17e44502ee3017779088602a2  WIFI_MT7922_patch_mcu_1_1_hdr.bin
09434126955898757e4c4c7efc386c5c  WIFI_RAM_CODE_MT7922_1.bin

$ strings BT_RAM_CODE_MT7922_1_1_hdr.bin | grep 202
20240716163633
_NEPTUNE_BORA_CI_BUILD_TAG_INFO_ = t-neptune-mp-mt7922e1-2012-MT7922_E1_MAIN_ASIC_ROM_RAM_MOBILE_CCN16-20240716163157

$ strings WIFI_MT7922_patch_mcu_1_1_hdr.bin | grep 202
20240716163242a

$ strings WIFI_MT7922_patch_mcu_1_1_hdr.bin | grep 202
20240716163242a

For Windows:
md5sum *bin
3f3b027121884da00e8d6ad7d362ef3d  BT_RAM_CODE_MT7922_1_1_hdr.bin
90d752d30115d1da807ce827585a13bc  WIFI_MT7922_patch_mcu_1_1_hdr.bin
0965b3968076821fbcda398a87f42b3b  WIFI_RAM_CODE_MT7922_1.bin

They contain the following strings:

$ strings BT_RAM_CODE_MT7922_1_1_hdr.bin | grep 202
20240122003900
_NEPTUNE_BORA_CI_BUILD_TAG_INFO_ = t-neptune-main-sta-2017-MT7922_E1_MAIN_ASIC_ROM_RAM_MOBILE_CCN10-20240122003354

$ strings WIFI_MT7922_patch_mcu_1_1_hdr.bin | grep 202
20240303123432a

$ strings WIFI_RAM_CODE_MT7922_1.bin | grep 202
t-neptune-main-sta-2017-MT7922_E1_MAIN_ASIC_ROM_RAM_MOBILE_CCN10-20240303123351
____00000020240303123513
Comment 1 Artem S. Tashkinov 2024-08-18 15:57:20 UTC
I've tried to replace Linux firmware files with Windows files, sadly it didn't work:

mt7921e 0000:01:00.0: enabling device (0000 -> 0002)
mt7921e 0000:01:00.0: ASIC revision: 79220010
mt7921e 0000:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20240303123432a
mt7921e 0000:01:00.0: WM Firmware Version: ____000000, Build Time: 20240303123513
mt7921e 0000:01:00.0 wlp1s0: renamed from wlan0
mt7921e 0000:01:00.0: Message 00020001 (seq 9) timeout
mt7921e 0000:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20240303123432a
mt7921e 0000:01:00.0: WM Firmware Version: ____000000, Build Time: 20240303123513
mt7921e 0000:01:00.0: Message 00020001 (seq 15) timeout
mt7921e 0000:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20240303123432a
mt7921e 0000:01:00.0: WM Firmware Version: ____000000, Build Time: 20240303123513
mt7921e 0000:01:00.0: Message 00020001 (seq 6) timeout
mt7921e 0000:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20240303123432a
mt7921e 0000:01:00.0: WM Firmware Version: ____000000, Build Time: 20240303123513
mt7921e 0000:01:00.0: Message 00020001 (seq 12) timeout
mt7921e 0000:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20240303123432a
mt7921e 0000:01:00.0: WM Firmware Version: ____000000, Build Time: 20240303123513
mt7921e 0000:01:00.0: Message 00020001 (seq 6) timeout
mt7921e 0000:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20240303123432a
mt7921e 0000:01:00.0: WM Firmware Version: ____000000, Build Time: 20240303123513
mt7921e 0000:01:00.0: Message 00020001 (seq 14) timeout
mt7921e 0000:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20240303123432a
mt7921e 0000:01:00.0: WM Firmware Version: ____000000, Build Time: 20240303123513
mt7921e 0000:01:00.0: Message 00020001 (seq 9) timeout
mt7921e 0000:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20240303123432a
mt7921e 0000:01:00.0: WM Firmware Version: ____000000, Build Time: 20240303123513
mt7921e 0000:01:00.0: Message 00020001 (seq 3) timeout
mt7921e 0000:01:00.0: ASIC revision: 79220010
mt7921e 0000:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20240716163242a
mt7921e 0000:01:00.0: WM Firmware Version: ____000000, Build Time: 20240716163327
mt7921e 0000:01:00.0 wlp1s0: renamed from wlan0
Comment 2 Artem S. Tashkinov 2024-08-18 16:10:01 UTC
I've tried to use sufficiently old firmware files but it didn't help:

for i in *.bin; do echo -e "** $i **"; strings $i | grep 202; done

** BT_RAM_CODE_MT7922_1_1_hdr.bin **
20240219103618
-_NEPTUNE_BORA_CI_BUILD_TAG_INFO_ = t-neptune-mp-mt7922e1-2012-MT7922_E1_MAIN_ASIC_ROM_RAM_MOBILE_CCN16-20240219103153

** WIFI_MT7922_patch_mcu_1_1_hdr.bin **
20240219103244a

** WIFI_RAM_CODE_MT7922_1.bin **
t-neptune-mp-mt7922e1-2012-MT7922_E1_MAIN_ASIC_ROM_RAM_MOBILE_CCN16-20240219103153
____00000020240219103337

What's the worst, with these particular versions I'm looking at 216 Mbps connection speed.
Comment 3 Daniel Gibson 2024-09-17 18:38:28 UTC
I have similar problems on my Framework 13 AMD laptop that also has a MT7922 wifi card, and so do other users of Framework laptops, see for example https://community.frame.work/t/responded-framework-13-amd-linux-slow-wifi/42937

I'm currently using kernel 6.10.10 and the latest firmware (mt7921e 0000:01:00.0: WM Firmware Version: ____000000, Build Time: 2024071616332), with Arch Linux.

I noticed the following, while downloading a 3GB file through http from another local machine in my network; during testing with my Fritz!Box I was at most 2m away from the AP:

* This only seems to happen with Wifi-6 Access Points (both with my
  Fritz!Box Cable 6660 and a friend’s Netgear AP) - Wifi-5 APs seem to work fine
  and have decent performance (in my test 70-80MB/s)
* As far as I can tell (from running watch -n1 iwconfig while testing) this only
  happens at 5GHz (Frequency:5.6 GHz or similar), at 2.4GHz it seems to be more 
  stable and I get 30-40MB/s (which maybe isn’t super-great, but 10x as fast as 
  what I get with 5GHz)
  => This means that the problem can appear resolved (after an update or randomly)
     if a users current connection happens to use 2.4GHz
* Usually (at 5GHz) the download or copying starts relatively fast (around 50MB/s 
  or so) and then over time degrades to 2-4MB/s, even though iwconfig shows a
  high Bit Rate (>800Mbit/s, often >1000) and good Link Quality
* I tried disabling Wifi powersave (iw dev wlan0 set power_save off) but it didn't
  make a difference
Comment 4 Artem S. Tashkinov 2024-09-17 18:59:28 UTC
Here's some info:

$ for i in `seq 10`; do iwconfig wlan0 | grep -E "Bit Rate|ink Quality"; sleep 10; done
          Bit Rate=648.5 Mb/s   Tx-Power=3 dBm   
          Link Quality=47/70  Signal level=-63 dBm  
          Bit Rate=576.4 Mb/s   Tx-Power=3 dBm   
          Link Quality=45/70  Signal level=-65 dBm  
          Bit Rate=576.4 Mb/s   Tx-Power=3 dBm   
          Link Quality=49/70  Signal level=-61 dBm  
          Bit Rate=648.5 Mb/s   Tx-Power=3 dBm   
          Link Quality=51/70  Signal level=-59 dBm  
          Bit Rate=648.5 Mb/s   Tx-Power=3 dBm   
          Link Quality=46/70  Signal level=-64 dBm  
          Bit Rate=576.4 Mb/s   Tx-Power=3 dBm   
          Link Quality=45/70  Signal level=-65 dBm  
          Bit Rate=576.4 Mb/s   Tx-Power=3 dBm   
          Link Quality=46/70  Signal level=-64 dBm  
          Bit Rate=576.4 Mb/s   Tx-Power=3 dBm   
          Link Quality=46/70  Signal level=-64 dBm  
          Bit Rate=648.5 Mb/s   Tx-Power=3 dBm   
          Link Quality=46/70  Signal level=-64 dBm  
          Bit Rate=576.4 Mb/s   Tx-Power=3 dBm   
          Link Quality=46/70  Signal level=-64 dBm  

Under Windows it's 1200Mbps uplink/downlink. So, under Linux I get on average just 48% of the available throughput.

There are no other Wi-Fi routers using my 5GHz channel. I've not tested 2.4GHz because it's insufficient for me - I have a 1Gbps Internet connection, so I'm forced to use the 5GHz bandwidth. And then there are close to twenty 2.4GHz access points nearby, so 2.4GHz cannot work well even in theory.

And just like for Daniel, `iw wlan0 set power_save off` does nothing for me.
Comment 5 Artem S. Tashkinov 2024-09-17 19:07:14 UTC
I've tried to disable ASPM and it had an even worse effect as the link speed decreased to 288Mbps.
Comment 6 Daniel Gibson 2024-09-17 19:57:33 UTC
This isn't just about the bit rate - for me it shows a bitrate of >800Mbit/s, but still only reaches 2-4 MByte/s.
I'm not sure if the bitrate shown there can at least theoretically be reached, and what it means exactly.

Have you tried actually copying (downloading, whatever) a big file to see what real speed you get? Might also be interesting to compare Windows and Linux there (I only have Linux on my laptop).


By the way, the access points I've tested with:
* My Fritz!Box 6660 Cable 
  (see https://boxmatrix.info/wiki/FRITZ!Box_6660_Cable#Hardware for details
  on the hardware in there)
* A friend's Netgear WiFi 6 AX1800 (WAX214v2), using their latest official
  firmware (1.0.2.4). OpenWRT has information on the hardware (apparently it uses
  a MediaTek MT2621AT chipset): https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=f25cd55bd1d13d2b89fefd4b1a88198ece1f8bbf
Comment 7 Artem S. Tashkinov 2024-09-18 11:20:53 UTC
I've run some tests because it looks like it's either Windows 10 that's buggy or the Mediatek drivers, it's hard to say which.

TLDR:

1. Windows is faster but not so much.
2. In Windows the Wi-Fi connection speed is incorrectly reported as 1201/1201Mbps when in reality it's much lower.

Results:

------------------------ Windows 10 64 ------------------------

Reverse mode (-R):

c:\iperf3.17.1_64>iperf3.exe -R -c 192.168.0.100
Connecting to host 192.168.0.100, port 5201
Reverse mode, remote host 192.168.0.100 is sending
[  5] local 192.168.1.101 port 49934 connected to 192.168.0.100 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  62.1 MBytes   520 Mbits/sec
[  5]   1.00-2.00   sec  61.9 MBytes   518 Mbits/sec
[  5]   2.00-3.01   sec  60.6 MBytes   508 Mbits/sec
[  5]   3.01-4.00   sec  61.2 MBytes   517 Mbits/sec
[  5]   4.00-5.01   sec  61.5 MBytes   509 Mbits/sec
[  5]   5.01-6.01   sec  58.5 MBytes   492 Mbits/sec
[  5]   6.01-7.01   sec  55.0 MBytes   464 Mbits/sec
[  5]   7.01-8.01   sec  56.2 MBytes   471 Mbits/sec
[  5]   8.01-9.00   sec  55.4 MBytes   466 Mbits/sec
[  5]   9.00-10.01  sec  56.6 MBytes   474 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.02  sec   593 MBytes   497 Mbits/sec    2             sender
[  5]   0.00-10.01  sec   589 MBytes   494 Mbits/sec                  receiver

iperf Done.


Normal mode:

c:\iperf3.17.1_64>iperf3.exe -c 192.168.0.100
Connecting to host 192.168.0.100, port 5201
[  5] local 192.168.1.101 port 49938 connected to 192.168.0.100 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  13.4 MBytes   112 Mbits/sec
[  5]   1.00-2.01   sec  13.1 MBytes   109 Mbits/sec
[  5]   2.01-3.00   sec  13.0 MBytes   110 Mbits/sec
[  5]   3.00-4.01   sec  13.4 MBytes   111 Mbits/sec
[  5]   4.01-5.01   sec  12.9 MBytes   108 Mbits/sec
[  5]   5.01-6.00   sec  13.6 MBytes   115 Mbits/sec
[  5]   6.00-7.00   sec  13.2 MBytes   112 Mbits/sec
[  5]   7.00-8.01   sec  13.2 MBytes   110 Mbits/sec
[  5]   8.01-9.01   sec  13.1 MBytes   110 Mbits/sec
[  5]   9.01-10.00  sec  12.9 MBytes   109 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.00  sec   132 MBytes   111 Mbits/sec                  sender
[  5]   0.00-10.05  sec   132 MBytes   110 Mbits/sec                  receiver

iperf Done.

------------------------ Linux 6.10.7 ------------------------

Reverse mode (-R):

$ iperf3 -R -c 192.168.0.100
Connecting to host 192.168.0.100, port 5201
Reverse mode, remote host 192.168.0.100 is sending
[  5] local 192.168.0.101 port 56190 connected to 192.168.0.100 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  57.1 MBytes   479 Mbits/sec                  
[  5]   1.00-2.00   sec  52.8 MBytes   443 Mbits/sec                  
[  5]   2.00-3.00   sec  46.8 MBytes   392 Mbits/sec                  
[  5]   3.00-4.00   sec  41.5 MBytes   348 Mbits/sec                  
[  5]   4.00-5.00   sec  45.1 MBytes   379 Mbits/sec                  
[  5]   5.00-6.00   sec  50.2 MBytes   422 Mbits/sec                  
[  5]   6.00-7.00   sec  44.5 MBytes   373 Mbits/sec                  
[  5]   7.00-8.00   sec  41.2 MBytes   346 Mbits/sec                  
[  5]   8.00-9.00   sec  41.5 MBytes   348 Mbits/sec                  
[  5]   9.00-10.00  sec  39.4 MBytes   330 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   463 MBytes   388 Mbits/sec    3             sender
[  5]   0.00-10.00  sec   460 MBytes   386 Mbits/sec                  receiver

iperf Done.


Normal mode:

$ iperf3 -c 192.168.0.100
Connecting to host 192.168.0.100, port 5201
[  5] local 192.168.0.101 port 33088 connected to 192.168.0.100 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  9.00 MBytes  75.4 Mbits/sec    0    341 KBytes       
[  5]   1.00-2.00   sec  18.5 MBytes   155 Mbits/sec    0    729 KBytes       
[  5]   2.00-3.00   sec  20.9 MBytes   175 Mbits/sec    0    952 KBytes       
[  5]   3.00-4.00   sec  20.4 MBytes   171 Mbits/sec    0   1.06 MBytes       
[  5]   4.00-5.00   sec  22.2 MBytes   187 Mbits/sec    0   1.12 MBytes       
[  5]   5.00-6.00   sec  20.8 MBytes   174 Mbits/sec    0   1.12 MBytes       
[  5]   6.00-7.00   sec  20.6 MBytes   173 Mbits/sec    0   1.12 MBytes       
[  5]   7.00-8.00   sec  11.5 MBytes  96.4 Mbits/sec    0   1.12 MBytes       
[  5]   8.00-9.00   sec  19.0 MBytes   159 Mbits/sec    0   1.12 MBytes       
[  5]   9.00-10.00  sec  20.2 MBytes   170 Mbits/sec    0   1.12 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   183 MBytes   154 Mbits/sec    0             sender
[  5]   0.00-10.01  sec   180 MBytes   151 Mbits/sec                  receiver

iperf Done.

What I find extremely weird and confusing is why iperf3 is so terribly slow in "normal" mode as opposed to "reverse" mode.
Comment 8 Daniel Gibson 2024-09-18 16:30:47 UTC
Gahhh this fscking piece of shit bugtracker just logged me out when trying to post a comment I wrote for half an hour or so and lost everything I wrote -_-
I should really remember to paste everything into a text editor before trying to post..

-------------

In your iperf tests, which machine was the client and which the server?

I also did iperf3 tests yesterday, and I ran iperf3 -s (the server) on a machine connected by cable to my LAN, and the client (iperf3 -c $SERVER_IP) on my laptop. I ran the tests for a longer time (with "-t 0", so it ran until I cancelled them on the client with ctrl-c).

I got relatively stable 400-550MBit/s when sending data from my laptop to the server (this is the "normal" mode when running the client on the laptop), but a noticeably lower bitrate and much more fluctuation when sending data from the server to my laptop ("reverse mode").

Here's an excerpt of the log, from the server side, as it has more information (I'll attach the full log later as iperf-reverse-server.txt):

[  5] local 192.168.178.33 port 5201 connected to 192.168.178.36 port 33622
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  4.75 MBytes  39.8 Mbits/sec  137   90.5 KBytes
[  5]   1.00-2.00   sec  1.12 MBytes  9.44 Mbits/sec   96   33.9 KBytes
[  5]   2.00-3.00   sec  1.88 MBytes  15.7 Mbits/sec   71   1.41 KBytes
[  5]   3.00-4.00   sec   256 KBytes  2.10 Mbits/sec   43   5.66 KBytes
[  5]   4.00-5.00   sec  2.00 MBytes  16.8 Mbits/sec   77   33.9 KBytes
...
[  5]  69.00-70.00  sec  22.6 MBytes   190 Mbits/sec  123   2.00 MBytes
[  5]  70.00-71.00  sec  26.8 MBytes   224 Mbits/sec  138   1.50 MBytes
[  5]  71.00-72.00  sec  26.1 MBytes   219 Mbits/sec  276   1.11 MBytes
[  5]  72.00-73.00  sec  12.0 MBytes   101 Mbits/sec  640    287 KBytes
[  5]  73.00-74.00  sec  4.12 MBytes  34.6 Mbits/sec  219   1.41 KBytes
[  5]  74.00-75.00  sec  5.75 MBytes  48.2 Mbits/sec  158    127 KBytes
[  5]  75.00-76.00  sec  7.25 MBytes  60.8 Mbits/sec  172    304 KBytes
[  5]  76.00-77.00  sec  7.25 MBytes  60.8 Mbits/sec  229    362 KBytes
[  5]  77.00-78.00  sec  1.38 MBytes  11.5 Mbits/sec  125   1.41 KBytes
[  5]  78.00-79.00  sec  0.00 Bytes  0.00 bits/sec  198   25.5 KBytes
[  5]  79.00-80.00  sec  4.25 MBytes  35.7 Mbits/sec   50    157 KBytes
[  5]  80.00-81.00  sec  7.00 MBytes  58.7 Mbits/sec  118    482 KBytes
[  5]  81.00-82.00  sec  19.9 MBytes   167 Mbits/sec    0   1.46 MBytes
...
[  5] 169.00-170.00 sec  20.1 MBytes   169 Mbits/sec    0   3.93 MBytes
[  5] 170.00-171.00 sec  27.1 MBytes   228 Mbits/sec  272   1.86 MBytes
[  5] 171.00-172.00 sec  35.8 MBytes   300 Mbits/sec  128    988 KBytes
[  5] 172.00-173.00 sec  11.5 MBytes  96.5 Mbits/sec  456    247 KBytes
[  5] 173.00-174.00 sec  8.88 MBytes  74.4 Mbits/sec   93   1.41 KBytes
[  5] 174.00-175.00 sec  0.00 Bytes  0.00 bits/sec   10   2.83 KBytes
[  5] 175.00-176.00 sec  2.62 MBytes  22.0 Mbits/sec  154   5.66 KBytes
[  5] 176.00-177.00 sec  0.00 Bytes  0.00 bits/sec    6   2.83 KBytes
[  5] 177.00-178.00 sec  0.00 Bytes  0.00 bits/sec   90   2.83 KBytes
[  5] 178.00-179.00 sec  11.9 MBytes  99.6 Mbits/sec   71    547 KBytes
[  5] 179.00-180.00 sec  7.25 MBytes  60.8 Mbits/sec  187    338 KBytes
...
[  5] 217.00-218.00 sec  7.25 MBytes  60.8 Mbits/sec   83    414 KBytes
[  5] 218.00-219.00 sec  12.4 MBytes   104 Mbits/sec  462    247 KBytes
[  5] 219.00-220.00 sec  6.00 MBytes  50.3 Mbits/sec   12   1.41 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-220.00 sec  2.30 GBytes  89.8 Mbits/sec  28514             sender

So the bitrate reported by iperf fluctuates between 0 bits/s and 300Mbits/s and there are lots of retransmits.

While running the tests, iwconfig always reported bitrates of at least 720Mbit/s, but mostly 960Mbit/s to 1.2Gbit/s, and very high link quality (62-70/70, usually >= 67)

When running the same test over my Wifi-5 Access Point, I get about 650Mbit/s in both directions in iperf (sometimes it slows down to 200-250, but most of the time it was >500Mbit/s), and had fewer retransmissions (none except in the first interval when sending from the laptop to the server, usually <= 32 when sending from the server to the laptop).

Not sure if the retransmission count has much meaning. I think it *can* indicate packetloss or corrupted packets, but it can also be normal apparently: When I run iperf between two machines connected through 2.5Gbit ethernet, iperf reports >300 retransmissions per second, but still achieves around 2.35Gbit/s
Comment 9 Daniel Gibson 2024-09-18 16:33:09 UTC
Created attachment 306892 [details]
iperf3 log from sending data from my local server to my laptop (which uses MT7922)

By the way, another affected access point from another Framework laptop user:
Sagemcom F@st 3896, which has a Broadcom BCM3390 inside.
Comment 10 Artem S. Tashkinov 2024-09-18 16:51:38 UTC
Are you sure you've got no other access points using the same Wi-Fi channel?

You could use your smartphone to check it out. Any WiFi analyzer app will do.

I still think our cases are different enough, you may want to file a new bug report. At least my connection is relatively stable and I have no packet loss.

Still, not a single MediaTek wireless developer is on this bug tracker, so it seems extremely unlikely anything will ever be done.

The best mode of action would be to try to post your very descriptive issue to LKML and CC the people who have really contributed to your driver. You can find them via git log, e.g. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/net/wireless/mediatek/mt76
Comment 11 Daniel Gibson 2024-09-18 17:02:28 UTC
> Are you sure you've got no other access points using the same Wi-Fi channel

the channel is automatically selected, I'd expect it to eventually choose one that isn't overcrowded. Also, if it's the channel, why would sending data work much better than receiving?

> I still think our cases are different enough, you may want to file a new bug
> report.

*Maybe* have different issues, yours just sounded similar enough at first - and you too seem to have the weird behavior that one direction is much faster than the other (386Mbit/s vs 151Mbit/s - which measurement corresponds to sending from your laptop and which to receiving?)
Comment 12 Daniel Gibson 2024-09-21 02:48:49 UTC
For some reason, this problem mostly disappeared for me.
About half a day before my ordered Intel AX210 card, that I wanted to use to make sure the problem was on the WiFi card/driver's side and not with the access point, arrived, it became faster and more stable - even though I didn't change/update anything.
The bitrate displayed by iwconfig increased from about 1Gbit to about 2Gbit (or some negative number because iwconfig doesn't handle speeds above 2Gbit properly due to using a signed int32) and the receiving speed (on the laptop) according to iperf3 increased from an average of 90-100Mbit/s (with streaks of about 30Mbit and some seconds of 0, see above) to 250-350Mbit/s, and the sending speed increased from 650Mbit/s to about 800Mbit/s.

The AX210 achieves even more: About 300-400Mbit/s for receiving and 1.1Gbit/s for sending - so it's a bit faster, but sending still is a lot faster than receiving, for whatever reason. That's very weird, but apparently not specific to the MT7922.

I'm not 100% sure but I *think* that the channel width used to be 40MHz and now is 160MHz, which would probably explain the speedup and probably stability as well.
But I might misremember, because iwconfig doesn't show the channel width so I only saw it occasionally when looking at my access points configuration UI.
Should've used wavemon right from the start..

However, I'm still not convinced that the problem was (is?) entirely with my setup (AP, local interference, whatever), because originally I ran into this at a friends place where copying files to my laptop was really slow, while it worked just fine with his laptop connected to the same AP, even when putting the laptops to the same positions.. I'll have to do more testing next time I visit him.
Comment 13 Artem S. Tashkinov 2024-12-27 15:14:35 UTC
I don't know what fixed it but in 6.12.6 both speed and signal strength are now comparable to Windows.

mt7921e 0000:01:00.0: enabling device (0000 -> 0002)
mt7921e 0000:01:00.0: ASIC revision: 79220010
mt7921e 0000:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20241106163228a
mt7921e 0000:01:00.0: WM Firmware Version: ____000000, Build Time: 20241106163310
mt7921e 0000:01:00.0 wlp1s0: renamed from wlan0

Note You need to log in before you can comment on or make changes to this bug.