Ask Your Question

TCP Retransmission - Delay with Windows 10!

asked 2019-04-20 13:40:31 +0000

ramprasad1211 gravatar image

updated 2019-04-20 17:40:39 +0000

grahamb gravatar image

Hi, During our testing, I noticed when using Windows-10 - we observe less throughput. But when we use lInux - we see more throughput. But we intend to use Windows-10 only for this test.

When I analyzed the logs, below is my analysis so far:

Windows-10:, let's call Windows Peer : , let's call peer.

traffic direction : Windows (iperf Client) to Peer (iperf server)

  1. Windows sends TCP Seq-x to Peer
  2. Peer sends a TCP ACK - x-1460 bytes .
  3. Windows waits for ~100ms to ~200ms before re-transmitting the packet - which as seq-x.

Looks like TCP retransmission timeout is configured to be very large value: may be around 200ms? Is there a way I can change this to lower value? Yes, I'm running on a network - where some packet loss is expected.


edit retag flag offensive close merge delete


I'm not sure I understand your example correctly, it's a little too abstract. If it's just a iperf test why not share the PCAP file so we can take a look at what's really happening?

As far as your example goes I read it like "a packet is sent, it's acknowledged, it's resend again after 200ms" - which makes no sense. Why resend if the sender knows that it's packet got through fine? Also, iperf is a synthetic test so without seeing the pcap it's hard to say what it tries to do.

Jasper gravatar imageJasper ( 2019-04-21 10:09:33 +0000 )edit

If I understand it correctly the author says TCP ACK has (x-1460) set therefore it ACKs 1 packet before last (I could be wrong here, because it's not 100% clear). If it's the case, 200ms timeout value is pretty typical for Windows as well as any other OS.

Packet_vlad gravatar imagePacket_vlad ( 2019-04-22 06:18:23 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2019-04-22 08:29:26 +0000

updated 2019-04-22 11:24:51 +0000

As I have understood your reading right, the packet x got lost and was resend after around 200ms. Assuming this is an Retransmssion of time (RTO). I would not recommend to play around with this timer. Unless your are facing an issue where your normal RTT is around 200 ms, because then you might like to have a higher RTO.

But in your case I really would not recommend to deal with this value, because in most cases when you face an RTO it has mostly an impact to the session performance. Furthermore in most cases you won't face an RTO because the Fast Retransmission is send before an RTO.

So that you face an issue here with RTO seems to be related to the way how IPERF works and in normal operation you won't face the issue with RTO.(Without a trace it is hard to explain)

BTW: When you have this issue in your LAN then I recommend to find out, why the packets gets lost. This seems the root issue.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2019-04-20 13:40:31 +0000

Seen: 91 times

Last updated: Apr 22