FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [March 2017 Threads] disable ipconfigUSE_TCP_WIN compilation errorsPosted by miclam on March 23, 2017 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
~~~
if ipconfigUSETCPWIN == 1
UBaseType_t uxOptionsLength;
endif
~~~
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
disable ipconfigUSE_TCP_WIN compilation errorsPosted by heinbali01 on March 23, 2017 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.
disable ipconfigUSE_TCP_WIN compilation errorsPosted by heinbali01 on March 23, 2017 Here is the promised attachment: FreeRTOS_TCP_IP.c
disable ipconfigUSE_TCP_WIN compilation errorsPosted by miclam on March 23, 2017 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?
disable ipconfigUSE_TCP_WIN compilation errorsPosted by heinbali01 on March 24, 2017
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`
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|