Hello, following the low RAM recommendations I disabled ipconfigUSETCPWIN.

Now I get a few errors like ../FreeRTOS-Plus-TCP/FreeRTOS_TCP_IP.c:807:45: error: 'IPTCPSocket_t {aka struct TCPSOCKET}' has no member named 'ucMyWinScaleFactor' because there are unguarded occurences of pxSocket->u.xTCP.ucMyWinScaleFactor in lines 807, 2387, 2388, 2421. ucMyWinScaleFactor is not defined when ipconfigUSETCPWIN is disabled. Also there is an error in prvSetSynAckOptions, with the usage of ~~~ #if( ipconfigUSETCPWIN != 0 ) ... #else { uxOptionsLength = 4u; } #endif ~~~ which is defined as ~~~

UBaseType_t uxOptionsLength;

~~~

Also I think the different uses of ipconfigUSE_TCP_WIN == 1, ipconfigUSE_TCP_WIN == 0 and ipconfigUSE_TCP_WIN != 0 are a bit confusing.

As I do not fully understand TCP sliding windows and their implementation in FreeRTOS+TCP I'd like to ask for support to fix these bugs.

Regards, Michael

Hi Michael, we know about these compilation problems and a new release is in preparation. But that always takes more time than we hope for.

I'll attach the current version of FreeRTOSTCPIP.c It has been tested with ipconfigUSE_TCP_WIN == 0.

If there are any problems, please let it know.

A known problem with ipconfigUSE_TCP_WIN == 0 is slowness in case the devices sends TCP data. Acknowledgements from the host may be delayed for 200 ms.

Regards.

Here is the promised attachment: FreeRTOS_TCP_IP.c

Thanks Hein, that works!

I can also confirm the delay you mentioned. HTTP requests for 1kb files take 210ms with MTU 1500, 2kb need 620ms. Delay scales with decreasing MTU. Is there any plan to fix this?

Is there any plan to fix this?

Try google "naggle 200ms".

If you look with Wireshark, you will see that the host (Linux/Windows) is delaying its ACK, and we can't fix that :-) Normally the device would send a second packet and that one will be acknowledged without delay. When ipconfigUSE_TCP_WIN == 0, the device doesn't have this mechanism of sending-out a next packet.

What some users do is to sending out TCP data packets two times. These are packets carrying actual TCP data. If a host receives a packet a second time, it will be acknowledged immediately.

When performance matters, it is maybe better to use a small MTU along with ipconfigUSE_TCP_WIN == 1. I would choose an MTU of 552, which allows to send 512 bytes in each TCP packet. Make sure that the size of the DMA buffers depend on ipconfigNETWORK_MTU, normally ipconfigNETWORK_MTU + 36 (unless you're using small chained DMA buffers).

I attached a ZIP in which:

● double_send.c some sample code which sends-out every TCP data packet twice. Each second packet is acknowledged without a delay

● noslidingwindow.pcap A PCAP of the double-sending with ipconfigUSE_TCP_WIN = 0

● slidingwindow.pcap A PCAP when using a sliding TCP window `ipconfigUSETCP_WIN = 1`