• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 40 subscribers
  • Views 202 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC3220SF-LAUNCHXL: Long time in send function, multiple lost packets

Michelle Hedlund
Prodigy 100 points
Part Number: CC3220SF-LAUNCHXL

Hello,

I am using the TCP Echo example in CCS. I've noticed an issue while streaming data from my CC3220 to my PC where several (5-15) packets will be lost an retransmitted in a row. This occurrence coincides with the send function taking a long time to return (1 - 10 sec). Usually, the send function returns within 2 ms, even when there is fast retransmission. The data I am streaming comes in at a constant rate, so I lose data when the send function stalls like this.

Here is an image of the TCP throughput when this occurs:

I have tested this issue with multiple launchpads running the program at once on the same network to see if the problem increases with increased traffic. The issue occurs at the same frequency (about once every 20 min) with added launchpads, and the data rate is low enough (~0.2 Mbps per launchpad) that I do not believe that network congestion is the underlying problem. With multiple launchpads running the program, the dropped packets occur at the same time.

Do you have any insight as to why this problem may be occurring? Or is there a way to return from the send function when it takes a long time so that I can continue to buffer up the incoming data and try to resend?

Thanks,

Michelle

  • 0
    Prodigy 100 points

    My apologies, it looks like the image did not attach in the post.

  • 0 in reply to Michelle Hedlund
    TI__Mastermind 40965 points

    Hi Michelle,

    What is the packet size that you are using for your TCP traffic? If the sl_Send takes seconds to return, it most likely means that either the CC3220 has run out of its TCP buffer, or the remote side is out of buffer.

    Are you able to get an air sniffer capture? That would help us see what is causing the CC3220 to retransmit.

    Regards,

    Michael

  • 0 in reply to Michael Reymond
    Prodigy 100 points

    Hello Michael,

     

    Thank you for your response!

     

    I am sending packets of 1400 bytes, which I chose because it is safely below the MTU for ethernet. I've also included error checking on the application receiving the data to notify me when the receiving buffer is full, and it never throws an error in regard to this issue.

     

    I've captured the network traffic in Wireshark to observe the issue, but I didn't notice any other traffic on the network that would be slowing down transmission. There are some LLDP multicast messages shortly before the issue occurs, but those messages appear every 30 seconds, so they seem unlikely to have caused the problem.

     

    I've attached a.pcap file for you to look at. The error starts at packet 48393. This capture includes 2 CC3220's (10.156.1.100 and 10.156.1.102) transmitting to a desktop (10.156.1.144). The desktop is connected to the network via ethernet.

     

    retransmission_errs_01_04_21.zip

    I've placed the network I am using on a different channel from my home wifi to avoid channel interference, but there are some neighboring networks on the channel that I cannot control. Is it possible for traffic on those networks to cause mine to drop packets?

     

    Thanks,

    Michelle

  • 0 in reply to Michelle Hedlund
    TI__Mastermind 40965 points

    Hi Michelle,

    Your MTU should be fine, and given you're checking the buffer on the receive side we can eliminate that as a source of the issue. Your wireshark logs show the retransmissions, but they don't have any additional insight into why the issue might be occurring though.

    Do you observe the issue once every 20 minutes without fail, or do the packets sometimes get dropped sooner/later?

    Also, do you see the same issue occur when your CC3220 devices are connected to a different AP? In the past, this sort of periodic connectivity error was found to be an interoperability issue with specific AP models. Newer CC32xx servicepacks should have the issue fixed though. Are you ensuring that you have the latest CC32xx servicepack running on your CC3220?

    Regards,

    Michael

  • 0 in reply to Michael Reymond
    Prodigy 100 points

    Hi Michael,

    After streaming data for longer periods of time, I've noticed that the error occurs exactly every hour. I originally thought it was ~every 20 minutes because I usually saw the first error about 20-30 min after I started streaming, but now I have observed that if I let the program keep running, I will get another error exactly 1 hour after the first error occurred. I thought maybe my DHCP lease time might be causing it, but it is set to 24 hours, so probably not.

    I have tried using both a different router and a different computer. The error persists in both cases.

    For the service pack, I think it is up to date? I am using the simplelink sdk 4.30.00.06 and service pack 3.17.0.4. which I think were updated just a couple months ago.

    Another thing to mention is that I have run this test in an environment where I am sure there is no interfering traffic, and I still see the issue. Is there some sort of interrupt on the CC3220 or something that gets reset every hour that could cause this problem?

    Thanks,

    Michelle

  • 0 in reply to Michelle Hedlund
    TI__Mastermind 40965 points

    Hi Michelle,

    It's interesting that the error occurs exactly every hour, consistently.

    The SDK and servicepack that you are using are up to date, so that isn't the source of the problem.

    Taking another look at your wireshark logs, it seems like when the retransmissions occur the server running on the PC is reporting that its TCP window is 0, meaning that its receive buffer is full. From that, I suspect that the issue has to do with the server software you are using. Also possible is a process on your PC that performs some networking task every hour that momentarily loads your PC's network interface.

    If you use a different server setup, or use a tool such as iperf to test the TCP functionality, do you see the same errors?

    Regards,

    Michael