the APPLICATION is
・Tera Term
・IO Libraries Suite (Keysight )
・TCP/IP Test tool (free software)
I’ve tried 3 different types, but the results are the same.
Sometimes the [TCP] window size becomes “4106”, but there is no change in behavior.
I was reviewing the TCP options for SYN-ACK, but I was concerned that the Window scale was set to 0.
Should I change this number?
And how should I change it?
Hi @S.FUKAYA
Were you able to move forward, I tried a simple echo server demo and i can see PSH is setup from application {Which makes sense because the application does not want to wait for buffer to be full before sending the data ) whereas when sending back the same data from TCP stack the PSH flag is not set. So i doubt the flag is set by FreeRTOS.
Can you please help in sharing more details of your project.
What are the buffer and window sizes that are used by the socket.
Are you using sliding window protocol i.e. ipconfigUSE_TCP_WIN is set to 1?
You can also use FREERTOS_SO_WIN_PROPERTIES to set it’s buffer properties
You can check the configuration example here - TCP/IP stack configuration examples for RTOS applications
Which hardware are you using for TCP communication. It would be great if you can share your project to check it further
Hi @moninom1
thanks for confirming!!
I’m so happy I could cry(´;ω;｀)
I will answer the question.
This source mimicked the sample.I don’t know what value is good.
ipconfigUSE_TCP_WIN is set to 1.
My device is Renesas “R7FA6M2AF3CFB”
The integrated development environment is also Renesas’ “e2 studio”
Thank you!!
It would be great if you can share your project, i would like to take a look.
Also in our FreeRTOS+TCP we are setting PSH flag at only this loop - https://github.com/FreeRTOS/FreeRTOS-Plus-TCP/blob/main/source/FreeRTOS_TCP_Transmission.c#L1132
Can you please add some logs here and check if in your case the flag is being enabled by TCP stack, otherwise we can conclude that the flag is being set by the application side.
Also if you are trying to achieve communication like echo server/client, you can try using Hercules SETUP utility which can work as both client and server to make sure one side of the communication is stable.
sorry for the late reply.
share my project.Please check.
Please change the IP address, gateway, etc. appropriately
BACKUP.zip (3.1 MB)
Commercially available devices add [PSH] only to the last data when sending data of 1460 bytes or more, but my device adds [PSH] to all data.
And some non-commercial IP-stacks do so as well 
As FreeRTOS+TCP was written for platforms with limited resources (RAM, flash), some features have been simplified, like setting the PSH flag. The flag will be set in every packet that contains outgoing data.
At the receiving side, it means that every packet can be passed immediately to the application, a call to recv() will unblock and return data.
You’re saying that the peer is replying with an ACK “too early”. That is up to the peer, and I don’t think it is much related to the PSH flag. When the sender is fast enough, and the peer’s WIN is big enough, the peer won’t see a reason to send ACK’s in between.
When I send a file from a fast CPU (running +TCP) to my laptop, it is possible that +TCP has 12 outstanding packets before receiving an ACK.
RAc wrote:
This may be related to the peer’s advertised small window size (513).
Yes indeed, when the peer has a lot of RX buffer space, it will also send less ACK’s in-between.
If you like, you can run iperf3 and see maximum possible speed. Please download:
iperf_config.h
iperf_task_v3_0f.c
‘iperf_config.h’ shows an example of configuring iperf3.
the logging will tell how to start up iper3 at the Window’s side, e.g. :
iperf3 -c 192.168.101.100 --port 5001 --bytes 100M -R
Or, if that is too complex, you can post a PACP file of any TCP conversation in which loads of data are being sent. I will analyse it.