Vista Connection Problems
When Microsoft did a Launch party for Windows Vista on Second Life, the impact of the event was somewhat stifled because many new Vista users found they could no longer connect to Second Life.
A similar problem has been reported with the most basic of all internet communications mediums - telnet.
In all likelihood both problems - and their solutions - are tied to 'Receive Window Autotuning'.
Microsoft's Technet describes this as follows:
"The TCP Receive Window size is the amount of bytes that a receiving host allows a sending host to send at one time on a TCP connection. To correctly determine the value of the optimum TCP Receive Window size for a connection based on the current conditions of the network, the Next-Generation TCP/IP stack supports TCP Receive Window Auto-Tuning. TCP Receive Window Auto-Tuning continually determines the optimal TCP Receive Window size on a per-connection basis by measuring the bandwidth-delay product (the bandwidth multiplied by the latency of the connection) and the application retrieve rate, and automatically adjusts the maximum TCP Receive Window size on an ongoing basis. With better throughput between TCP peers, the utilization of network bandwidth increases during data transfer. The overall utilization of the network will be better optimized, making the use of Quality of Service (QoS) more important for networks that are operating at or near capacity. For more information, see the "Policy-based Quality of Service" section of this document."
It turns out that the network utilization becomes extremely well optimized, because traffic drops to 0, since the #$^&^* thing doesn't work right most of the time.
This is another example of Microsoft turning on something by default that was previously (i.e. in XP) turned off by default. To solve this problem, proceed as follows:
1) Run CMD as an administrator
2) At the command line type: netsh int tcp set global autotuninglevel=disable
That's it you're done. Have a nice day.
A similar problem has been reported with the most basic of all internet communications mediums - telnet.
In all likelihood both problems - and their solutions - are tied to 'Receive Window Autotuning'.
Microsoft's Technet describes this as follows:
"The TCP Receive Window size is the amount of bytes that a receiving host allows a sending host to send at one time on a TCP connection. To correctly determine the value of the optimum TCP Receive Window size for a connection based on the current conditions of the network, the Next-Generation TCP/IP stack supports TCP Receive Window Auto-Tuning. TCP Receive Window Auto-Tuning continually determines the optimal TCP Receive Window size on a per-connection basis by measuring the bandwidth-delay product (the bandwidth multiplied by the latency of the connection) and the application retrieve rate, and automatically adjusts the maximum TCP Receive Window size on an ongoing basis. With better throughput between TCP peers, the utilization of network bandwidth increases during data transfer. The overall utilization of the network will be better optimized, making the use of Quality of Service (QoS) more important for networks that are operating at or near capacity. For more information, see the "Policy-based Quality of Service" section of this document."
It turns out that the network utilization becomes extremely well optimized, because traffic drops to 0, since the #$^&^* thing doesn't work right most of the time.
This is another example of Microsoft turning on something by default that was previously (i.e. in XP) turned off by default. To solve this problem, proceed as follows:
1) Run CMD as an administrator
2) At the command line type: netsh int tcp set global autotuninglevel=disable
That's it you're done. Have a nice day.
posted by Vaughan Wynne-Jones | 12:18 PM
0 Comments:
Post a Comment
<< Home