TCP windowing delayed transaction

glenenglish wrote on Tuesday, April 03, 2018:

So I have found a quirk I think in my configuration, or the code, in the TCP /TCP server in freeRTOS TCP (V 160909). … Has there been much done since then on +TCP in 180222 ?

I’m asking this question here because I am not very familiar with the internals of the Windowing-TCP side of FreeRTOS networking. it mostly works, I never go to go looking.

The problem occurs about 1 time in 5… but there is a deterministic failure time… read on.

What happens is, when the web browser requests several files at the same time, (while file transfers of other files are in progress) , the TCP server seems to forget for a short time that it needs to respond to one of the requests. I will work on this today , and am posting in case others have seen it…

So, for example if a GIF gets missed, it loads later. The browser doesnt ask for it again- the TCP stack in FreeRTOS+TCP just seems to remember it needs to process this exactly 19.85 seconds later for 333 ticks/second. No matter how many server sockers are available ,2,4,8 12…

Must be something to do with timeouts and timers on sockets that I have not yet dived in to understand.

This only happens when windowing is enabled. It does NOT occur if windowing is disabled. (but everything is very slow of course on high latency connections because each MSS gets an ACK.

I have the wireshark capture on my disk if anyone is interested.

First index.htm is requesting @ 4.274643 sec.

while index.htm is loading , the browser requests jasmos455.gif @ 4.288856 seconds

and then the file livereaddn.json is regularly requested (and regularly served correctly) . It is requested every 2 seconds or so, (live update of the page) …

EVENTUALLY (exactly 19.85 seconds after the request every time…) jasmos455.gif is provided…the webserver begins to serve at 24.1292 sec

and is fullfilled at @24.151486 sec

any ideas ?

In the TCP config, it is not clear from the doco what the ratios of sizes between various buffers must be, a few more asserts I think required in there.

TCP config is :
#define ipconfigNETWORK_MTU 1264

//#define ipconfigTCP_MSS        ( ipconfigNETWORK_MTU - ipSIZE_OF_IP_HEADER - ipSIZE_OF_TCP_HEADER )
#define ipconfigTCP_MSS        ( 576 - ipSIZE_OF_IP_HEADER - ipSIZE_OF_TCP_HEADER )

#define ipconfigTCP_RX_BUFFER_LENGTH            ( 4u * ipconfigTCP_MSS )
#define ipconfigTCP_TX_BUFFER_LENGTH            ( 4u * ipconfigTCP_MSS )

/* Buffer and window sizes used by the FTP and HTTP servers respectively.  The
FTP and HTTP servers both execute in the standard server task. */
#define ipconfigFTP_TX_BUFSIZE                (4 * ipconfigTCP_MSS )
#define ipconfigFTP_TX_WINSIZE                ( 2 )
#define ipconfigFTP_RX_BUFSIZE                ( 4 * ipconfigTCP_MSS )
#define ipconfigFTP_RX_WINSIZE                ( 2 )

#define ipconfigHTTP_TX_BUFSIZE                ( 4 * ipconfigTCP_MSS )
#define ipconfigHTTP_TX_WINSIZE                ( 2 )
#define ipconfigHTTP_RX_BUFSIZE                ( 4 * ipconfigTCP_MSS )
#define ipconfigHTTP_RX_WINSIZE                ( 2 )



heinbali01 wrote on Tuesday, April 03, 2018:

Hi Glen, thanks for reporting this. I have contacted you directly and we will report on this forum as soon as we’ve found a solution.

heinbali01 wrote on Friday, April 06, 2018:

Hi Glen, we found the guilty one in your FreeRTOSIPConfig.h:

#define    ipconfigTCP_WIN_SEG_COUNT  ( 4 )

This defines the maximum number of outstanding TX and RX TCP packets (segments). There is one pool of buffers shared by all TCP sockets.
Your socket was temporarily not able to allocate such a segment buffer. Only after a 20-second time-out it would check again and send the file.

glenenglish wrote on Saturday, April 07, 2018:

Hi Hein’
Yes, I thought that was segment count for EACH connection.

But it is the segment count for ALL connections.

Indeed. I think the documentation on this one probably needs some revision.