Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


+ TCP uxNxWinSize

Posted by friesen on June 14, 2018

Could I get a bit an explanation on WinProperties_t Rx and Tx WinSize?

Coming from a different IP stack, I'm having a hard time following why this is specified in MSS.

For example, I have a socket that I want the rx buffer size at 1,048,576, or 1mb. This would translate to a window scale of 4 in tcp language. However, 1048576 / 1460 = 718, so I'm not following exactly how this number is being used, as the examples don't use numbers this high.

+ TCP uxNxWinSize

Posted by heinbali01 on June 14, 2018

A TCP conversation is parametrised by a few variables:

  • MSS, Maximum Segment Size, which is the size of the TCP payload. Often this is 1460 bytes long
  • TCP window sizes
  • TCP buffer sizes ( which is an internal thing )

When you communicate through a LAN, it does not make much sense to have a window size longer than 8 to 12 times MSS ( 11680 to 17520 bytes ).

Your question is why the TCP window size is defined as a multiple of MSS: the answer is efficiency. Suppose that there is a constant stream of data, and that the window size is 4 KB, then you will often see half-filled Ethernet packets. If the window size is 3 x MSS ( 4380 bytes ), than you will see that all packets are 100% filled.

Buffer sizes are expressed in bytes, so you have total freedom.

If you make a big TCP window like 1 MB, a scale factor will be used, and the window size will not be an exact multiple of MSS, due to rounding.

Why do you choose 1 MB? Do you expect a better performance compared to a size of e.g. 12 times MSS ?

+ TCP uxNxWinSize

Posted by friesen on June 15, 2018

My communication is not on a lan, it is a streaming audio device, and really needs to work without skips where internet isn't so great. A larger tcp window combined with other internal buffering really helps. Perhaps 1mb is overkill, but it has worked.

I think I follow now, so really window scaling happens depending on the WinSize. The microchip stack I have been using has it that the tcp buffer size is the same as the window size, thus this seemed confusing that the window size is smaller than the buffer size.

+ TCP uxNxWinSize

Posted by richard_damon on June 15, 2018

You don't need a TCP window as big as your buffering time. You could buffer a couple of seconds of video in your application, while the TCP layer uses a smaller window. This might actually improve performance as if an earlier packet was lost you want to re-request it before you actually need it, so you can have it (you don't need much more buffer than the round trip delay time). The additional application buffer smooths out the varying quality of the connection, No amount of buffering (except down load the whole stream then play it) will get you skipless streaming if the connection can't handle the needed rate, at least on average.

+ TCP uxNxWinSize

Posted by heinbali01 on June 15, 2018

The microchip stack ... the tcp buffer size is the same as the window size

That is probably where your confusion comes from. In +TCP, these parameters are separated.

Richard Damon is right: it is more advantageous to have a reasonable sized TCP window, and keep audio data buffered. It is up to you how much data must be in the buffer before you start the player. The FreeRTOS+TCP stack can buffer TCP data for you. You can poll how much data is available in the buffer with this function:

~~~ BaseTypet FreeRTOSrxsize( Sockett xSocket ); ~~~

My advice for your streaming client would be the following:

~~~ xWinProperties.lRxBufSize = 1024 * 1024; /* 1 MB, or more / xWinProperties.lRxWinSize = 12; / 12 packets / xWinProperties.lTxBufSize = 6 * 1024; / 6 KB / xWinProperties.lTxWinSize = 2; / 2 packets */ ~~~

You may want to wait until the RX buffer is filled 80% and start playing the sound.

If your Internet connection is not so good, the IP stack may decide to decrease the size of the advertised TCP window. Using a large TCP window may lead to a chaotic conversation with many retransmissions and Selective Acknowledgements ( SACK's ). If there are many dropped packets, a window size of 4 x MSS or less would be better.

+ TCP uxNxWinSize

Posted by heinbali01 on June 15, 2018

Have you tried the option ipconfigNIC_LINKSPEED_AUTODETECT? That worked for me, Zynq gets a 1 Gbps connection. I'll attach the latest +TCP driver for Zynq, just to make sure it will also work for you.


[ Back to the top ]    [ About FreeRTOS ]    [ Privacy ]    [ Sitemap ]    [ ]

Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS v10.2.1 is available for immediate download. MIT licensed, includes 64-bit RISC-V, NXP Cortex-M33 demo, Nuvoton Cortex-M23 demo & STM32H745 dual core (AMP) demo.

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


FreeRTOS and other embedded software careers at AWS.

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Cadence Tensilica Cortes

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers





STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner