DerrickBoyd
asked on
Windows XP registry settings to decrease packet loss
I have set the following in my registry
TcpMaxConnectRetransmissio
TcpMaxDataRetransmissions to 1000000
DefaultTTL to 128
With these settings I would expect my computer to never lose a packet. If a packet can't get through I would expect my computer to lock up rather than time out a packet. Despite this I still see packet loss when using "ping www.telus.net -n 100"
I have also tried
TcpMaxConnectRetransmissio
TcpMaxDataRetransmissions to 1
DefaultTTL to 128
Performance does not appear to be any different than the above settings. (Yes, the computer was rebooted between changes)
I am editing these settings in HKEY_LOCAL_MACHINE.SYSTEM.
If I change DefaultTTL to 1 my internet connection dies (All packets take more than 1 ms so all packets time out). This suggests to me that I am editing the registry correctly and that my changes are being picket up and used. So why are the Retransmission settings being ignored? Any other registry settings that would help decrease packet loss?
Note: the packet loss is due to the wireless signal running about 50 KM before it gets to the nearest land line. Packet loss is normally 3% but can be as high as 8%. The ISP considers this acceptable. I'm having trouble finding an alternet ISP in my area. In this question I would like to focus specificaly on what the windows registry can do for me. I have posted a seperate question with more general details looking for alternative ways to solve this problem.
TcpMaxConnectRetransmissio
TcpMaxDataRetransmissions to 1000000
DefaultTTL to 128
With these settings I would expect my computer to never lose a packet. If a packet can't get through I would expect my computer to lock up rather than time out a packet. Despite this I still see packet loss when using "ping www.telus.net -n 100"
I have also tried
TcpMaxConnectRetransmissio
TcpMaxDataRetransmissions to 1
DefaultTTL to 128
Performance does not appear to be any different than the above settings. (Yes, the computer was rebooted between changes)
I am editing these settings in HKEY_LOCAL_MACHINE.SYSTEM.
If I change DefaultTTL to 1 my internet connection dies (All packets take more than 1 ms so all packets time out). This suggests to me that I am editing the registry correctly and that my changes are being picket up and used. So why are the Retransmission settings being ignored? Any other registry settings that would help decrease packet loss?
Note: the packet loss is due to the wireless signal running about 50 KM before it gets to the nearest land line. Packet loss is normally 3% but can be as high as 8%. The ISP considers this acceptable. I'm having trouble finding an alternet ISP in my area. In this question I would like to focus specificaly on what the windows registry can do for me. I have posted a seperate question with more general details looking for alternative ways to solve this problem.
ASKER
Isn't the retry management done by the tcp protocal? Ok, yes, there should be retransmission/fault tolerance built into the microwave transmitter (At least I would have thought so) but if there is it doesn't seem to be good enough. I just ran over to a neighbours house that uses the same ISP and did a 100 test pings on their computer. 4% packet loss. So it's not faulty equipment at my house that causes it.
But that brings me back to... isn't TCP guarenteed packet delivery? If the packet is lost TCP should re-send it.
Since the TCP retry protocol is based on an end to end connection I'm not sure system settings along the path would impact it. The packet could be discarded along the path, but unless the final destination acknowledges the packet the source system is responsible for resending it. You make a good point when you say "Due to settings on the other end". I foolishly overlooked this. I can muck with my settings all I want and I can probably guarentee that the packets I send out will arrive at the destination... but the data that comes back will be on a different TCP session controlled by the computer at the other end. So with registry settings I can guarentee out bound data, but not inbound data.
I assume this also explains how ping can register packets being lost even though I've told it to do a million retrys. The data is being lost on the inbound traffic. Quick reality check though: assuming the channel interferance is approximatly the same in both directions then with default settings I should expect half the packets to be lost on inbound and half on outbound. So by setting the retrys to a large number it should effectivly eliminate outbound loss and reduce the total packet loss by half. But this doesn't fit with the observation of no change between setting the retrys to 1 or 1 million. Indeed, setting the retrys to 1 should have INCREASED the packet loss as this is lower than the default.
Possible conclusions could be:
1) The sample size was not large enough to show the random packet loss being reduced by half.
2) All packet loss on the channel is on the inbound connection.
3) Windows is not using the retry settings I am asking it to.
1) Try measuring again with larger samples
2) High packet loss in one direction could be very possible in this case. The receiver on the tower is likely much higher quality than the one mounted on my house. Alternativly this could point to a damaged transmitter on the tower. I should be able to prove if the packet loss is all on one side of the transmission by pinging inbound from an external system. With default settings the packet loss would be the same. With high retry set on the external system the packet loss should drop to near zero.
3) Windows ignoring my settings... I'm not sure how I can prove this, but if I eliminate the other two options that would be a strong indication for this option.
I'm located in Alberta (Canada)
But that brings me back to... isn't TCP guarenteed packet delivery? If the packet is lost TCP should re-send it.
Since the TCP retry protocol is based on an end to end connection I'm not sure system settings along the path would impact it. The packet could be discarded along the path, but unless the final destination acknowledges the packet the source system is responsible for resending it. You make a good point when you say "Due to settings on the other end". I foolishly overlooked this. I can muck with my settings all I want and I can probably guarentee that the packets I send out will arrive at the destination... but the data that comes back will be on a different TCP session controlled by the computer at the other end. So with registry settings I can guarentee out bound data, but not inbound data.
I assume this also explains how ping can register packets being lost even though I've told it to do a million retrys. The data is being lost on the inbound traffic. Quick reality check though: assuming the channel interferance is approximatly the same in both directions then with default settings I should expect half the packets to be lost on inbound and half on outbound. So by setting the retrys to a large number it should effectivly eliminate outbound loss and reduce the total packet loss by half. But this doesn't fit with the observation of no change between setting the retrys to 1 or 1 million. Indeed, setting the retrys to 1 should have INCREASED the packet loss as this is lower than the default.
Possible conclusions could be:
1) The sample size was not large enough to show the random packet loss being reduced by half.
2) All packet loss on the channel is on the inbound connection.
3) Windows is not using the retry settings I am asking it to.
1) Try measuring again with larger samples
2) High packet loss in one direction could be very possible in this case. The receiver on the tower is likely much higher quality than the one mounted on my house. Alternativly this could point to a damaged transmitter on the tower. I should be able to prove if the packet loss is all on one side of the transmission by pinging inbound from an external system. With default settings the packet loss would be the same. With high retry set on the external system the packet loss should drop to near zero.
3) Windows ignoring my settings... I'm not sure how I can prove this, but if I eliminate the other two options that would be a strong indication for this option.
I'm located in Alberta (Canada)
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
According to the link you send TcpMaxDataRetransmissions valid range is "0 - 0xFFFFFFFF", so I am still within the valid range specification.
Another quote from the site: "Too large a value could ensure that a connection attempt will never time out". Which is exactly my point. I have deliberatly set an abnormally high value and yet still see timeouts.
I've noticed that there are quite a few sites that deal with the problem of a long slow connection. Unfortunatly I have a slightly different problem. I have a REALLY fast connection that is lossy. IE: 400 kps bandwidth, 15 ms pings (very cool), 3-8% packet loss (vey not cool)
I am also aware of the timeout doubling on the retransmits, which is why I said I was expecting my computer to lock up rather than drop a packet. That prompted me to determine that I had messed up and was not correctly setting TcpMaxDataRetransmissions or that another setting was over riding my setting.
Could be mkdonohue has it right in suggesting the return packets are picking up the settings from the computer on the other end.
Another quote from the site: "Too large a value could ensure that a connection attempt will never time out". Which is exactly my point. I have deliberatly set an abnormally high value and yet still see timeouts.
I've noticed that there are quite a few sites that deal with the problem of a long slow connection. Unfortunatly I have a slightly different problem. I have a REALLY fast connection that is lossy. IE: 400 kps bandwidth, 15 ms pings (very cool), 3-8% packet loss (vey not cool)
I am also aware of the timeout doubling on the retransmits, which is why I said I was expecting my computer to lock up rather than drop a packet. That prompted me to determine that I had messed up and was not correctly setting TcpMaxDataRetransmissions or that another setting was over riding my setting.
Could be mkdonohue has it right in suggesting the return packets are picking up the settings from the computer on the other end.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Interesting, I have never used that command before. Hmm, isn't Reset Connects Very high?
--------------------------
C:\Documents and Settings\Derrick>netstat -s -p tcp
TCP Statistics for IPv4
Active Opens = 2151
Passive Opens = 6
Failed Connection Attempts = 44
Reset Connections = 853
Current Connections = 1
Segments Received = 85154
Segments Sent = 75574
Segments Retransmitted = 3270
--------------------------
C:\Documents and Settings\Derrick>netstat -s -p tcp
TCP Statistics for IPv4
Active Opens = 2151
Passive Opens = 6
Failed Connection Attempts = 44
Reset Connections = 853
Current Connections = 1
Segments Received = 85154
Segments Sent = 75574
Segments Retransmitted = 3270
ASKER
Ok mkdonohue, I think you just hinted at the answer to my question. I was making TCP configuration changes and attempting to measure the impact of the change using ping. But ping uses icmp/ip, not tcp/ip so I saw no performance impact no matter what setting changes I made. I proved to myself that I was editing the correct place in the registry because I did see impact when I changed DefaultTTL. I'm guessing this is an IP parameter so was measurable using ping's icmp/ip.
Using a web browser I can see the impact of these confguration changes and have been able to tune my system for better web browsing.
Thanx!
Using a web browser I can see the impact of these confguration changes and have been able to tune my system for better web browsing.
Thanx!
Sorry I didn't get back to you sooner. I had a car wreck and haven't been back online until today. (I'm ok, car will be fixed, my nerves are back in one piece.)
You've hit the proverbial nail on the head. I'm glad we got you where you needed to be. :)
You've hit the proverbial nail on the head. I'm glad we got you where you needed to be. :)
Where are you located? Perhaps an Expert can suggest an ISP for you.