2 Replies Latest reply on Dec 9, 2016 1:59 PM by dickb_1995216

    System hanging after receiving UDP packets

    nrcrast

      Hi,

       

      I am using the Inventek ISM43341 module with WICED SDK 3.5.2. I have the Inventek module configured to be in soft AP mode, and I have a linux PC client sending UDP packets. I am sending 128 byte packets at the rate of about 100 a second. After a few minutes (or sometimes just a few seconds), the Inventek module stops receiving packets and it seems like the whole IP stack just dies. This happens with both NetX and LwIP. Increasing the packet rate makes the problem occur faster usually.

       

      See SoftAP mode stuck receiving UDP packets for main thread in Wi-Fi forum.

       

      To reproduce:

       

      1.) Build the ap_clients_rssi for WICED: make snip.ap_clients_rssi-ISM43341_M4G_L44-debug download run

       

      2.) Build talker.c for Linux.

       

      3.) Connect to WICED soft AP

       

      4.) Start talker: ./talker [interface/default] [port] (Eg. ./talker default 5678 will start sending on your default interface and expect to receive data on port 5678)

       

      Change the packet frequency with the tv struct in talker.c.

        • 1. Re: System hanging after receiving UDP packets
          mifo

          Adding als@inventeksys.com and dickb_1995216 from Inventek so that they can have someone on the team look into the issue.

          • 2. Re: System hanging after receiving UDP packets
            dickb_1995216

            There are a few factors that impact the reliability of sending small packets sizes at fast rates:

            1. 1. The modules use Client WiFi chips, not Access Point(AP)/Router chips.

            The major difference between the two is the AP/Router chip has significantly more

            memory than the Client chip.  So when the SoftAP is running on a client chip the

            buffering is limited.

            1. 2. The WiFi stack is running on the microprocessor on the module. This means that all packets

            that are specific to the module and broadcast to the module pass to and from the

            stack over the SDIO bus. When in SoftAP mode, all packets sent by a connected

            client to the internet will also be directed to the stack.  This is caused by the fact that the connected client is not aware that there is no internet connection.

            1. 3. The microprocessor on the module is memory currently limited to 128KB of SRAM.

            This SRAM must hold all of the buffers (TX and RX) for the stack and all of the variables

            buffer for the running application.  In the case of the IWIN AT command set, the system

            architecture is designed to handle a wide variety of communication tasks.  This places

            restriction on the amount of memory that can be dedicated to the buffers for the stack. In your case, you can experiment with different buffer sizes.

            1. 4. The Client chips were designed for systems with much greater memory resources

            (Smartphones). So when the WICED API was designed certain assumptions were

            made on the number and types data traffic that would be passing through the stack.

            To this the algorithm used has some limitations.

            Over the years, Broadcom improved the algorithm for better performance, but it still

            has some limitations. One of these is sending small packets very fast. The buffers for the

            stack are not dynamically sized to the incoming data. They are a fixed size to handle

            the max MTU (1518 bytes). The buffers are used for both the data the application is sending

            and receiving as well as the network traffic (ARP, ICMP, etc.) created by having devices on

            the network.

            So there is a point where the system can’t handle all the traffic. From our years

            of experience of working with different versions of WICED and our IWIN command set that point

            tends to occur with packet rates of less than 15ms (over 66 packets per second). The system  can

            become unreliable and unpredictable whether it be seconds, minutes, hours, before the system fails.

             

            You can try to optimize performance by adjusting the PBUFs to your needs within WICED.

            1 of 1 people found this helpful