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.

CC3000 Dropping every 10th packet while recv TCP data

Other Parts Discussed in Thread: MSP430F5529

I've created a simple test to help me work through bandwidth issues.  I have a TCP server running on a windows box.  The CC3000 connects to the server and requests a file, the server sends a 250K byte file.  I test to see how fast this goes.

When I look in wireshark capture, the time between the windows box sending the data and the CC3000 ACK always has a 5ms delay!  Is that normal? I believe from what I've read, that this is a limitation of the CC3000.

Then like clockwork, every 10th packet is dropped, resulting in the server re-transmitting the packet after a 300ms delay in not receiving the ACK.  (This is where my real problem exists).  It is every 10 packets, repeating throughout the entire duration of the transfer.  This happens every time I run my test.  I even tried running the test to a different computer and got the exact same results.

Here is the wireshark capture of a transfer:

http://www.tjscreed.com/5ms_delay.pcapng

I'll post my client code below.  As you can see in my client code, I've set SOCKOPT_RECV_NONBLOCK on the socket so that the call does not block.  I've added a counter to ensure the code is really nonblocking.  I see nonblockcnt incremented about 100 times for each successful call to recv that returns bytes.

Why does the CC3000 drop every 10th packet?  Have I missed something somewhere?

    // Connect Socket
    ulClientSocket = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
    lerr = connect(ulClientSocket, &tSocketAddr, sizeof(tSocketAddr));

    if(lerr != ESUCCESS)
    {
        print("Error Connecting\r\n");
        return;
    }

    SentLen = send(ulClientSocket, req, strlen(req), 0);

    long optvalue_block = 0;
    if (setsockopt(ulClientSocket, SOL_SOCKET, SOCKOPT_RECV_NONBLOCK, &optvalue_block, sizeof(optvalue_block)) != 0)
    {
        print("Error setting RECV_NONBLOCK\r\n");
    }

    do
    {
            iBytesReceived = recv(ulClientSocket, rxbuf, RX_BUFFER_SIZE, 0);
            if (iBytesReceived > 0)
            {
                cnt+=iBytesReceived;
            } else {

                nonblockcnt++;

            }

    } while (cnt != totalbytes);

  • Any ideas here?

    I've looked closer at this issue and it seems as if those packets are being dropped in the CC3000.  There is no indication a packet has arrived until the resend 300 ms later.

    My CC3000 is patched to the latest patch 1.11, reading back nvmem_read_sp_version confirms it is at 1.19 as it should be.

    I'm interfaced to a MSP430F5529 dev card.

    Any ideas would be appreciated.

  • I was hoping to get a response on this?

    I've spent countless hours trying different things.  I've tried three different access points.  No change.  I've looked at wireshark and numerous times.  Every 10th packet is dropped.  It is dropped inside the cc3000 chip, I'm positive.  My code is constantly pulling for arrival of data and the buffer is empty.  I've taken the WIFI example and modified it with the above simplistic change.  How do I go about getting a response here?

  • Troy,

    I took a look at your wireshark logs. It appears that your frames are upwards of 1500 bytes in size.

    Please keep in mind that the maximum RX size is 1468 bytes, and the CC3000 does not support fragmentation. I would recommend changing the MTU of your server to something below 1468 bytes.

    Thanks,

     Keegan

     

  • Hi Keegan,

    Thanks for the looking at my files.

    Yes, I understand that I was pushing the maximum packet size.  The data was all being received, albeit slowly, because of the issue of every 10th packet being dropped.

    I went back and tried changing the packet size to 400, just to ensure that nothing crazy was going on.

    My results are the same.

    Any other ideas? 

  • Hi Troy

    As far as I understand you are only using one socket to transfer data. Can you rewritte your code to use all availabe sockets (up to 4) to transmit data? Because in my understanding there are for each socket seperate buffers in the CC3000 and therefore the Throughtput should increase with each socket added.

  • With a TCP connection, multiple sockets won't help.  I can't download a file any faster.  With separate sockets I could download 4 files at the same time, but you can't use multiple sockets to download the same file.

    This appears to be a design flaw with the CC3000 chip.  The chip is dropping the TCP packet.  It is nothing I'm doing on my side.  The chip is not sending the ACK even though the packet is arriving.  I have code that I can share with anyone that would like to reproduce the problem.