I did a quick read of RFC6298 about the RTO (retransmission timeout) and SRTT. Note that when the ‘SRTT’ timer is large, and there is no retransmission, it is seen clearly that Windows 10 is TCP/IP ACKing after 200ms.
This keeps on forever, with each ‘live’ message. Windows 10 TCP/IP ACKs the message, but nothing happens with the internal ‘SRTT’ timer. The embedded device sends the ‘live’ message. Next time a ‘live’ message is send same behavior happens. Note: we don’t want to change this default value.īecause the ‘SRTT’ timer is only 70ms, FreeRTOS+TCP retransmits the ‘live’ message.Ī new ‘SRTT’ isn’t calculated because it is a retransmission? (line 1917 FreeRTOS_TCP_WIN.c). This because of the default delayed TCP/IP ACK of 200ms in Windows 10.
The embedded device sends the ‘live’ message, however, Windows 10 is TCP/IP ACKing this ‘live’ message after 200ms. The ‘SRTT’ gets a value of about 70ms.Īfter exchanging a lot of data there are only ‘live’ messages. However, in my case this ‘SRTT’ is calculated and tuned when both parties are exchanging a lot of data at startup. I found out that the ‘SRTT’ is calculated in FreeRTOS_TCP_WIN.c and used to detect if a retransmission is needed. My problem is that this ‘live’ message is retransmitted each time by FreeRTOS+TCP. This propriety protocol supports application data and, if there is no application data, a propriety ‘live’ message is send each 30 seconds to detect the device is correctly running. The embedded device is the client, the Windows 10 PC the server. The embedded device communicates with an application on a Windows 10 PC.Ĭommunication is done with a propriety protocol running on TCP/IP. We have an embedded device, running FreeRTOS with FreeRTOS+TCP.
0 kommentar(er)
