Hi I am developing software for an embedded device, running on a TI DSP. For test purposes I can communicate to this device over a TCP connection from a Windows 7 PC. So I have a Windows 7 PC connected to the device using a private subnet (crossover cable). When I send a small message to the DSP from Windows (200 octets), I see that Windows performs a retransmission at about 900ms after the initial transmission. Using netsh I can see that Windows 'Initial RTO' is set to 3000ms. So I don't understand why Windows is retransmitting at 900ms. Please can anyone explain why the retransmission is happening so early? (I could paste in the TCP flow captured by Wireshark in text form, but it doesn't display well. Is there a good way of doing this?) Best regards David asked 30 Apr '15, 06:16  DavidA_2015 |
2 Answers:
My guess is that this is because of the Push flag being set - this may be a reason why the Win7 PC is impatient and disregards RTO, but I haven't found anything more specific. answered 30 Apr '15, 07:15  Jasper ♦♦ Thanks for your comments. I wonder if the initial timeout is affected by the RTT value, which I believe is 300ms for Windows? (30 Apr '15, 08:42) DavidA_2015 |
3000 ms (3 seconds) is the initial receive time out timer value. However, the TCP stack will tune the RTO value during the communication and it should eventually end up being about twice the round-trip time, although RFC 6298 states that if the calculated RTO is less than one second, than an RTO value of one second should be used. There is no reason to wait three full seconds before retransmitting a packet under normal network conditions. answered 30 Apr '15, 10:17  Jim Aragon There is a hotfix out there that allows to reduce the minRTO value in Window: http://support.microsoft.com/kb/2472264 (30 Apr '15, 12:44) mrEEde |
Upload the capture to http://www.cloudshark.org and paste the link here.
Here is the capture:
https://www.cloudshark.org/captures/f660d96bdc85