On Tue, Apr 3, 2018 at 7:51 PM, Larry Finger <larry.fin...@lwfinger.net> 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 <larry.fin...@lwfinger.net>
>> 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.
