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.

TCP packet timing problem

Hi,

I'm developing an application that requests files from a server over HTTP. The application opens a TCP socket, sends a GET request to the server, then reads in a loop until a remote close is detected. The application performs around 8 to 16 successful reads at a time, and then fails to read any data for about 250ms. This repeats until the download is complete. Using Wireshark, I determined that the 250ms delay is due to packet retransmissions.

The Wireshark trace above shows 14 successful packet transmissions of 1460 payload bytes, starting with the retransmission at frame 30 and ending with the ACK at frame 57. Channel 1 of the corresponding logic analyzer trace shows 14 ticks, with each tick representing a 1460 byte read in the application. According to the Wireshark trace, the server is sending packets at around 5ms to 9ms apart. The CC3000 responds with an ACK for each of these until the packet sent at frame 58, which is not ACK'ed. This causes a 300ms delay before retransmission. The logic analyzer trace shows that reads are occurring in the application at around 7ms to 16ms apart. Since packets are being ACK'ed 5ms to 9ms apart, this implies that the CC3000 is sending ACKs faster than the application is performing reads. I'm assuming that this is why the CC3000 is periodically dropping packets, leading to retransmission delays.

I have two questions:
- When does the CC3000 send an ACK -- after the module receives a packet, or after the application reads the payload via calls to recv? In this post, it's stated that the CC3000 will not send an ACK until the application pulls the data. According to my traces, however, that doesn't seem to be the case.
- Given that the CC3000's internal receive buffer is 1468 bytes, how am I not losing data? Looking at my traces, it seems inevitable that the CC3000 would fill its buffer faster than the application reads out of the buffer, leading to payload data being overwritten (or not written at all) before the application reads it. However, I've thankfully had no problem with the integrity of the downloaded file.

Any help would be appreciated. Thanks.

  • Could a TI employee please provide a response on this? We are experiencing horrible download speeds (max 30KBps on a LAN) when using the CC3000 as an HTTP client because of the above issue.

  • Hi.


    I think this might be because your not doing recv often enough causing all the CC3000's internal buffers to be filled up and thats why it stops ACKing until you've emptied some of it's buffers (with recv). This is to prevent loosing data.

    So you need to do your recv more often and/or faster.

    Kind regards

    Jimmy

  • Hi Derek,

    To answer your questions:

    1) CC3000 sends an ACK when the module receives the packet and not when the 'recv' is called from the application. And it does stops sending ACK when the internal memory is full and it waits for the application to 'recv' as soon as it can.

    2) The data does not get lost as long as it is with CC3000's buffers. Again, it will wait for the recv to be called. And once the buffers are free, the remote device (waiting to send un-ACKed packets) will proceed with retransmission and it will get an ACK.

    Thanks & Regards,
    Raghavendra