LorenzoBianconi / mt76

mac80211 driver for MediaTek MT76x2 802.11ac chips
29 stars 8 forks source link

mt76x2u RSSI and throughput are low when compared to Windows drivers #1

Closed araujorm closed 6 years ago

araujorm commented 6 years ago

Hello.

As said on https://github.com/openwrt/mt76/issues/139 the RSSI values are too low when using this driver in Linux, when compared on the same machine with Windows and its drivers. Also the throughput is considerably slower in Linux an inconstant when compared to Windows.

As an example, the same device EDUP AC 1605 has 96% of signal, and an iperf3 to a raspberry pi attached to the AC wifi router achieves constant 92 Mbps in Windows, whereas in Linux with mt76x2u driver the RSSI is 56/70 which is 80% of signal, and the same iperf3 test achieves irregular values ranging from 60 to 80 Mbps, with few spikes of 90 Mbps.

If there is anything you need me to test please feel free to ask.

Thank you and best regards.

LorenzoBianconi commented 6 years ago

@araujorm could you please provide the rssi value using iw? (Btw it is better to use iw instead of iwlist/iwconfig)

iw dev wlanX link

araujorm commented 6 years ago

@LorenzoBianconi Here's the output you requested:

Connected to <my_routers_bssid> (on wlp0s29u1u5)
    SSID: <myssid>
    freq: 5240
    RX: 68443 bytes (454 packets)
    TX: 3805 bytes (32 packets)
    signal: -50 dBm
    tx bitrate: 144.4 MBit/s MCS 15 short GI

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

Signal oscilates between -50 and -49. Then I went to check on windows, but natively it seems it only shows percentages. I had to use a 3rd party utility - http://www.nirsoft.net/utils/wifi_information_view.html - to see the actual signal value. Well, it also oscilates between -50 and -49, and says it's "100% quality".

Did I misinterpreted the values somewhere? Well, the fact is that Windows seems to think I have an excelent signal, but on linux, NetworkManager's applet never shows the full bars on the tray icon, as if I had like 80% of "full quality". Do you think this is meaningful, regarding the throughput problem? Could that be that the correct signal quality isn't being returned by the driver somewhere, making it slow down to "safer" speeds unnecessarily in Linux? (I understand some of these may not be the most correct terms, but please try to bear with me)

BTW, latest commits broke scanning completely for me. I had to revert to the one I was using yesterday - 75ea81f43e68d098558715acc2745ce871d8e475 - to be able to connect again.

LorenzoBianconi commented 6 years ago

@LorenzoBianconi https://github.com/LorenzoBianconi Here's the output you requested:

Connected to (on wlp0s29u1u5) SSID: freq: 5240 RX: 68443 bytes (454 packets) TX: 3805 bytes (32 packets) signal: -50 dBm tx bitrate: 144.4 MBit/s MCS 15 short GI

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

Signal oscilates between -50 and -49. Then I went to check on windows, but natively it seems it only shows percentages. I had to use a 3rd party utility - http://www.nirsoft.net/utils/wifi_information_view.html - to see the actual signal value. Well, it also oscilates between -50 and -49, and says it's "100% quality".

What is meaningful is the value (in dbm) reported by windows/linux driver, and AFAIU they are roughly the same (~-50dbm). Win/NM applets could have different thresholds to consider the RSSI good or optimum

Did I misinterpreted the values somewhere? Well, the fact is that Windows seems to think I have an excelent signal, but on linux, NetworkManager's applet never shows the full bars on the tray icon, as if I had like 80% of "full quality". Do you think this is meaningful, regarding the throughput problem? Could that be that the correct signal quality isn't being returned by the driver somewhere, making it slow down to "safer" speeds unnecessarily in Linux? (I understand some of these may not be the most correct terms, but please try to bear with me)

AFAIU the only issue here is mt76x2u can't get the same tpt as win driver

BTW, latest commits broke scanning completely for me. I had to revert to the one I was using yesterday - 75ea81f https://github.com/LorenzoBianconi/mt76/commit/75ea81f43e68d098558715acc2745ce871d8e475

  • to be able to connect again.

Yes, sorry. Could you please try latest commit (7c7eb24b79b7) Regards,

Lorenzo

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LorenzoBianconi/mt76/issues/1#issuecomment-389681829, or mute the thread https://github.com/notifications/unsubscribe-auth/ABwNCUdFmVv3hxPMBTWydxBtnl6jH_MCks5tzKOygaJpZM4UAfK9 .

-- UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch; unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp; umount; make clean; sleep

araujorm commented 6 years ago

As I said on https://github.com/openwrt/mt76/issues/139 the problems I'm still seeing with speed going up and down don't seem specific to mt76x2u, they also happen with the master branch and mt76x2 on openwrt. Latest commits seem to help stabilize, but there is still something happening that makes Nagle algorithm kick in on TCP connections more than it usually would as tests with iperf3 in UDP aren't affected and always seem to give stable high speeds (or it's just something specific to my environment that I can't pinpoint at this time). Maybe we should close this issue and just continue to debate that on openwrt/mt76, agreed? If you want me to close this issue, please feel free to ask.

LorenzoBianconi commented 6 years ago

@araujorm thx a lot for testing. I guess to close this issue since it is not strictly mt76x2u related.