Cinterion TC65’s TCP stack limits

WARNING: All the Cinterion related content from this blog will be removed to go to the javacint wiki soon. Please get used to going there.

If you use the TC65 to transmit some frequent (with a transmission interval of less than 700 ms) data, you should know that the TC65’s has a poor TCP implementation considering the ACK management of sent messages.

When the TC65 sends a TCP packet, it waits for an ACK packet before sending any other packet. It means that if you have a delay 400 ms between the TC65 and your server (which is very quite common), the TC65 will wait for 800 ms (400 ms for the data packet from the TC65 to the server and 400 ms for the ACK packet to return) before sending any data.

I discovered it because I wanted to send real-time GPS tracking data, and at a rate of 20 positions per second it was way above the minimal delay of 800ms. My positions came by packet of 5 to 20.

I asked for help to the french Cinterion’s support with complete description of the problem, “AT^SCFG” complete view and some libpcap network captures. And they couldn’t give me any real solution to this problem.

I think this is a chosen restriction. The chip has a memory of 400 Kb, to send a packet before waiting the acknowledge of the previous packet, it would have to use a more complex TCP stack and to consume some RAM to store all the packets left to acknowledge. I might be wrong, there might be a way to activate this, but right now Cinterion isn’t able give me any answer.

The only solution I found is to send data from the TC65 using UDP and to receive data using TCP. And receiving in real-time (I mean short time) DOES work perfectly with the chip (no need for increasing the receive buffer). You just have to disable Nagle’s algorithm (TCP_NODELAY=TRUE) on the remote host (most probably the TCP server).

Leave a Reply

Your email address will not be published. Required fields are marked *