lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CAB4CAwdHPfi3rhQofxbH+yWJZnLJCFK+r901HZ6HLxmHPjkU4w@mail.gmail.com>
Date:   Fri, 3 May 2019 14:38:50 +0800
From:   Chris Chiu <chiu@...lessm.com>
To:     Jes Sorensen <jes.sorensen@...il.com>, kvalo@...eaurora.org,
        davem@...emloft.net
Cc:     linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
        Linux Kernel <linux-kernel@...r.kernel.org>,
        Linux Upstreaming Team <linux@...lessm.com>
Subject: Improve TX performance of RTL8723BU on rtl8xxxu driver

We have 3 laptops which connect the wifi by the same RTL8723BU.
The PCI VID/PID of the wifi chip is 10EC:B720 which is supported.
They have the same problem with the in-kernel rtl8xxxu driver, the
iperf (as a client to an ethernet-connected server) gets ~1Mbps.
Nevertheless, the signal strength is reported as around -40dBm,
which is quite good. From the wireshark capture, the tx rate for each
data and qos data packet is only 1Mbps. Compare to the driver from
https://github.com/lwfinger/rtl8723bu, the same iperf test gets ~12
Mbps or more. The signal strength is reported similarly around
-40dBm. That's why we want to find out the cause and improve.

After reading the source code of the rtl8xxxu driver and Larry's, the
major difference is that Larry's driver has a watchdog which will keep
monitoring the signal quality and updating the rate mask just like the
rtl8xxxu_gen2_update_rate_mask() does if signal quality changes.
And this kind of watchdog also exists in rtlwifi driver of some specific
chips, ex rtl8192ee, rtl8188ee, rtl8723ae, rtl8821ae...etc. They have
the same member function named dm_watchdog and will invoke the
corresponding dm_refresh_rate_adaptive_mask to adjust the tx rate
mask.

Thus I created 2 commits and try to do the same thing on rtl8xxxu.
https://github.com/endlessm/linux/commit/503d0b6eb61f25984042b1f00e6293776ae722c7
https://github.com/endlessm/linux/commit/5b06665766d6c3e25cbf649022989a8f3abc83d6
The 1st commit brings a data structure for rate adaptive which will be
useful for determining higher or lower the tx rate. The second commit
adds a watchdog to monitor and update the tx rate mask and tell the
firmware. After applying these commits, the tx rate of each data and
qos data packet will be 39Mbps (MCS4) with the 0xf00000 as its tx
rate mask. The 20th bit ~ 23th bit means MCS4 to MCS7. It means
that the firmware still picks the lowest rate from the rate mask and
explains why the tx rate of data and qos data is always lowest 1Mbps
because the default rate mask passed is almost 0xFFFFFFF ranges
from the basic CCK rate, OFDM rate, and MCS rate. However, with
Larry's driver, the tx rate observed from wireshark under the same
condition is almost 65Mbps or 72Mbps.

I believe the firmware of RTL8723BU may need fix. And I think we
can still bring in the dm_watchdog as rtlwifi to improve from the
driver side. Please leave precious comments for my commits and
suggest what I can do better to get them upstream. Or suggest if
there's any better idea to fix this. Thanks.

Chris

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ