Limiting the number of times TCP can retransmit packets in Windows

Status
Not open for further replies.

g67575

g67575

g67575

Soldato
Joined
30 Jun 2019
Posts
8,130
There's a registry command that can do this, discussed here:
https://support.microsoft.com/en-us...time-out-7ae0982a-4963-fa7e-ee79-ff6d0da73db8

The default setting for 'TcpMaxDataRetransmissions' is 5 in Windows 10.

I set mine to 1 in the registry. This is a registry key that can be added here:
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

I've rerun a test here that checks for retransmissions and the amount of retransmissions is lower than before, with the amount varying between 0.4 and 0.6% on my FTTC line.

I found that with the default setting of 5, the amount of retransmission tended to vary anywhere between 0.5 to approximately 10%.

I can set the value to 0, which ends the test sooner during the upstream phase (so I know this command works). Wouldn't advise setting this to 0, but it does seem to lower the amount of TCP retransmissions (and probably just increases the discarded packets).

Mlab test here (there's now a London server):
https://speed.measurementlab.net/#/

Is lowering the number of retransmission attempts a bad idea?

I haven't noticed any interruptions in browsing or file downloads yet.
 
Last edited:
g67575 said:
Is lowering the number of retransmission attempts a bad idea?
Click to expand...

Yes, in almost any normal use case you should leave the Windows defaults alone.

Ignoring measurementlab, what is your actual problem? I assume you haven't a unique need to ensure that the tests on that specific website and that website alone work perfectly and are instead using it as a proxy to try to diagnose and solve an actual problem you are having.

So, what's the actual problem you are trying to solve? You've mentioned Google Stadia in some of your other posts, but I don't recall you describing the symptoms you are trying to aleviate.
 
It's just an experiment for now, I'm curious to see what affect this will have. It also potentially highlights a flaw in the test, that it seems to allow too many retransmissions (and therefore gives results that don't seem consistent or accurate between different runs).

I think there is still a problem on my FTTC line, the more upstream I allow to be used (via QOS), the higher the packet loss. Realistically, I've no idea if this is even something BT Openreach engineers could fix (perhaps 1% or less is normal for VDSL2 lines).

In terms of there being a problem, I think my line may be good enough (in terms of packet loss) to run Stadia on some of the time, but it's hard to say at this point (as the line is often congested anyway).
 
TCP overall you generally want potentially retransmitting a fair bit if necessary - UDP not so much but I don't think you can influence UDP behaviour in that respect. Unless you can tune it on an app by app basis it isn't really useful to change it.
 
Have you, in all of your numerous similar posts, ever told us what problems your claimed packet loss is causing you?

None of your proposed solutions, to what is probably a minor or nonexistent problem, have made much sense compared with leaving everything at default and letting DLM do its job.
 
This just doesn't make sense to me, you require retransmission for TCP to work as intended. E.G you get sent some packets, and then you acknowledge those packets.

Without retransmit you can break that chain, if you don't ack a set of packets then you'll probably get them retransmited by whatevers at the the other end. If your sending packets and don't get an ack back then you should be resending in order that your data is complete.

UDP is fire and forget and not really comparible in function to TCP.
 
Status
Not open for further replies.
Back
Top Bottom