TCP packets lost with the GT202 Addon

Hello,

 

I have the following problem with a S7G2-DK board, SSP 1.2.0 and Wifi Addon Distribution GT202 1.0.0 SSPv1.2.

A server/client application is running in the following way:

- The server is an echo server (supporting both TCP and UDP), that waits for a client connection (TCP only), then receives data on a socket and echoes it back. This server is running on PC

- The client is running on the DK board, and does the following:

  - Scans all available wifi access points

  - Connects to a wifi access point (same as the PC, WPA2 encryption)

  - Updates the time via an NTP request

  - Start a TCP test loop, generating 1MB of random data and sending it to the server in chunks of 256 bytes. Then, it waits for each chunk to be received and compares the sent/received data

  - Start a UDP test loop, generating 1MB of random data and sending it to the server in chunks of 4096 bytes. Then, it waits for each chunk to be received and compares the sent/received data

  - Start a multithreaded TCP/UDP test loop, with 1 socket opened per protocol, generating 1MB of random data on each socket and sending it to the server in chunks of 256/4096 bytes. Then, it waits for each chunk to be received and compares the sent/received data

 

Test results:

- Single TCP socket test works fine, all the data is sent/received, no data corrupted

- Single UDP socket test works fine, there are some UDP packets being lost, but this is normal, due to the unreliability of the UDP protocol (and no re-transmission)

- Issue observed when testing with 2 opened sockets, one TCP and one UDP. In this scenario, I have lost TCP packets, which should never be the case. Note that I've set the socket receive timeout to 5 seconds, and the wifi rssi is very high (2 meters away from the wifi router)

 

I've attached test logs for both the server and the client applications, for a better understanding of the issue. Also, the issue is reproducible 100%, and always when "stressing" the board with more than 1 opened socket. With a single socket, I never saw any issue.

 

Please advise,

ValentinWifiServerTest.txtWifiClientTest.txt

  • What I forgot to mention is that the DK project supports multi-interfaces, with both ethernet and wifi being supported. On ethernet, there is no issue observed whatsoever, only on wifi. So, the first main question which arise, could this issue be related to the GT202 device itself, or to it's integration in the SSP?
  • Is this using NetX, or the GT-202 on-chip stack?
  • In reply to Jeremy:

    Hi Jeremy, it is with NetX, the on-chip stack support is disabled.
  • In reply to Valentin:

    Hi Valentin,

    At the beginning, for debugging network related issues, I strongly recommend to use a traffic analyzer like Wireshark.

    I've tried to reproduce this issue and created an example project with TCP and UDP clients. Both clients send and receive the data correctly. You may try to tune a TCP window size, but too large value can have a negative impact on performance. Moreover, there is an option in GT202 WiFi module configuration settings called "Request High Throughput" - it may be worth to enable this one.

    Please find the project below:

    S7_DK_WiFi_Benchmark_1_3_0.zip

    Regards,
    adboc

  • In reply to adboc:

    Hi adboc,

    Thanks for your support. I found the issue, it was related to the default value of the Driver Heap Size in bytes = 8192 bytes. The GT202 driver uses dynamic memory allocation for the incoming Rx packets, and once these packets are copied by my code above the driver (which runs in another thread), the Rx buffers are freed.

    This default configuration was too small for my usecase. Keeping in mind that I transfer UDP packets in 4kB chunks, if 2 UDP packets are received and not freed by the application, then I was getting memory allocation errors for the other incoming TCP packets.

    The issue is solved by increasing the Driver Heap Size to 16kB.

    Thanks for your support,
    Valentin