Hello,
I've been trying to track a performance regression on the RTL8723BE
WiFi adapter, which mainly affects the upload bandwidth (although we
can see a decreased download performance as well, the effect on upload
is more drastic). This was first reported by users after upgrading
from our 4.11-based kernel to our 4.13-based kernel, but also
confirmed to affect our development branch (4.15-based kernel) and
wireless-drivers-next at the
wireless-drivers-next-for-davem-2018-03-29 tag. This is happening on
an HP laptop that needs rtl8723be.ant_sel=1 (and all the following
tests have been made with that param).
My first bisect attempt pointed me to the following commit:
bcd37f4a0831 rtlwifi: btcoex: 23b 2ant: let bt transmit when hw
initialisation done
Which I later found to be already fixed by
a33fcba6ec01 rtlwifi: btcoexist: Fix breakage of ant_sel for rtl8723be.
That fix is already included in v4.15 though (and our dev branch as
well), so I did a second bisect, now cherry-picking a33fcba6ec01 at
every step, and it pointed me to the following commit:
7937f02d1953 rtlwifi: btcoex: hook external functions for newer chips
Reverting that commit on top of our development branch fixes the
problem, but on top of v4.15 I get mixed results: a few times getting
a good upload performance (~5-6Mbps) but most of the time just getting
~1-1.5Mpbs (which is still better than the 0.0 then test failure I've
gotten on most bad points of the bisect).
Bisecting the downstream patches we carry on top of v4.15 (we base our
kernel on Ubuntu's, so there are quite a few downstream changes) did
not bring any clarity, as at all bisect points (plus reverting
7937f02d1953) the performance was good, so probably there was some
other difference in the resulting kernels from my initial revert of
that patch on top of v4.15 and each step during the bisect. I've
experimented a bit with fwlps=0, but it did not bring any conclusive
results either. I'll try to look at other things that may have changed
(configuration perhaps?), but I don't have a clear plan yet.
Have you seen anything similar, or have any other ideas or suggestions
to track this problem? Even without crystal clear results, it looks
like 7937f02d1953 is having a negative impact on the RTL8723BE
performance, so perhaps it is worth reverting it and reworking it a
later point?
This are the results (testing with speedtest.net) I got at some key points:
Version Commit Ping Down Up
v4.11 a351e9b 12 25.44 5.99
v4.11 a351e9b 131 17.02 5.89
v4.13 569dbb8 174 14.08 0.00
v4.13 569dbb8 261 8.41 0.00
v4.15+revert d8a5b80 19 23.86 1.41
v4.15+revert d8a5b80 189 18.69 1.39
Best regards,
--
João Paulo Rechi Vita
http://about.me/jprvita
On 04/03/2018 08:51 PM, João Paulo Rechi Vita wrote:
> Hello,
>
> I've been trying to track a performance regression on the RTL8723BE
> WiFi adapter, which mainly affects the upload bandwidth (although we
> can see a decreased download performance as well, the effect on upload
> is more drastic). This was first reported by users after upgrading
> from our 4.11-based kernel to our 4.13-based kernel, but also
> confirmed to affect our development branch (4.15-based kernel) and
> wireless-drivers-next at the
> wireless-drivers-next-for-davem-2018-03-29 tag. This is happening on
> an HP laptop that needs rtl8723be.ant_sel=1 (and all the following
> tests have been made with that param).
>
> My first bisect attempt pointed me to the following commit:
>
> bcd37f4a0831 rtlwifi: btcoex: 23b 2ant: let bt transmit when hw
> initialisation done
>
> Which I later found to be already fixed by
>
> a33fcba6ec01 rtlwifi: btcoexist: Fix breakage of ant_sel for rtl8723be.
>
> That fix is already included in v4.15 though (and our dev branch as
> well), so I did a second bisect, now cherry-picking a33fcba6ec01 at
> every step, and it pointed me to the following commit:
>
> 7937f02d1953 rtlwifi: btcoex: hook external functions for newer chips
>
> Reverting that commit on top of our development branch fixes the
> problem, but on top of v4.15 I get mixed results: a few times getting
> a good upload performance (~5-6Mbps) but most of the time just getting
> ~1-1.5Mpbs (which is still better than the 0.0 then test failure I've
> gotten on most bad points of the bisect).
>
> Bisecting the downstream patches we carry on top of v4.15 (we base our
> kernel on Ubuntu's, so there are quite a few downstream changes) did
> not bring any clarity, as at all bisect points (plus reverting
> 7937f02d1953) the performance was good, so probably there was some
> other difference in the resulting kernels from my initial revert of
> that patch on top of v4.15 and each step during the bisect. I've
> experimented a bit with fwlps=0, but it did not bring any conclusive
> results either. I'll try to look at other things that may have changed
> (configuration perhaps?), but I don't have a clear plan yet.
>
> Have you seen anything similar, or have any other ideas or suggestions
> to track this problem? Even without crystal clear results, it looks
> like 7937f02d1953 is having a negative impact on the RTL8723BE
> performance, so perhaps it is worth reverting it and reworking it a
> later point?
>
> This are the results (testing with speedtest.net) I got at some key points:
>
> Version Commit Ping Down Up
>
> v4.11 a351e9b 12 25.44 5.99
> v4.11 a351e9b 131 17.02 5.89
>
> v4.13 569dbb8 174 14.08 0.00
> v4.13 569dbb8 261 8.41 0.00
>
> v4.15+revert d8a5b80 19 23.86 1.41
> v4.15+revert d8a5b80 189 18.69 1.39
>
As the antenna selection code changes affected your first bisection, do you have
one of those HP laptops with only one antenna and the incorrect coding in the
FUSE? If so, please make sure that you still have the same signal strength for
good and bad cases. I have tried to keep the driver and the btcoex code in sync,
but there may be some combinations of antenna configuration and FUSE contents
that cause the code to fail.
Larry
On Tue, Apr 3, 2018 at 7:28 PM, Larry Finger <[email protected]> wrote:
(...)
> As the antenna selection code changes affected your first bisection, do you
> have one of those HP laptops with only one antenna and the incorrect coding
> in the FUSE?
Yes, that is why I've been passing ant_sel=1 during my tests -- this
was needed to achieve a good performance in the past, before this
regression. I've also opened the laptop chassis and confirmed the
antenna cable is plugged to the connector labeled with "1" on the
card.
> If so, please make sure that you still have the same signal
> strength for good and bad cases. I have tried to keep the driver and the
> btcoex code in sync, but there may be some combinations of antenna
> configuration and FUSE contents that cause the code to fail.
>
What is the recommended way to monitor the signal strength?
Thanks for such a quick reply,
--
João Paulo Rechi Vita
http://about.me/jprvita
On 04/03/2018 09:37 PM, João Paulo Rechi Vita wrote:
> On Tue, Apr 3, 2018 at 7:28 PM, Larry Finger <[email protected]> wrote:
>
> (...)
>
>> As the antenna selection code changes affected your first bisection, do you
>> have one of those HP laptops with only one antenna and the incorrect coding
>> in the FUSE?
>
> Yes, that is why I've been passing ant_sel=1 during my tests -- this
> was needed to achieve a good performance in the past, before this
> regression. I've also opened the laptop chassis and confirmed the
> antenna cable is plugged to the connector labeled with "1" on the
> card.
>
>> If so, please make sure that you still have the same signal
>> strength for good and bad cases. I have tried to keep the driver and the
>> btcoex code in sync, but there may be some combinations of antenna
>> configuration and FUSE contents that cause the code to fail.
>>
>
> What is the recommended way to monitor the signal strength?
The btcoex code is developed for multiple platforms by a different group than
the Linux driver. I think they made a change that caused ant_sel to switch from
1 to 2. At least numerous comments at github.com/lwfinger/rtlwifi_new claimed
they needed to make that change.
Mhy recommended method is to verify the wifi device name with "iw dev". Then
using that device
sudo iw dev <dev_name> scan | egrep "SSID|signal"
Larry
On Tue, Apr 3, 2018 at 6:51 PM, João Paulo Rechi Vita <[email protected]> wrote:
>
> This are the results (testing with speedtest.net) I got at some key points:
>
> Version Commit Ping Down Up
>
> v4.11 a351e9b 12 25.44 5.99
> v4.11 a351e9b 131 17.02 5.89
>
> v4.13 569dbb8 174 14.08 0.00
> v4.13 569dbb8 261 8.41 0.00
>
> v4.15+revert d8a5b80 19 23.86 1.41
> v4.15+revert d8a5b80 189 18.69 1.39
>
I recommend doing throughput testing in a closed system using iperf.
speedtest.net is potentially useful for testing your ISP's bandwidth
at some particular point in time, but little else as it exposes you to
too many variables. I wouldn't take those numbers to mean much and the
inconclusive results you're getting could be explained by external
network loading and having little to do with your bisect effort. I can
get that spread in numbers from speedtest.net without making any
changes other than the time of day I do the test.
Here's how to do it. Install iperf2 (you could use iperf3, personal
choice) on two machines, one being your device under test (DUT). Setup
a network configuration that looks similar to this:
server <==hardwire==> AP <--wireless link--> DUT
Be sure your hardwire is more bandwidth than your wireless link is
capable of, or set it up where the server is the AP. What you're
looking for here is environmental consistency, not maximum throughput
numbers.
On the computer hardwired to the network, start the server, we'll
assume it has an ip of 192.168.33.18:
iperf -s
On your DUT:
iperf -c 192.168.33.18
That's the most basic setup, check the man page for more options.
You will get best results if you can exclude other computers from your
test network and other wireless devices from your airspace.
- Steve
--
Steve deRosier
Cal-Sierra Consulting LLC
https://www.cal-sierra.com/
On Tue, Apr 3, 2018 at 7:51 PM, Larry Finger <[email protected]> wrote:
> On 04/03/2018 09:37 PM, João Paulo Rechi Vita wrote:
>>
>> On Tue, Apr 3, 2018 at 7:28 PM, Larry Finger <[email protected]>
>> wrote:
>>
>> (...)
>>
>>> As the antenna selection code changes affected your first bisection, do
>>> you
>>> have one of those HP laptops with only one antenna and the incorrect
>>> coding
>>> in the FUSE?
>>
>>
>> Yes, that is why I've been passing ant_sel=1 during my tests -- this
>> was needed to achieve a good performance in the past, before this
>> regression. I've also opened the laptop chassis and confirmed the
>> antenna cable is plugged to the connector labeled with "1" on the
>> card.
>>
>>> If so, please make sure that you still have the same signal
>>> strength for good and bad cases. I have tried to keep the driver and the
>>> btcoex code in sync, but there may be some combinations of antenna
>>> configuration and FUSE contents that cause the code to fail.
>>>
>>
>> What is the recommended way to monitor the signal strength?
>
>
> The btcoex code is developed for multiple platforms by a different group
> than the Linux driver. I think they made a change that caused ant_sel to
> switch from 1 to 2. At least numerous comments at
> github.com/lwfinger/rtlwifi_new claimed they needed to make that change.
>
> Mhy recommended method is to verify the wifi device name with "iw dev". Then
> using that device
>
> sudo iw dev <dev_name> scan | egrep "SSID|signal"
>
I have confirmed that the performance regression is indeed tied to
signal strength: on the good cases signal was between -16 and -8 dBm,
whereas in bad cases signal was always between -50 to - 40 dBm. I've
also switched to testing bandwidth in controlled LAN environment using
iperf3, as suggested by Steve deRosier, with the DUT being the only
machine connected to the 2.4 GHz radio and the machine running the
iperf3 server connected via ethernet.
Using those two tests (iperf3 and signal strength) I've dug deeper
into the culprit I had found previously, commit 7937f02d1953,
reverting it partially and testing the resulting driver, to isolate
which change was causing the problem. Besides "hooking up external
functions for newer ICs", as described by the commit message, that
commit also added code to decided whether ex_btc8723b1ant_*() or
ex_btc8723b2ant_*() functions should be used in halbtcoutsrc.c,
depending on the value of board_info.btdm_ant_num, whereas before that
commit ex_btc8723b2ant_*() were always used. Reverting to always using
ex_btc8723b2ant_*() functions fixes the regression on v4.15.
I've also tried to bisect between v4.15..v4.16 to find what else was
causing problems there, as the changes mentioned above on top of v4.16
did not solve the problem. The bisect pointed to "874e837d67d0
rtlwifi: fill FW version and subversion", only but reverting it plus
the changes mentioned above also didn't yield good results. That's
when I decided to get a bit creative: starting on v4.16 I first
applied the changes to have ex_btc8723b2ant_*() always being used, as
mentioned above, then reverted every commit between v4.15..v4.16
affecting drivers/net/wireless/realtek/rtlwifi/, and verified the
resulting kernel had a good performance. Then I started trimming down
the history and testing along the way, to reduce to the minimum set of
changes that had to be reverted in order to restore the good
performance. In addition to the ex_btc8723b2ant_*() changes and
reverting "874e837d67d0 rtlwifi: fill FW version and subversion", I've
also had to remove the following lines from
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c, which
were introduced by "40d9dd4f1c5d rtlwifi: btcoex: Remove global
variables from btcoex", in order to restore the upload performance and
signal strength.
/* set default antenna position to main port */
btcoexist->board_info.btdm_ant_pos = BTC_ANTENNA_AT_MAIN_PORT;
These are the results I've got on v4.16 (similarly on
wireless-drivers-next-for-davem-2018-03-29 or v4.15):
$ sudo iw dev wlp2s0 scan | grep -B3 JJ | grep signal
signal: -42.00 dBm
$ iperf3 -c 192.168.1.254
Connecting to host 192.168.1.254, port 5201
[ 4] local 192.168.1.253 port 39678 connected to 192.168.1.254 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 735 KBytes 6.02 Mbits/sec 1 1.41 KBytes
[ 4] 1.00-2.00 sec 274 KBytes 2.25 Mbits/sec 1 1.41 KBytes
[ 4] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 4] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 4] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec 1 28.3 KBytes
[ 4] 5.00-6.00 sec 423 KBytes 3.47 Mbits/sec 3 41.0 KBytes
[ 4] 6.00-7.00 sec 840 KBytes 6.88 Mbits/sec 0 58.0 KBytes
[ 4] 7.00-8.00 sec 830 KBytes 6.79 Mbits/sec 1 1.41 KBytes
[ 4] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 4] 9.00-10.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 3.03 MBytes 2.54 Mbits/sec 7
sender
[ 4] 0.00-10.00 sec 2.88 MBytes 2.41 Mbits/sec
receiver
iperf Done.
And these are the results on v4.16 with all the changes mentioned on
the previous paragraph, and similar results were obtained when
applying the same changes on the current wireless-drivers-next master
branch (f56324baf329):
$ sudo iw dev wlp2s0 scan | grep -B3 JJ | grep signal
signal: -14.00 dBm
$ iperf3 -c 192.168.1.254
Connecting to host 192.168.1.254, port 5201
[ 4] local 192.168.1.253 port 59380 connected to 192.168.1.254 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 4.63 MBytes 38.8 Mbits/sec 0 194 KBytes
[ 4] 1.00-2.00 sec 4.58 MBytes 38.4 Mbits/sec 0 273 KBytes
[ 4] 2.00-3.00 sec 5.05 MBytes 42.3 Mbits/sec 0 332 KBytes
[ 4] 3.00-4.00 sec 4.98 MBytes 41.8 Mbits/sec 0 393 KBytes
[ 4] 4.00-5.00 sec 4.76 MBytes 39.9 Mbits/sec 0 434 KBytes
[ 4] 5.00-6.00 sec 4.85 MBytes 40.7 Mbits/sec 0 434 KBytes
[ 4] 6.00-7.00 sec 3.96 MBytes 33.2 Mbits/sec 0 464 KBytes
[ 4] 7.00-8.00 sec 4.74 MBytes 39.8 Mbits/sec 0 481 KBytes
[ 4] 8.00-9.00 sec 4.22 MBytes 35.4 Mbits/sec 0 508 KBytes
[ 4] 9.00-10.00 sec 4.09 MBytes 34.3 Mbits/sec 0 564 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 45.9 MBytes 38.5 Mbits/sec 0
sender
[ 4] 0.00-10.00 sec 45.0 MBytes 37.7 Mbits/sec
receiver
iperf Done.
I'll send an RFC patchset with the changes that I mentioned above.
Please advise whether those changes themselves should be merged, or if
you suggest a different approach.
This partially reverts commit 40d9dd4f1c5dcd0d4a2a1f0efcd225c9c4b36d6f,
which does not only remove global variables from btcoex, as described on
its commit message, but also does a few other things -- in particular,
setting the default antenna position to BTC_ANTENNA_AT_MAIN_PORT.
This drastically affects the upload performance and signal strenght on
the HP 240 G4 laptop, as shown by the results bellow:
Without this change:
$ sudo iw dev wlp2s0 scan | grep -B3 JJ | grep signal
signal: -42.00 dBm
$ iperf3 -c 192.168.1.254
Connecting to host 192.168.1.254, port 5201
[ 4] local 192.168.1.253 port 39678 connected to 192.168.1.254 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 735 KBytes 6.02 Mbits/sec 1 1.41 KBytes
[ 4] 1.00-2.00 sec 274 KBytes 2.25 Mbits/sec 1 1.41 KBytes
[ 4] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 4] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 4] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec 1 28.3 KBytes
[ 4] 5.00-6.00 sec 423 KBytes 3.47 Mbits/sec 3 41.0 KBytes
[ 4] 6.00-7.00 sec 840 KBytes 6.88 Mbits/sec 0 58.0 KBytes
[ 4] 7.00-8.00 sec 830 KBytes 6.79 Mbits/sec 1 1.41 KBytes
[ 4] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 4] 9.00-10.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 3.03 MBytes 2.54 Mbits/sec 7 sender
[ 4] 0.00-10.00 sec 2.88 MBytes 2.41 Mbits/sec receiver
iperf Done.
With this change:
$ sudo iw dev wlp2s0 scan | grep -B3 JJ | grep signal
signal: -14.00 dBm
$ iperf3 -c 192.168.1.254
Connecting to host 192.168.1.254, port 5201
[ 4] local 192.168.1.253 port 59380 connected to 192.168.1.254 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 4.63 MBytes 38.8 Mbits/sec 0 194 KBytes
[ 4] 1.00-2.00 sec 4.58 MBytes 38.4 Mbits/sec 0 273 KBytes
[ 4] 2.00-3.00 sec 5.05 MBytes 42.3 Mbits/sec 0 332 KBytes
[ 4] 3.00-4.00 sec 4.98 MBytes 41.8 Mbits/sec 0 393 KBytes
[ 4] 4.00-5.00 sec 4.76 MBytes 39.9 Mbits/sec 0 434 KBytes
[ 4] 5.00-6.00 sec 4.85 MBytes 40.7 Mbits/sec 0 434 KBytes
[ 4] 6.00-7.00 sec 3.96 MBytes 33.2 Mbits/sec 0 464 KBytes
[ 4] 7.00-8.00 sec 4.74 MBytes 39.8 Mbits/sec 0 481 KBytes
[ 4] 8.00-9.00 sec 4.22 MBytes 35.4 Mbits/sec 0 508 KBytes
[ 4] 9.00-10.00 sec 4.09 MBytes 34.3 Mbits/sec 0 564 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 45.9 MBytes 38.5 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 45.0 MBytes 37.7 Mbits/sec receiver
iperf Done.
Signed-off-by: João Paulo Rechi Vita <[email protected]>
---
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
index b026e80940a4..86182b917c92 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
@@ -1388,9 +1388,6 @@ bool exhalbtc_bind_bt_coex_withadapter(void *adapter)
ant_num = rtl_get_hwpg_ant_num(rtlpriv);
exhalbtc_set_ant_num(rtlpriv, BT_COEX_ANT_TYPE_PG, ant_num);
- /* set default antenna position to main port */
- btcoexist->board_info.btdm_ant_pos = BTC_ANTENNA_AT_MAIN_PORT;
-
single_ant_path = rtl_get_hwpg_single_ant_path(rtlpriv);
exhalbtc_set_single_ant_path(btcoexist, single_ant_path);
--
2.17.0
This partially reverts commit 7937f02d1953952a6eaf626b175ea9db5541e699,
which not only hooked external functions for newer ICs, as described in
its commit message, but also changed the behavior for RTL8723BE
depending on the value of board_info.btdm_ant_num.
When board_info.btdm_ant_num == 1, 7937f02d19 changes the codepath to
use a whole different set of functions ex_btc8723b1ant_*, instead of the
ex_btc8723b2ant_* that were used before it.
This drastically affects the upload performance and signal strenght on
the HP 240 G4 laptop, as shown by the results bellow:
Without this change:
$ sudo iw dev wlp2s0 scan | grep -B3 JJ | grep signal
signal: -42.00 dBm
$ iperf3 -c 192.168.1.254
Connecting to host 192.168.1.254, port 5201
[ 4] local 192.168.1.253 port 39678 connected to 192.168.1.254 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 735 KBytes 6.02 Mbits/sec 1 1.41 KBytes
[ 4] 1.00-2.00 sec 274 KBytes 2.25 Mbits/sec 1 1.41 KBytes
[ 4] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 4] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 4] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec 1 28.3 KBytes
[ 4] 5.00-6.00 sec 423 KBytes 3.47 Mbits/sec 3 41.0 KBytes
[ 4] 6.00-7.00 sec 840 KBytes 6.88 Mbits/sec 0 58.0 KBytes
[ 4] 7.00-8.00 sec 830 KBytes 6.79 Mbits/sec 1 1.41 KBytes
[ 4] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 4] 9.00-10.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 3.03 MBytes 2.54 Mbits/sec 7 sender
[ 4] 0.00-10.00 sec 2.88 MBytes 2.41 Mbits/sec receiver
iperf Done.
With this change:
$ sudo iw dev wlp2s0 scan | grep -B3 JJ | grep signal
signal: -14.00 dBm
$ iperf3 -c 192.168.1.254
Connecting to host 192.168.1.254, port 5201
[ 4] local 192.168.1.253 port 59380 connected to 192.168.1.254 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 4.63 MBytes 38.8 Mbits/sec 0 194 KBytes
[ 4] 1.00-2.00 sec 4.58 MBytes 38.4 Mbits/sec 0 273 KBytes
[ 4] 2.00-3.00 sec 5.05 MBytes 42.3 Mbits/sec 0 332 KBytes
[ 4] 3.00-4.00 sec 4.98 MBytes 41.8 Mbits/sec 0 393 KBytes
[ 4] 4.00-5.00 sec 4.76 MBytes 39.9 Mbits/sec 0 434 KBytes
[ 4] 5.00-6.00 sec 4.85 MBytes 40.7 Mbits/sec 0 434 KBytes
[ 4] 6.00-7.00 sec 3.96 MBytes 33.2 Mbits/sec 0 464 KBytes
[ 4] 7.00-8.00 sec 4.74 MBytes 39.8 Mbits/sec 0 481 KBytes
[ 4] 8.00-9.00 sec 4.22 MBytes 35.4 Mbits/sec 0 508 KBytes
[ 4] 9.00-10.00 sec 4.09 MBytes 34.3 Mbits/sec 0 564 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 45.9 MBytes 38.5 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 45.0 MBytes 37.7 Mbits/sec receiver
iperf Done.
Signed-off-by: João Paulo Rechi Vita <[email protected]>
---
.../realtek/rtlwifi/btcoexist/halbtcoutsrc.c | 62 ++++---------------
1 file changed, 12 insertions(+), 50 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
index 86182b917c92..a862b5efdf55 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
@@ -1452,10 +1452,7 @@ void exhalbtc_init_hw_config(struct btc_coexist *btcoexist, bool wifi_only)
else if (btcoexist->board_info.btdm_ant_num == 1)
ex_btc8821a1ant_init_hwconfig(btcoexist, wifi_only);
} else if (IS_HARDWARE_TYPE_8723B(btcoexist->adapter)) {
- if (btcoexist->board_info.btdm_ant_num == 2)
- ex_btc8723b2ant_init_hwconfig(btcoexist);
- else if (btcoexist->board_info.btdm_ant_num == 1)
- ex_btc8723b1ant_init_hwconfig(btcoexist, wifi_only);
+ ex_btc8723b2ant_init_hwconfig(btcoexist);
} else if (IS_HARDWARE_TYPE_8723A(btcoexist->adapter)) {
/* 8723A has no this function */
} else if (IS_HARDWARE_TYPE_8192E(btcoexist->adapter)) {
@@ -1481,10 +1478,7 @@ void exhalbtc_init_coex_dm(struct btc_coexist *btcoexist)
else if (btcoexist->board_info.btdm_ant_num == 1)
ex_btc8821a1ant_init_coex_dm(btcoexist);
} else if (IS_HARDWARE_TYPE_8723B(btcoexist->adapter)) {
- if (btcoexist->board_info.btdm_ant_num == 2)
- ex_btc8723b2ant_init_coex_dm(btcoexist);
- else if (btcoexist->board_info.btdm_ant_num == 1)
- ex_btc8723b1ant_init_coex_dm(btcoexist);
+ ex_btc8723b2ant_init_coex_dm(btcoexist);
} else if (IS_HARDWARE_TYPE_8192E(btcoexist->adapter)) {
if (btcoexist->board_info.btdm_ant_num == 2)
ex_btc8192e2ant_init_coex_dm(btcoexist);
@@ -1516,10 +1510,7 @@ void exhalbtc_ips_notify(struct btc_coexist *btcoexist, u8 type)
else if (btcoexist->board_info.btdm_ant_num == 1)
ex_btc8821a1ant_ips_notify(btcoexist, ips_type);
} else if (IS_HARDWARE_TYPE_8723B(btcoexist->adapter)) {
- if (btcoexist->board_info.btdm_ant_num == 2)
- ex_btc8723b2ant_ips_notify(btcoexist, ips_type);
- else if (btcoexist->board_info.btdm_ant_num == 1)
- ex_btc8723b1ant_ips_notify(btcoexist, ips_type);
+ ex_btc8723b2ant_ips_notify(btcoexist, ips_type);
} else if (IS_HARDWARE_TYPE_8192E(btcoexist->adapter)) {
if (btcoexist->board_info.btdm_ant_num == 2)
ex_btc8192e2ant_ips_notify(btcoexist, ips_type);
@@ -1549,10 +1540,7 @@ void exhalbtc_lps_notify(struct btc_coexist *btcoexist, u8 type)
else if (btcoexist->board_info.btdm_ant_num == 1)
ex_btc8821a1ant_lps_notify(btcoexist, lps_type);
} else if (IS_HARDWARE_TYPE_8723B(btcoexist->adapter)) {
- if (btcoexist->board_info.btdm_ant_num == 2)
- ex_btc8723b2ant_lps_notify(btcoexist, lps_type);
- else if (btcoexist->board_info.btdm_ant_num == 1)
- ex_btc8723b1ant_lps_notify(btcoexist, lps_type);
+ ex_btc8723b2ant_lps_notify(btcoexist, lps_type);
} else if (IS_HARDWARE_TYPE_8192E(btcoexist->adapter)) {
if (btcoexist->board_info.btdm_ant_num == 2)
ex_btc8192e2ant_lps_notify(btcoexist, lps_type);
@@ -1582,10 +1570,7 @@ void exhalbtc_scan_notify(struct btc_coexist *btcoexist, u8 type)
else if (btcoexist->board_info.btdm_ant_num == 1)
ex_btc8821a1ant_scan_notify(btcoexist, scan_type);
} else if (IS_HARDWARE_TYPE_8723B(btcoexist->adapter)) {
- if (btcoexist->board_info.btdm_ant_num == 2)
- ex_btc8723b2ant_scan_notify(btcoexist, scan_type);
- else if (btcoexist->board_info.btdm_ant_num == 1)
- ex_btc8723b1ant_scan_notify(btcoexist, scan_type);
+ ex_btc8723b2ant_scan_notify(btcoexist, scan_type);
} else if (IS_HARDWARE_TYPE_8192E(btcoexist->adapter)) {
if (btcoexist->board_info.btdm_ant_num == 2)
ex_btc8192e2ant_scan_notify(btcoexist, scan_type);
@@ -1630,10 +1615,7 @@ void exhalbtc_connect_notify(struct btc_coexist *btcoexist, u8 action)
else if (btcoexist->board_info.btdm_ant_num == 1)
ex_btc8821a1ant_connect_notify(btcoexist, asso_type);
} else if (IS_HARDWARE_TYPE_8723B(btcoexist->adapter)) {
- if (btcoexist->board_info.btdm_ant_num == 2)
- ex_btc8723b2ant_connect_notify(btcoexist, asso_type);
- else if (btcoexist->board_info.btdm_ant_num == 1)
- ex_btc8723b1ant_connect_notify(btcoexist, asso_type);
+ ex_btc8723b2ant_connect_notify(btcoexist, asso_type);
} else if (IS_HARDWARE_TYPE_8192E(btcoexist->adapter)) {
if (btcoexist->board_info.btdm_ant_num == 2)
ex_btc8192e2ant_connect_notify(btcoexist, asso_type);
@@ -1666,10 +1648,7 @@ void exhalbtc_mediastatus_notify(struct btc_coexist *btcoexist,
else if (btcoexist->board_info.btdm_ant_num == 1)
ex_btc8821a1ant_media_status_notify(btcoexist, status);
} else if (IS_HARDWARE_TYPE_8723B(btcoexist->adapter)) {
- if (btcoexist->board_info.btdm_ant_num == 2)
- ex_btc8723b2ant_media_status_notify(btcoexist, status);
- else if (btcoexist->board_info.btdm_ant_num == 1)
- ex_btc8723b1ant_media_status_notify(btcoexist, status);
+ ex_btc8723b2ant_media_status_notify(btcoexist, status);
} else if (IS_HARDWARE_TYPE_8192E(btcoexist->adapter)) {
if (btcoexist->board_info.btdm_ant_num == 2)
ex_btc8192e2ant_media_status_notify(btcoexist, status);
@@ -1709,12 +1688,8 @@ void exhalbtc_special_packet_notify(struct btc_coexist *btcoexist, u8 pkt_type)
ex_btc8821a1ant_special_packet_notify(btcoexist,
packet_type);
} else if (IS_HARDWARE_TYPE_8723B(btcoexist->adapter)) {
- if (btcoexist->board_info.btdm_ant_num == 2)
- ex_btc8723b2ant_special_packet_notify(btcoexist,
- packet_type);
- else if (btcoexist->board_info.btdm_ant_num == 1)
- ex_btc8723b1ant_special_packet_notify(btcoexist,
- packet_type);
+ ex_btc8723b2ant_special_packet_notify(btcoexist,
+ packet_type);
} else if (IS_HARDWARE_TYPE_8192E(btcoexist->adapter)) {
if (btcoexist->board_info.btdm_ant_num == 2)
ex_btc8192e2ant_special_packet_notify(btcoexist,
@@ -1741,12 +1716,7 @@ void exhalbtc_bt_info_notify(struct btc_coexist *btcoexist,
ex_btc8821a1ant_bt_info_notify(btcoexist, tmp_buf,
length);
} else if (IS_HARDWARE_TYPE_8723B(btcoexist->adapter)) {
- if (btcoexist->board_info.btdm_ant_num == 2)
- ex_btc8723b2ant_bt_info_notify(btcoexist, tmp_buf,
- length);
- else if (btcoexist->board_info.btdm_ant_num == 1)
- ex_btc8723b1ant_bt_info_notify(btcoexist, tmp_buf,
- length);
+ ex_btc8723b2ant_bt_info_notify(btcoexist, tmp_buf, length);
} else if (IS_HARDWARE_TYPE_8192E(btcoexist->adapter)) {
if (btcoexist->board_info.btdm_ant_num == 2)
ex_btc8192e2ant_bt_info_notify(btcoexist, tmp_buf,
@@ -1763,8 +1733,6 @@ void exhalbtc_rf_status_notify(struct btc_coexist *btcoexist, u8 type)
if (IS_HARDWARE_TYPE_8821(btcoexist->adapter)) {
} else if (IS_HARDWARE_TYPE_8723B(btcoexist->adapter)) {
- if (btcoexist->board_info.btdm_ant_num == 1)
- ex_btc8723b1ant_rf_status_notify(btcoexist, type);
} else if (IS_HARDWARE_TYPE_8192E(btcoexist->adapter)) {
}
}
@@ -1804,10 +1772,7 @@ void exhalbtc_halt_notify(struct btc_coexist *btcoexist)
else if (btcoexist->board_info.btdm_ant_num == 1)
ex_btc8821a1ant_halt_notify(btcoexist);
} else if (IS_HARDWARE_TYPE_8723B(btcoexist->adapter)) {
- if (btcoexist->board_info.btdm_ant_num == 2)
- ex_btc8723b2ant_halt_notify(btcoexist);
- else if (btcoexist->board_info.btdm_ant_num == 1)
- ex_btc8723b1ant_halt_notify(btcoexist);
+ ex_btc8723b2ant_halt_notify(btcoexist);
} else if (IS_HARDWARE_TYPE_8192E(btcoexist->adapter)) {
if (btcoexist->board_info.btdm_ant_num == 2)
ex_btc8192e2ant_halt_notify(btcoexist);
@@ -1880,10 +1845,7 @@ void exhalbtc_periodical(struct btc_coexist *btcoexist)
if (!halbtc_under_ips(btcoexist))
ex_btc8821a1ant_periodical(btcoexist);
} else if (IS_HARDWARE_TYPE_8723B(btcoexist->adapter)) {
- if (btcoexist->board_info.btdm_ant_num == 2)
- ex_btc8723b2ant_periodical(btcoexist);
- else if (btcoexist->board_info.btdm_ant_num == 1)
- ex_btc8723b1ant_periodical(btcoexist);
+ ex_btc8723b2ant_periodical(btcoexist);
} else if (IS_HARDWARE_TYPE_8192E(btcoexist->adapter)) {
if (btcoexist->board_info.btdm_ant_num == 2)
ex_btc8192e2ant_periodical(btcoexist);
--
2.17.0
This reverts commit 874e837d67d0db179c9771f38fd21df07c703e93.
This drastically affects the upload performance and signal strenght on
the HP 240 G4 laptop, as shown by the results bellow:
Without this change:
$ sudo iw dev wlp2s0 scan | grep -B3 JJ | grep signal
signal: -42.00 dBm
$ iperf3 -c 192.168.1.254
Connecting to host 192.168.1.254, port 5201
[ 4] local 192.168.1.253 port 39678 connected to 192.168.1.254 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 735 KBytes 6.02 Mbits/sec 1 1.41 KBytes
[ 4] 1.00-2.00 sec 274 KBytes 2.25 Mbits/sec 1 1.41 KBytes
[ 4] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 4] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 4] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec 1 28.3 KBytes
[ 4] 5.00-6.00 sec 423 KBytes 3.47 Mbits/sec 3 41.0 KBytes
[ 4] 6.00-7.00 sec 840 KBytes 6.88 Mbits/sec 0 58.0 KBytes
[ 4] 7.00-8.00 sec 830 KBytes 6.79 Mbits/sec 1 1.41 KBytes
[ 4] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 4] 9.00-10.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 3.03 MBytes 2.54 Mbits/sec 7 sender
[ 4] 0.00-10.00 sec 2.88 MBytes 2.41 Mbits/sec receiver
iperf Done.
With this change:
$ sudo iw dev wlp2s0 scan | grep -B3 JJ | grep signal
signal: -14.00 dBm
$ iperf3 -c 192.168.1.254
Connecting to host 192.168.1.254, port 5201
[ 4] local 192.168.1.253 port 59380 connected to 192.168.1.254 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 4.63 MBytes 38.8 Mbits/sec 0 194 KBytes
[ 4] 1.00-2.00 sec 4.58 MBytes 38.4 Mbits/sec 0 273 KBytes
[ 4] 2.00-3.00 sec 5.05 MBytes 42.3 Mbits/sec 0 332 KBytes
[ 4] 3.00-4.00 sec 4.98 MBytes 41.8 Mbits/sec 0 393 KBytes
[ 4] 4.00-5.00 sec 4.76 MBytes 39.9 Mbits/sec 0 434 KBytes
[ 4] 5.00-6.00 sec 4.85 MBytes 40.7 Mbits/sec 0 434 KBytes
[ 4] 6.00-7.00 sec 3.96 MBytes 33.2 Mbits/sec 0 464 KBytes
[ 4] 7.00-8.00 sec 4.74 MBytes 39.8 Mbits/sec 0 481 KBytes
[ 4] 8.00-9.00 sec 4.22 MBytes 35.4 Mbits/sec 0 508 KBytes
[ 4] 9.00-10.00 sec 4.09 MBytes 34.3 Mbits/sec 0 564 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 45.9 MBytes 38.5 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 45.0 MBytes 37.7 Mbits/sec receiver
iperf Done.
Signed-off-by: João Paulo Rechi Vita <[email protected]>
---
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/fw.c | 2 --
drivers/net/wireless/realtek/rtlwifi/rtl8723com/fw_common.c | 2 --
2 files changed, 4 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/fw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/fw.c
index 63874512598b..a2eca669873b 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/fw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/fw.c
@@ -141,8 +141,6 @@ int rtl88e_download_fw(struct ieee80211_hw *hw,
return 1;
pfwheader = (struct rtlwifi_firmware_header *)rtlhal->pfirmware;
- rtlhal->fw_version = le16_to_cpu(pfwheader->version);
- rtlhal->fw_subversion = pfwheader->subversion;
pfwdata = rtlhal->pfirmware;
fwsize = rtlhal->fwsize;
RT_TRACE(rtlpriv, COMP_FW, DBG_DMESG,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723com/fw_common.c b/drivers/net/wireless/realtek/rtlwifi/rtl8723com/fw_common.c
index 521039c5d4ce..0d1ebc861720 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723com/fw_common.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723com/fw_common.c
@@ -200,8 +200,6 @@ int rtl8723_download_fw(struct ieee80211_hw *hw,
return 1;
pfwheader = (struct rtlwifi_firmware_header *)rtlhal->pfirmware;
- rtlhal->fw_version = le16_to_cpu(pfwheader->version);
- rtlhal->fw_subversion = pfwheader->subversion;
pfwdata = rtlhal->pfirmware;
fwsize = rtlhal->fwsize;
--
2.17.0
> -----Original Message-----
> From: João Paulo Rechi Vita [mailto:[email protected]]
> Sent: Wednesday, May 02, 2018 6:41 AM
> To: Larry Finger
> Cc: Steve deRosier; 莊彥宣; Pkshih; Birming Chiu; Shaofu; Steven Ting; Chaoming_Li; Kalle Valo;
> linux-wireless; Network Development; LKML; Daniel Drake; João Paulo Rechi Vita; [email protected]
> Subject: Re: RTL8723BE performance regression
>
> On Tue, Apr 3, 2018 at 7:51 PM, Larry Finger <[email protected]> wrote:
> > On 04/03/2018 09:37 PM, João Paulo Rechi Vita wrote:
> >>
> >> On Tue, Apr 3, 2018 at 7:28 PM, Larry Finger <[email protected]>
> >> wrote:
> >>
> >> (...)
> >>
> >>> As the antenna selection code changes affected your first bisection, do
> >>> you
> >>> have one of those HP laptops with only one antenna and the incorrect
> >>> coding
> >>> in the FUSE?
> >>
> >>
> >> Yes, that is why I've been passing ant_sel=1 during my tests -- this
> >> was needed to achieve a good performance in the past, before this
> >> regression. I've also opened the laptop chassis and confirmed the
> >> antenna cable is plugged to the connector labeled with "1" on the
> >> card.
> >>
> >>> If so, please make sure that you still have the same signal
> >>> strength for good and bad cases. I have tried to keep the driver and the
> >>> btcoex code in sync, but there may be some combinations of antenna
> >>> configuration and FUSE contents that cause the code to fail.
> >>>
> >>
> >> What is the recommended way to monitor the signal strength?
> >
> >
> > The btcoex code is developed for multiple platforms by a different group
> > than the Linux driver. I think they made a change that caused ant_sel to
> > switch from 1 to 2. At least numerous comments at
> > github.com/lwfinger/rtlwifi_new claimed they needed to make that change.
> >
> > Mhy recommended method is to verify the wifi device name with "iw dev". Then
> > using that device
> >
> > sudo iw dev <dev_name> scan | egrep "SSID|signal"
> >
>
> I have confirmed that the performance regression is indeed tied to
> signal strength: on the good cases signal was between -16 and -8 dBm,
> whereas in bad cases signal was always between -50 to - 40 dBm. I've
> also switched to testing bandwidth in controlled LAN environment using
> iperf3, as suggested by Steve deRosier, with the DUT being the only
> machine connected to the 2.4 GHz radio and the machine running the
> iperf3 server connected via ethernet.
>
We have new experimental results in commit af8a41cccf8f46 ("rtlwifi: cleanup
8723be ant_sel definition"). You can use the above commit and do the same
experiments (with ant_sel=0, 1 and 2) in your side, and then share your results.
Since performance is tied to signal strength, you can only share signal strength.
Regards
PK
On Wed, 2018-05-02 at 05:44 +0000, Pkshih wrote:
>
> > -----Original Message-----
> > From: João Paulo Rechi Vita [mailto:[email protected]]
> > Sent: Wednesday, May 02, 2018 6:41 AM
> > To: Larry Finger
> > Cc: Steve deRosier; 莊彥宣; Pkshih; Birming Chiu; Shaofu; Steven Ting; Chaoming_Li; Kalle Valo;
> > linux-wireless; Network Development; LKML; Daniel Drake; João Paulo Rechi Vita; [email protected]
> om
> > Subject: Re: RTL8723BE performance regression
> >
> > On Tue, Apr 3, 2018 at 7:51 PM, Larry Finger <[email protected]> wrote:
> > > On 04/03/2018 09:37 PM, João Paulo Rechi Vita wrote:
> > >>
> > >> On Tue, Apr 3, 2018 at 7:28 PM, Larry Finger <[email protected]>
> > >> wrote:
> > >>
> > >> (...)
> > >>
> > >>> As the antenna selection code changes affected your first bisection, do
> > >>> you
> > >>> have one of those HP laptops with only one antenna and the incorrect
> > >>> coding
> > >>> in the FUSE?
> > >>
> > >>
> > >> Yes, that is why I've been passing ant_sel=1 during my tests -- this
> > >> was needed to achieve a good performance in the past, before this
> > >> regression. I've also opened the laptop chassis and confirmed the
> > >> antenna cable is plugged to the connector labeled with "1" on the
> > >> card.
> > >>
> > >>> If so, please make sure that you still have the same signal
> > >>> strength for good and bad cases. I have tried to keep the driver and the
> > >>> btcoex code in sync, but there may be some combinations of antenna
> > >>> configuration and FUSE contents that cause the code to fail.
> > >>>
> > >>
> > >> What is the recommended way to monitor the signal strength?
> > >
> > >
> > > The btcoex code is developed for multiple platforms by a different group
> > > than the Linux driver. I think they made a change that caused ant_sel to
> > > switch from 1 to 2. At least numerous comments at
> > > github.com/lwfinger/rtlwifi_new claimed they needed to make that change.
> > >
> > > Mhy recommended method is to verify the wifi device name with "iw dev". Then
> > > using that device
> > >
> > > sudo iw dev <dev_name> scan | egrep "SSID|signal"
> > >
> >
> > I have confirmed that the performance regression is indeed tied to
> > signal strength: on the good cases signal was between -16 and -8 dBm,
> > whereas in bad cases signal was always between -50 to - 40 dBm. I've
> > also switched to testing bandwidth in controlled LAN environment using
> > iperf3, as suggested by Steve deRosier, with the DUT being the only
> > machine connected to the 2.4 GHz radio and the machine running the
> > iperf3 server connected via ethernet.
> >
>
> We have new experimental results in commit af8a41cccf8f46 ("rtlwifi: cleanup
> 8723be ant_sel definition"). You can use the above commit and do the same
> experiments (with ant_sel=0, 1 and 2) in your side, and then share your results.
> Since performance is tied to signal strength, you can only share signal strength.
>
Please pay attention to cold reboot once ant_sel is changed.
On Tue, May 1, 2018 at 10:58 PM, Pkshih <[email protected]> wrote:
> On Wed, 2018-05-02 at 05:44 +0000, Pkshih wrote:
>>
>> > -----Original Message-----
>> > From: João Paulo Rechi Vita [mailto:[email protected]]
>> > Sent: Wednesday, May 02, 2018 6:41 AM
>> > To: Larry Finger
>> > Cc: Steve deRosier; 莊彥宣; Pkshih; Birming Chiu; Shaofu; Steven Ting; Chaoming_Li; Kalle Valo;
>> > linux-wireless; Network Development; LKML; Daniel Drake; João Paulo Rechi Vita; [email protected]
>> om
>> > Subject: Re: RTL8723BE performance regression
>> >
>> > On Tue, Apr 3, 2018 at 7:51 PM, Larry Finger <[email protected]> wrote:
>> > > On 04/03/2018 09:37 PM, João Paulo Rechi Vita wrote:
>> > >>
>> > >> On Tue, Apr 3, 2018 at 7:28 PM, Larry Finger <[email protected]>
>> > >> wrote:
>> > >>
>> > >> (...)
>> > >>
>> > >>> As the antenna selection code changes affected your first bisection, do
>> > >>> you
>> > >>> have one of those HP laptops with only one antenna and the incorrect
>> > >>> coding
>> > >>> in the FUSE?
>> > >>
>> > >>
>> > >> Yes, that is why I've been passing ant_sel=1 during my tests -- this
>> > >> was needed to achieve a good performance in the past, before this
>> > >> regression. I've also opened the laptop chassis and confirmed the
>> > >> antenna cable is plugged to the connector labeled with "1" on the
>> > >> card.
>> > >>
>> > >>> If so, please make sure that you still have the same signal
>> > >>> strength for good and bad cases. I have tried to keep the driver and the
>> > >>> btcoex code in sync, but there may be some combinations of antenna
>> > >>> configuration and FUSE contents that cause the code to fail.
>> > >>>
>> > >>
>> > >> What is the recommended way to monitor the signal strength?
>> > >
>> > >
>> > > The btcoex code is developed for multiple platforms by a different group
>> > > than the Linux driver. I think they made a change that caused ant_sel to
>> > > switch from 1 to 2. At least numerous comments at
>> > > github.com/lwfinger/rtlwifi_new claimed they needed to make that change.
>> > >
>> > > Mhy recommended method is to verify the wifi device name with "iw dev". Then
>> > > using that device
>> > >
>> > > sudo iw dev <dev_name> scan | egrep "SSID|signal"
>> > >
>> >
>> > I have confirmed that the performance regression is indeed tied to
>> > signal strength: on the good cases signal was between -16 and -8 dBm,
>> > whereas in bad cases signal was always between -50 to - 40 dBm. I've
>> > also switched to testing bandwidth in controlled LAN environment using
>> > iperf3, as suggested by Steve deRosier, with the DUT being the only
>> > machine connected to the 2.4 GHz radio and the machine running the
>> > iperf3 server connected via ethernet.
>> >
>>
>> We have new experimental results in commit af8a41cccf8f46 ("rtlwifi: cleanup
>> 8723be ant_sel definition"). You can use the above commit and do the same
>> experiments (with ant_sel=0, 1 and 2) in your side, and then share your results.
>> Since performance is tied to signal strength, you can only share signal strength.
>>
>
> Please pay attention to cold reboot once ant_sel is changed.
>
I've tested the commit mentioned above and it fixes the problem on top
of v4.16 (in addition to the latest wireless-drivers-next also been
fixed as it already contains such commit). On v4.15, we also need the
following commits before "af8a41cccf8f rtlwifi: cleanup 8723be ant_sel
definition" to have a good performance again:
874e837d67d0 rtlwifi: fill FW version and subversion
a44709bba70f rtlwifi: btcoex: Add power_on_setting routine
40d9dd4f1c5d rtlwifi: btcoex: Remove global variables from btcoex
Surprisingly, it seems forcing ant_sel=1 is not needed anymore on
these machines, as the shown by the numbers bellow (ant_sel=0 means
that actually no parameter was passed to the module). I have powered
off the machine and done a cold boot for every test. It seems
something have changed in the antenna auto-selection code since v4.11,
the latest point where I could confirm we definitely need to force
ant_sel=1. I've been trying to understand what causes this difference,
but haven't made progress on that so far, so any suggestions are
appreciated (we are trying to decide if we can confidently drop the
downstream DMI quirks for these specific machines).
w-d-n ant_sel=0: -14.00 dBm, 69.5 Mbps -> good
w-d-n ant_sel=1: -10.00 dBm, 41.1 Mbps -> good
w-d-n ant_sel=2: -44.00 dBm, 607 kbps -> bad
v4.16 ant_sel=0: -12.00 dBm, 63.0 Mbps -> good
v4.16 ant_sel=1: - 8.00 dBm, 69.0 Mbps -> good
v4.16 ant_sel=2: -50.00 dBm, 224 kbps -> bad
v4.15 ant_sel=0: - 8.00 dBm, 33.0 Mbps -> good
v4.15 ant_sel=1: -10.00 dBm, 38.1 Mbps -> good
v4.15 ant_sel=2: -48.00 dBm, 206 kbps -> bad
--
João Paulo Rechi Vita
http://about.me/jprvita
On Mon, 2018-05-07 at 14:49 -0700, João Paulo Rechi Vita wrote:
> On Tue, May 1, 2018 at 10:58 PM, Pkshih <[email protected]> wrote:
> > On Wed, 2018-05-02 at 05:44 +0000, Pkshih wrote:
> >>
> >> > -----Original Message-----
> >> > From: João Paulo Rechi Vita [mailto:[email protected]]
> >> > Sent: Wednesday, May 02, 2018 6:41 AM
> >> > To: Larry Finger
> >> > Cc: Steve deRosier; 莊彥宣; Pkshih; Birming Chiu; Shaofu; Steven Ting; Chaoming_Li; Kalle Valo;
> >> > linux-wireless; Network Development; LKML; Daniel Drake; João Paulo Rechi Vita; linux@endless
> m.c
> >> om
> >> > Subject: Re: RTL8723BE performance regression
> >> >
> >> > On Tue, Apr 3, 2018 at 7:51 PM, Larry Finger <[email protected]> wrote:
> >> > > On 04/03/2018 09:37 PM, João Paulo Rechi Vita wrote:
> >> > >>
> >> > >> On Tue, Apr 3, 2018 at 7:28 PM, Larry Finger <[email protected]>
> >> > >> wrote:
> >> > >>
> >> > >> (...)
> >> > >>
> >> > >>> As the antenna selection code changes affected your first bisection, do
> >> > >>> you
> >> > >>> have one of those HP laptops with only one antenna and the incorrect
> >> > >>> coding
> >> > >>> in the FUSE?
> >> > >>
> >> > >>
> >> > >> Yes, that is why I've been passing ant_sel=1 during my tests -- this
> >> > >> was needed to achieve a good performance in the past, before this
> >> > >> regression. I've also opened the laptop chassis and confirmed the
> >> > >> antenna cable is plugged to the connector labeled with "1" on the
> >> > >> card.
> >> > >>
> >> > >>> If so, please make sure that you still have the same signal
> >> > >>> strength for good and bad cases. I have tried to keep the driver and the
> >> > >>> btcoex code in sync, but there may be some combinations of antenna
> >> > >>> configuration and FUSE contents that cause the code to fail.
> >> > >>>
> >> > >>
> >> > >> What is the recommended way to monitor the signal strength?
> >> > >
> >> > >
> >> > > The btcoex code is developed for multiple platforms by a different group
> >> > > than the Linux driver. I think they made a change that caused ant_sel to
> >> > > switch from 1 to 2. At least numerous comments at
> >> > > github.com/lwfinger/rtlwifi_new claimed they needed to make that change.
> >> > >
> >> > > Mhy recommended method is to verify the wifi device name with "iw dev". Then
> >> > > using that device
> >> > >
> >> > > sudo iw dev <dev_name> scan | egrep "SSID|signal"
> >> > >
> >> >
> >> > I have confirmed that the performance regression is indeed tied to
> >> > signal strength: on the good cases signal was between -16 and -8 dBm,
> >> > whereas in bad cases signal was always between -50 to - 40 dBm. I've
> >> > also switched to testing bandwidth in controlled LAN environment using
> >> > iperf3, as suggested by Steve deRosier, with the DUT being the only
> >> > machine connected to the 2.4 GHz radio and the machine running the
> >> > iperf3 server connected via ethernet.
> >> >
> >>
> >> We have new experimental results in commit af8a41cccf8f46 ("rtlwifi: cleanup
> >> 8723be ant_sel definition"). You can use the above commit and do the same
> >> experiments (with ant_sel=0, 1 and 2) in your side, and then share your results.
> >> Since performance is tied to signal strength, you can only share signal strength.
> >>
> >
> > Please pay attention to cold reboot once ant_sel is changed.
> >
>
> I've tested the commit mentioned above and it fixes the problem on top
> of v4.16 (in addition to the latest wireless-drivers-next also been
> fixed as it already contains such commit). On v4.15, we also need the
> following commits before "af8a41cccf8f rtlwifi: cleanup 8723be ant_sel
> definition" to have a good performance again:
>
> 874e837d67d0 rtlwifi: fill FW version and subversion
> a44709bba70f rtlwifi: btcoex: Add power_on_setting routine
> 40d9dd4f1c5d rtlwifi: btcoex: Remove global variables from btcoex
v4.15 isn't longterm version and had been EOL.
>
> Surprisingly, it seems forcing ant_sel=1 is not needed anymore on
> these machines, as the shown by the numbers bellow (ant_sel=0 means
> that actually no parameter was passed to the module). I have powered
> off the machine and done a cold boot for every test. It seems
> something have changed in the antenna auto-selection code since v4.11,
> the latest point where I could confirm we definitely need to force
> ant_sel=1. I've been trying to understand what causes this difference,
> but haven't made progress on that so far, so any suggestions are
> appreciated (we are trying to decide if we can confidently drop the
> downstream DMI quirks for these specific machines).
>
I think your rtl8723be module programed correct efuse content, so it
works properly with ant_sel=0, and quirk isn't required for your
machine.
> w-d-n ant_sel=0: -14.00 dBm, 69.5 Mbps -> good
> w-d-n ant_sel=1: -10.00 dBm, 41.1 Mbps -> good
> w-d-n ant_sel=2: -44.00 dBm, 607 kbps -> bad
>
> v4.16 ant_sel=0: -12.00 dBm, 63.0 Mbps -> good
> v4.16 ant_sel=1: - 8.00 dBm, 69.0 Mbps -> good
> v4.16 ant_sel=2: -50.00 dBm, 224 kbps -> bad
>
> v4.15 ant_sel=0: - 8.00 dBm, 33.0 Mbps -> good
> v4.15 ant_sel=1: -10.00 dBm, 38.1 Mbps -> good
> v4.15 ant_sel=2: -48.00 dBm, 206 kbps -> bad
>
With your results, the efuse content is programmed as one or two antenna
on AUX path.
Regards,
PK
On Tue, May 8, 2018 at 1:37 AM, Pkshih <[email protected]> wrote:
> On Mon, 2018-05-07 at 14:49 -0700, João Paulo Rechi Vita wrote:
>> On Tue, May 1, 2018 at 10:58 PM, Pkshih <[email protected]> wrote:
>> > On Wed, 2018-05-02 at 05:44 +0000, Pkshih wrote:
>> >>
>> >> > -----Original Message-----
>> >> > From: João Paulo Rechi Vita [mailto:[email protected]]
>> >> > Sent: Wednesday, May 02, 2018 6:41 AM
>> >> > To: Larry Finger
>> >> > Cc: Steve deRosier; 莊彥宣; Pkshih; Birming Chiu; Shaofu; Steven Ting; Chaoming_Li; Kalle Valo;
>> >> > linux-wireless; Network Development; LKML; Daniel Drake; João Paulo Rechi Vita; linux@endless
>> m.c
>> >> om
>> >> > Subject: Re: RTL8723BE performance regression
>> >> >
>> >> > On Tue, Apr 3, 2018 at 7:51 PM, Larry Finger <[email protected]> wrote:
>> >> > > On 04/03/2018 09:37 PM, João Paulo Rechi Vita wrote:
>> >> > >>
>> >> > >> On Tue, Apr 3, 2018 at 7:28 PM, Larry Finger <[email protected]>
>> >> > >> wrote:
>> >> > >>
>> >> > >> (...)
>> >> > >>
>> >> > >>> As the antenna selection code changes affected your first bisection, do
>> >> > >>> you
>> >> > >>> have one of those HP laptops with only one antenna and the incorrect
>> >> > >>> coding
>> >> > >>> in the FUSE?
>> >> > >>
>> >> > >>
>> >> > >> Yes, that is why I've been passing ant_sel=1 during my tests -- this
>> >> > >> was needed to achieve a good performance in the past, before this
>> >> > >> regression. I've also opened the laptop chassis and confirmed the
>> >> > >> antenna cable is plugged to the connector labeled with "1" on the
>> >> > >> card.
>> >> > >>
>> >> > >>> If so, please make sure that you still have the same signal
>> >> > >>> strength for good and bad cases. I have tried to keep the driver and the
>> >> > >>> btcoex code in sync, but there may be some combinations of antenna
>> >> > >>> configuration and FUSE contents that cause the code to fail.
>> >> > >>>
>> >> > >>
>> >> > >> What is the recommended way to monitor the signal strength?
>> >> > >
>> >> > >
>> >> > > The btcoex code is developed for multiple platforms by a different group
>> >> > > than the Linux driver. I think they made a change that caused ant_sel to
>> >> > > switch from 1 to 2. At least numerous comments at
>> >> > > github.com/lwfinger/rtlwifi_new claimed they needed to make that change.
>> >> > >
>> >> > > Mhy recommended method is to verify the wifi device name with "iw dev". Then
>> >> > > using that device
>> >> > >
>> >> > > sudo iw dev <dev_name> scan | egrep "SSID|signal"
>> >> > >
>> >> >
>> >> > I have confirmed that the performance regression is indeed tied to
>> >> > signal strength: on the good cases signal was between -16 and -8 dBm,
>> >> > whereas in bad cases signal was always between -50 to - 40 dBm. I've
>> >> > also switched to testing bandwidth in controlled LAN environment using
>> >> > iperf3, as suggested by Steve deRosier, with the DUT being the only
>> >> > machine connected to the 2.4 GHz radio and the machine running the
>> >> > iperf3 server connected via ethernet.
>> >> >
>> >>
>> >> We have new experimental results in commit af8a41cccf8f46 ("rtlwifi: cleanup
>> >> 8723be ant_sel definition"). You can use the above commit and do the same
>> >> experiments (with ant_sel=0, 1 and 2) in your side, and then share your results.
>> >> Since performance is tied to signal strength, you can only share signal strength.
>> >>
>> >
>> > Please pay attention to cold reboot once ant_sel is changed.
>> >
>>
>> I've tested the commit mentioned above and it fixes the problem on top
>> of v4.16 (in addition to the latest wireless-drivers-next also been
>> fixed as it already contains such commit). On v4.15, we also need the
>> following commits before "af8a41cccf8f rtlwifi: cleanup 8723be ant_sel
>> definition" to have a good performance again:
>>
>> 874e837d67d0 rtlwifi: fill FW version and subversion
>> a44709bba70f rtlwifi: btcoex: Add power_on_setting routine
>> 40d9dd4f1c5d rtlwifi: btcoex: Remove global variables from btcoex
>
> v4.15 isn't longterm version and had been EOL.
>
Right, but this is a performace regression in comparison to v4.11, so
if "af8a41cccf8f rtlwifi: cleanup 8723be ant_sel definition" is marked
for stable, shouldn't these other patches be brought as well? All
releases since v4.11 are probably affected, but honestly I don't have
a strong understanding of how the stable trees operate in situations
like this.
>>
>> Surprisingly, it seems forcing ant_sel=1 is not needed anymore on
>> these machines, as the shown by the numbers bellow (ant_sel=0 means
>> that actually no parameter was passed to the module). I have powered
>> off the machine and done a cold boot for every test. It seems
>> something have changed in the antenna auto-selection code since v4.11,
>> the latest point where I could confirm we definitely need to force
>> ant_sel=1. I've been trying to understand what causes this difference,
>> but haven't made progress on that so far, so any suggestions are
>> appreciated (we are trying to decide if we can confidently drop the
>> downstream DMI quirks for these specific machines).
>>
> I think your rtl8723be module programed correct efuse content, so it
> works properly with ant_sel=0, and quirk isn't required for your
> machine.
>
>> w-d-n ant_sel=0: -14.00 dBm, 69.5 Mbps -> good
>> w-d-n ant_sel=1: -10.00 dBm, 41.1 Mbps -> good
>> w-d-n ant_sel=2: -44.00 dBm, 607 kbps -> bad
>>
>> v4.16 ant_sel=0: -12.00 dBm, 63.0 Mbps -> good
>> v4.16 ant_sel=1: - 8.00 dBm, 69.0 Mbps -> good
>> v4.16 ant_sel=2: -50.00 dBm, 224 kbps -> bad
>>
>> v4.15 ant_sel=0: - 8.00 dBm, 33.0 Mbps -> good
>> v4.15 ant_sel=1: -10.00 dBm, 38.1 Mbps -> good
>> v4.15 ant_sel=2: -48.00 dBm, 206 kbps -> bad
>>
>
> With your results, the efuse content is programmed as one or two antenna
> on AUX path.
>
With v4.11 I had good performance results on this very same machine
(thus same efuse contents) only when passing ant_sel=1, so there has
to be some change on the code that parses the efuse contents and
decides which antenna will be used.
--
João Paulo Rechi Vita
http://about.me/jprvita
On Wed, 2018-05-09 at 13:33 -0700, João Paulo Rechi Vita wrote:
> On Tue, May 8, 2018 at 1:37 AM, Pkshih <[email protected]> wrote:
> > On Mon, 2018-05-07 at 14:49 -0700, João Paulo Rechi Vita wrote:
> >> On Tue, May 1, 2018 at 10:58 PM, Pkshih <[email protected]> wrote:
> >> > On Wed, 2018-05-02 at 05:44 +0000, Pkshih wrote:
> >> >>
> >> >> > -----Original Message-----
> >> >> > From: João Paulo Rechi Vita [mailto:[email protected]]
> >> >> > Sent: Wednesday, May 02, 2018 6:41 AM
> >> >> > To: Larry Finger
> >> >> > Cc: Steve deRosier; 莊彥宣; Pkshih; Birming Chiu; Shaofu; Steven Ting; Chaoming_Li; Kalle
> Valo;
> >> >> > linux-wireless; Network Development; LKML; Daniel Drake; João Paulo Rechi Vita; linux@endl
> ess
> >> m.c
> >> >> om
> >> >> > Subject: Re: RTL8723BE performance regression
> >> >> >
> >> >> > On Tue, Apr 3, 2018 at 7:51 PM, Larry Finger <[email protected]> wrote:
> >> >> > > On 04/03/2018 09:37 PM, João Paulo Rechi Vita wrote:
> >> >> > >>
> >> >> > >> On Tue, Apr 3, 2018 at 7:28 PM, Larry Finger <[email protected]>
> >> >> > >> wrote:
> >> >> > >>
> >> >> > >> (...)
> >> >> > >>
> >> >> > >>> As the antenna selection code changes affected your first bisection, do
> >> >> > >>> you
> >> >> > >>> have one of those HP laptops with only one antenna and the incorrect
> >> >> > >>> coding
> >> >> > >>> in the FUSE?
> >> >> > >>
> >> >> > >>
> >> >> > >> Yes, that is why I've been passing ant_sel=1 during my tests -- this
> >> >> > >> was needed to achieve a good performance in the past, before this
> >> >> > >> regression. I've also opened the laptop chassis and confirmed the
> >> >> > >> antenna cable is plugged to the connector labeled with "1" on the
> >> >> > >> card.
> >> >> > >>
> >> >> > >>> If so, please make sure that you still have the same signal
> >> >> > >>> strength for good and bad cases. I have tried to keep the driver and the
> >> >> > >>> btcoex code in sync, but there may be some combinations of antenna
> >> >> > >>> configuration and FUSE contents that cause the code to fail.
> >> >> > >>>
> >> >> > >>
> >> >> > >> What is the recommended way to monitor the signal strength?
> >> >> > >
> >> >> > >
> >> >> > > The btcoex code is developed for multiple platforms by a different group
> >> >> > > than the Linux driver. I think they made a change that caused ant_sel to
> >> >> > > switch from 1 to 2. At least numerous comments at
> >> >> > > github.com/lwfinger/rtlwifi_new claimed they needed to make that change.
> >> >> > >
> >> >> > > Mhy recommended method is to verify the wifi device name with "iw dev". Then
> >> >> > > using that device
> >> >> > >
> >> >> > > sudo iw dev <dev_name> scan | egrep "SSID|signal"
> >> >> > >
> >> >> >
> >> >> > I have confirmed that the performance regression is indeed tied to
> >> >> > signal strength: on the good cases signal was between -16 and -8 dBm,
> >> >> > whereas in bad cases signal was always between -50 to - 40 dBm. I've
> >> >> > also switched to testing bandwidth in controlled LAN environment using
> >> >> > iperf3, as suggested by Steve deRosier, with the DUT being the only
> >> >> > machine connected to the 2.4 GHz radio and the machine running the
> >> >> > iperf3 server connected via ethernet.
> >> >> >
> >> >>
> >> >> We have new experimental results in commit af8a41cccf8f46 ("rtlwifi: cleanup
> >> >> 8723be ant_sel definition"). You can use the above commit and do the same
> >> >> experiments (with ant_sel=0, 1 and 2) in your side, and then share your results.
> >> >> Since performance is tied to signal strength, you can only share signal strength.
> >> >>
> >> >
> >> > Please pay attention to cold reboot once ant_sel is changed.
> >> >
> >>
> >> I've tested the commit mentioned above and it fixes the problem on top
> >> of v4.16 (in addition to the latest wireless-drivers-next also been
> >> fixed as it already contains such commit). On v4.15, we also need the
> >> following commits before "af8a41cccf8f rtlwifi: cleanup 8723be ant_sel
> >> definition" to have a good performance again:
> >>
> >> 874e837d67d0 rtlwifi: fill FW version and subversion
> >> a44709bba70f rtlwifi: btcoex: Add power_on_setting routine
> >> 40d9dd4f1c5d rtlwifi: btcoex: Remove global variables from btcoex
> >
> > v4.15 isn't longterm version and had been EOL.
> >
>
> Right, but this is a performace regression in comparison to v4.11, so
> if "af8a41cccf8f rtlwifi: cleanup 8723be ant_sel definition" is marked
> for stable, shouldn't these other patches be brought as well? All
> releases since v4.11 are probably affected, but honestly I don't have
> a strong understanding of how the stable trees operate in situations
> like this.
>
see below.
> >>
> >> Surprisingly, it seems forcing ant_sel=1 is not needed anymore on
> >> these machines, as the shown by the numbers bellow (ant_sel=0 means
> >> that actually no parameter was passed to the module). I have powered
> >> off the machine and done a cold boot for every test. It seems
> >> something have changed in the antenna auto-selection code since v4.11,
> >> the latest point where I could confirm we definitely need to force
> >> ant_sel=1. I've been trying to understand what causes this difference,
> >> but haven't made progress on that so far, so any suggestions are
> >> appreciated (we are trying to decide if we can confidently drop the
> >> downstream DMI quirks for these specific machines).
> >>
> > I think your rtl8723be module programed correct efuse content, so it
> > works properly with ant_sel=0, and quirk isn't required for your
> > machine.
> >
> >> w-d-n ant_sel=0: -14.00 dBm, 69.5 Mbps -> good
> >> w-d-n ant_sel=1: -10.00 dBm, 41.1 Mbps -> good
> >> w-d-n ant_sel=2: -44.00 dBm, 607 kbps -> bad
> >>
> >> v4.16 ant_sel=0: -12.00 dBm, 63.0 Mbps -> good
> >> v4.16 ant_sel=1: - 8.00 dBm, 69.0 Mbps -> good
> >> v4.16 ant_sel=2: -50.00 dBm, 224 kbps -> bad
> >>
> >> v4.15 ant_sel=0: - 8.00 dBm, 33.0 Mbps -> good
> >> v4.15 ant_sel=1: -10.00 dBm, 38.1 Mbps -> good
> >> v4.15 ant_sel=2: -48.00 dBm, 206 kbps -> bad
> >>
> >
> > With your results, the efuse content is programmed as one or two antenna
> > on AUX path.
> >
>
> With v4.11 I had good performance results on this very same machine
> (thus same efuse contents) only when passing ant_sel=1, so there has
> to be some change on the code that parses the efuse contents and
> decides which antenna will be used.
>
Since btcoex control TDMA parameters for WiFi and BT, antenna related code
is put in btcoex. That's why ant_sel is used by btcoex.
In v4.12, we upgraded btcoex and firmware in order to yield better balance
between WiFi and BT, meanwhile code flow had some changes. So, the single
commit af8a41cccf8f ("rtlwifi: cleanup 8723be ant_sel definition") won't
work on v4.11. In other words, if you want v4.11 work properly, you need to
apply all changes of btcoex.
The parser of efuse isn't changed, and I think the reason why v4.11 needs
ant_sel=1 is the same as above.
Regards
PK