• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 40 subscribers
  • Views 211 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

WL1837MOD: Slow STA TX performance against 2x2 802.11n AP

Ursula
Prodigy 10 points
Part Number: WL1837MOD

Hello,

We're observing the following slow STA performance on WL1837MOD TX, when connecting to a 2x2 2.4GHz 802.11n AP:

$ iperf3 -c 192.168.1.157
Connecting to host 192.168.1.157, port 5201
[  5] local 192.168.1.211 port 44770 connected to 192.168.1.157 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  1.28 MBytes  10.7 Mbits/sec    0   48.1 KBytes
[  5]   1.00-2.00   sec   764 KBytes  6.25 Mbits/sec    0   56.6 KBytes
[  5]   2.00-3.00   sec   764 KBytes  6.26 Mbits/sec    0   59.4 KBytes

Changing the TCP congestion from cubic to reno as suggested elsewhere on the forum yields no change:

$ iperf3 -c 192.168.1.157
Connecting to host 192.168.1.157, port 5201
[  5] local 192.168.1.211 port 41052 connected to 192.168.1.157 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  1.53 MBytes  12.8 Mbits/sec    0    205 KBytes
[  5]   1.00-2.00   sec   764 KBytes  6.26 Mbits/sec    0    211 KBytes
[  5]   2.00-3.00   sec   764 KBytes  6.26 Mbits/sec    0    211 KBytes

Running a benchmark with a 2.4GHz AP in 802.11g mode and no WMM in the same conditions, the throughput is faster than for the 2x2 802.11n AP:

$ iperf3 -c 192.168.199.1
Connecting to host 192.168.199.1, port 5201
[  5] local 192.168.199.24 port 47344 connected to 192.168.199.1 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  2.96 MBytes  24.8 Mbits/sec    0    106 KBytes
[  5]   1.00-2.00   sec  2.24 MBytes  18.8 Mbits/sec    0    113 KBytes
[  5]   2.00-3.00   sec  2.49 MBytes  20.9 Mbits/sec    0    113 KBytes

Going back to the 802.11n AP:

1/ Sometimes, but not always, changing fw_logger in sysfs to 2 makes the problem spontaneously go away. Sometimes, but not always, changing fw_logger in sysfs to 2 and also starting wl_logproxy makes the problem spontaneously go away.

2/ If I change the QoS from default Best Effort to Background problem always (reliably) goes away:

$ iperf3 -c 192.168.1.157 -S 32
Connecting to host 192.168.1.157, port 5201
[  5] local 192.168.1.211 port 44780 connected to 192.168.1.157 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  9.05 MBytes  75.9 Mbits/sec    0    262 KBytes
[  5]   1.00-2.00   sec  9.32 MBytes  78.2 Mbits/sec    0    322 KBytes
[  5]   2.00-3.00   sec  8.95 MBytes  75.1 Mbits/sec    0    341 KBytes

This throughput slowness is not noticed when running the WL1837MOD as an access point, the performance is good. This STA slowness also doesn't seem to be related to on-air traffic and WMM, as sometimes it gets fixed spontaneously by the fw_logger / wl_logproxy as noted above. It seems that something is not always performing well with the AC_BE TX queue in the firmware? Or there is some congestion problem that is somehow sometimes fixed by turning on the logging? Any suggestions?

WiLink FW: 8.9.0.0.90
WiLink Driver: kernel v4.19.193, with all R8.8 kernel patches applied

  • 0
    TI__Mastermind 30140 points

    Hi Ursula,

    Could you inform me which AP you are using?

  • 0 in reply to Sabeeh Khan1
    Prodigy 10 points

    Hi Sabeeh,

    I see this with a Tenda F3 but we have also seen this with other APs.

    After further digging, it looks like a newer wpa_supplicant is necessary to trigger the problem. In particular, the problematic feature seems to be NL80211_EXT_FEATURE_CONTROL_PORT_OVER_NL80211 which is something that older versions of wpa_supplicant (such as in R8.8) do not make use of.

    Disabling the following in the kernel, in net/mac80211/main.c, seems to resolve the performance problems:

            wiphy_ext_feature_set(wiphy,
                                  NL80211_EXT_FEATURE_CONTROL_PORT_OVER_NL80211);

    It looks like there remains an issue to sort out somewhere in the WiLink driver and/or firmware, but the above looks like a suitable workaround for the time being...