iMX8.MP WiFi connection performance problem

[idragan]

Hi everyone,

We are using system based on iMX8.MP and we have issue with the performance of WiFi interface. Namely, we're sending some data with frequency of 2kHz over the socket from our board to the PC and it happens that after a few minutes connection simply breaks - there is no way to connect to the board and existing terminal isn't responsive.

During the inspection of a problem, it's noticeable that there are the spikes of receiving the data. Moreover, when using the command ss -tmp, the are high values of Send-Q, sometimes reaching more than 100.000 during the spikes.

It's worth to note that the same logic for sending and receiving the data doesn't cause the problem on other system we use.

I'm attaching the information which might be useful for understanding the issue:

• board: DART-MX8M-PLUS v1.3
• WiFi chipset: BCM4339/2
• Linux version: 6.1.36-imx8mp
• Yocto version: mickledore

Running the command ethtool -i wlan0 results in the following output:

driver: brcmfmac
version: 6.37.39.141
firmware-version: CY)
expansion-rom-version: 
bus-info: mmc0:0001:1
supports-statistics: no
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

Results of ping and iperf3 command are as following:

iperf3 -c 192.168.75.2
Connecting to host 192.168.75.2, port 5201
[  5] local 192.168.75.1 port 35910 connected to 192.168.75.2 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  4.50 MBytes  37.7 Mbits/sec    7    140 KBytes       
[  5]   1.00-2.00   sec  3.73 MBytes  31.3 Mbits/sec    0    158 KBytes       
[  5]   2.00-3.00   sec  3.73 MBytes  31.3 Mbits/sec    0    171 KBytes       
[  5]   3.00-4.00   sec  3.73 MBytes  31.3 Mbits/sec    0    187 KBytes       
[  5]   4.00-5.00   sec  1.24 MBytes  10.4 Mbits/sec  144   91.9 KBytes       
[  5]   5.00-6.00   sec  1.18 MBytes  9.91 Mbits/sec   60   26.9 KBytes       
[  5]   6.00-7.00   sec   891 KBytes  7.30 Mbits/sec   32   28.3 KBytes       
[  5]   7.00-8.00   sec  2.80 MBytes  23.5 Mbits/sec    0   72.1 KBytes       
[  5]   8.00-9.00   sec  3.54 MBytes  29.7 Mbits/sec    0    105 KBytes       
[  5]   9.00-10.00  sec  3.98 MBytes  33.4 Mbits/sec    0    130 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  29.3 MBytes  24.6 Mbits/sec  243             sender
[  5]   0.00-10.08  sec  28.4 MBytes  23.6 Mbits/sec                  receiver

ping -U -c 10 192.168.75.1  
PING 192.168.75.1 (192.168.75.1) 56(84) bytes of data.
64 bytes from 192.168.75.1: icmp_seq=1 ttl=64 time=0.092 ms
64 bytes from 192.168.75.1: icmp_seq=2 ttl=64 time=0.069 ms
64 bytes from 192.168.75.1: icmp_seq=3 ttl=64 time=0.059 ms
64 bytes from 192.168.75.1: icmp_seq=4 ttl=64 time=0.060 ms
64 bytes from 192.168.75.1: icmp_seq=5 ttl=64 time=0.053 ms
64 bytes from 192.168.75.1: icmp_seq=6 ttl=64 time=0.058 ms
64 bytes from 192.168.75.1: icmp_seq=7 ttl=64 time=0.101 ms
64 bytes from 192.168.75.1: icmp_seq=8 ttl=64 time=0.062 ms
64 bytes from 192.168.75.1: icmp_seq=9 ttl=64 time=0.057 ms
64 bytes from 192.168.75.1: icmp_seq=10 ttl=64 time=0.057 ms

--- 192.168.75.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9195ms
rtt min/avg/max/mdev = 0.053/0.066/0.101/0.015 ms

Deactivating power saving mode for WiFi statistically has improved some performance but there is no huge difference in data stream spikes:

iperf3 -c 192.168.75.2
Connecting to host 192.168.75.2, port 5201
[  5] local 192.168.75.1 port 59894 connected to 192.168.75.2 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  4.51 MBytes  37.8 Mbits/sec    0    180 KBytes       
[  5]   1.00-2.00   sec  3.98 MBytes  33.4 Mbits/sec    7    195 KBytes       
[  5]   2.00-3.00   sec  3.48 MBytes  29.2 Mbits/sec    0    218 KBytes       
[  5]   3.00-4.00   sec  3.98 MBytes  33.4 Mbits/sec    0    229 KBytes       
[  5]   4.00-5.00   sec  3.98 MBytes  33.4 Mbits/sec    0    233 KBytes       
[  5]   5.00-6.00   sec  3.48 MBytes  29.2 Mbits/sec    0    233 KBytes       
[  5]   6.00-7.00   sec  3.48 MBytes  29.2 Mbits/sec    0    235 KBytes       
[  5]   7.00-8.00   sec  3.98 MBytes  33.4 Mbits/sec    0    243 KBytes       
[  5]   8.00-9.00   sec  3.98 MBytes  33.4 Mbits/sec    0    252 KBytes       
[  5]   9.00-10.00  sec  3.73 MBytes  31.3 Mbits/sec    0    263 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  38.6 MBytes  32.4 Mbits/sec    7             sender
[  5]   0.00-10.63  sec  37.1 MBytes  29.3 Mbits/sec                  receiver

ping -U -c 10 192.168.75.1
PING 192.168.75.1 (192.168.75.1) 56(84) bytes of data.
64 bytes from 192.168.75.1: icmp_seq=1 ttl=64 time=0.089 ms
64 bytes from 192.168.75.1: icmp_seq=2 ttl=64 time=0.061 ms
64 bytes from 192.168.75.1: icmp_seq=3 ttl=64 time=0.057 ms
64 bytes from 192.168.75.1: icmp_seq=4 ttl=64 time=0.051 ms
64 bytes from 192.168.75.1: icmp_seq=5 ttl=64 time=0.058 ms
64 bytes from 192.168.75.1: icmp_seq=6 ttl=64 time=0.049 ms
64 bytes from 192.168.75.1: icmp_seq=7 ttl=64 time=0.051 ms
64 bytes from 192.168.75.1: icmp_seq=8 ttl=64 time=0.051 ms
64 bytes from 192.168.75.1: icmp_seq=9 ttl=64 time=0.051 ms
64 bytes from 192.168.75.1: icmp_seq=10 ttl=64 time=0.054 ms

--- 192.168.75.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9196ms
rtt min/avg/max/mdev = 0.049/0.057/0.089/0.011 ms

Did anybody have similar problem?

Thanks in advance,
Dragan

[AldoG]

Hello,

Unfortunately it is difficult for us to reproduce since it is not an NXP board nor is one of the NXP WiFi chips, I would suggest to please reach out either Broadcom or Variscite for this kind of issue.

Best regards/Saludos,
Aldo.

[idragan]

The same connection problem persist even in a bit different scenario, when using DART-MX8M-PLUS development kit.

Namely, we're acquiring the data from the sensor and sending it over the socket in the local network, where python script is receiving the data and storing it into the file. After some time, access to the board via WiFi access point, which is present there, becomes unavailable and unresponsive.

Should I still contact Variscite/Broadcom or is it producible from your side?

Thanks a lot in advance,
Dragan