driver icon indicating copy to clipboard operation
driver copied to clipboard

TX throughput is slow and ping lost

Open db-ueda opened this issue 6 years ago • 6 comments

I'm testing wilc1000 throughput in STA mode by iperf3 TCP mode. RX is very good(30-40Mbps), but TX is 4-7Mbps. Too may TCP retry are happened like this.

Connecting to host 192.168.3.15, port 5201
[  4] local 192.168.3.64 port 36014 connected to 192.168.3.15 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   509 KBytes  4.17 Mbits/sec    6   11.3 KBytes
[  4]   1.00-2.00   sec   826 KBytes  6.76 Mbits/sec    2   14.1 KBytes
[  4]   2.00-3.00   sec   778 KBytes  6.36 Mbits/sec    5   8.48 KBytes
[  4]   3.00-4.00   sec   679 KBytes  5.57 Mbits/sec    7   11.3 KBytes
[  4]   4.00-5.00   sec   653 KBytes  5.35 Mbits/sec    6   12.7 KBytes
[  4]   5.00-6.00   sec   523 KBytes  4.29 Mbits/sec    7   7.07 KBytes

And ping to AP lost 3%. I think this rate is very bad. (The other wifi module is 0%)

db-ueda avatar Oct 10 '19 05:10 db-ueda

I'm having similar issues... 5 Mbits/sec when sending, < 1Mbits/sec when receiving.

PING: 15% packet loss, average time 398ms.

landersson avatar Oct 21 '19 08:10 landersson

Please report on salesforce http://microchipsupport.force.com/

AdhamAbozaeid avatar Oct 21 '19 17:10 AdhamAbozaeid

This issue again, is something numerous users point out and have opened salesforce tickets for.

https://github.com/linux4wilc/driver/issues/51 https://github.com/linux4wilc/driver/issues/34 https://github.com/linux4wilc/driver/issues/25

It is also mentioned in the firmware threads: https://github.com/linux4wilc/firmware/issues/7

My point is, that all these issues are quite old and the tickets related to them as well. For my part, my tickets were closed due to a timeout.

I'm really bothered by the fact, that many of the users participating have these units already running in a productive environment but communication drags, be it here or on salesforce. this down to a halt. Due to the nature of these issues they were hard to spot early on with lab test patterns.

Issues like this one: https://github.com/linux4wilc/driver/issues/53 also might be a consequence of the degrading performance finaly leading to serious problems.

I'm really sorry for @AdhamAbozaeid who seemingly has to handle this alone (besides a software developer in the first place). Please don't feel personally attacked. I'm really glad about your commitment.

Mateusz-Gwara avatar Oct 24 '19 08:10 Mateusz-Gwara

I have the same kind of problem. My linux board is in STA mode and i test with iperf3 (client or server). The throughput is about 20Mbps in both tests. I use version 15.2.1 oflinux driver on IMX6 platform. Do you think i should change driver version? Are there important modifications on last releases?

flgcpwd avatar Nov 08 '19 12:11 flgcpwd

There's an important update that improves the throughput for WILC3000 on the latest release. Which WILC/bus/bus speed are you using? is it 20Mbps UDP or TCP?

AdhamAbozaeid avatar Nov 08 '19 21:11 AdhamAbozaeid

Might as well pile on this problem. I'm seeing the same using the RTOS version of WILC1000 firmware (asf-3.49.1). While the firmware blobs are different, I expect their core functionality is pretty much the same.

When a packet is lost, my instrumentation shows that the packet is accepted by the WILC1000 firmware over SPI, an interrupt is generated (I have enabled INT_BASED_TX) and WIFI_HOST_RCV_CTRL_4 is non-zero, but the destination never sees the packet (as evidenced using tcpdump).

Unfortunately I don't have access to equipment to sniff the RF side of things so no idea if the WILC1000 even attempts to send the packet over the air.

Packet loss like this has a significant detrimental effect on TCP throughput on my product, to the point where I'm looking to design-in a different WiFi controller.

Does anyone at Microchip read these reports?

Steve

Syncena avatar Nov 02 '20 16:11 Syncena