Wisedigs

Check out the new page added.

I try to find logical arguments for both sides of a story. Sometimes I find myself in no man’s land because at times that is best. Other times I find myself partial to one side. Then as time goes on that changes to being heavily biased or the complete opposite.

The story of Apple. Truly a company that has done wonders. Not in it’s technological advances, certainly many before have accomplished something very similar, but in it’s tactics in increasing market share and hijacking customers and building a huge fan-base. No one even comes close to the strides Apple has made there. Their strategy wasn’t very complex at all:

• give the users something nice to look at
• give the users choices, but not too many choices
• give the users freedom, but not too much freedom
• give the users belief that they have the best, then release something better

Few can blame Apple for this. How many companies have this much control over so many people? None. When you are in a position like this, what do you do? You milk it for all it’s worth. As a smart business man you realize that what goes up must come down. In Apple’s position you want to make enemies. Enemies unwittingly produce allies. Not any sort of allies. The sort of strong, strongly opinionated ones that believe they have their own reasons for their decisions, unlike the others.

Ethically speaking, you can argue Apple’s tactics are disgusting. Things like purposely disabling features to await a future release of a product. Or handicapping older hardware to highlight advantages of owning the latest model. Or cutting corners during the manufacturing process to maximize profits. Or have the confidence that you can charge customers whatever you desire, knowing that they will buy in regardless.

How many people would buy the exact same laptop twice, or three times? What if you were to release a laptop without video output or a DVD drive, and then release one later on that has video output, then one yet again with both? Given enough time, the dedicated consumers will eventually buy all three.

Eventually users will catch on. How long will it take? Who knows. People can’t be stupid forever.. or can they.

If you are looking for a solution, head to the end of this article.

With the coming of Vista Microsoft decided it was time for them to rewrite the networking layer in the Windows operating system. Like it or not, what networking started out as being in the days of Windows 3.11 has changed drastically. Unfortunately, the new implementation is not perfect and that is easily justifiable.

Rather than explore the boring details we will jump to those that are responsible for millions of gray hair strands all over the IT world. The first being Receive Window Auto-Tuning. In previous versions of Windows, the TCP Receive Window (RWIN) was a constant you set it once and live with it regardless of your connection speed fluctuations. Now you are asking, what the heck is RWIN? In one sentence, it is the amount of packet data that can be transmitted to the receiver without waiting for acknowledgment. If you aren’t familiar with TCP, every packet sent must be acknowledged by the receiver. As packets are acknowledged they are removed from the receive window and new packets are loaded and transmitted.

An example to explain RWIN and its impact on bandwidth: Imagine the receiver is far away and I need to send him a 1000KB file. Let’s say RWIN is 10KB, and I, being the sender, can transmit 10KB in 10ms. It takes the receiver 20ms to receive 10KB. I initiate the sending and it takes me 10ms to saturate the receive window. Now I am waiting for the receiver to acknowledge. Total time spent by the sender waiting is 30ms! And the process repeats until the entire file is transmitted. We can improve this it seems. Let us set RWIN to 30KB. Now it takes me 30ms to transmit 30KB. By the time I have sent the last packet, I am receiving acknowledgments for the first packets. I can continue transmitting constantly without delay until I am done!

The above example illustrates the importance of an appropriately configured RWIN. In an ideal world, the PC should keep track of multiple RWIN values. This is because every network is loaded differently, with varying capabilities and latencies. A proper networking implementation should keep track of all the paths it has been to and keep track of the ideal RWIN values for each. Of course this solution is not ideal (given infinite resources, the impossible becomes possible) and we have to resort to a single possible value for RWIN at any given time.

Windows XP’s implementation of RWIN was quite primitive. With Vista and 7, Microsoft have introduced an auto-tuning layer for optimizing RWIN based on delay and transmission quality and probably 100,000 other variables. The good? Terrific for large high-latency WANs and local area networks. The bad? There is a “setting period” for autotuning. Beyond this setting period it remains somewhat permanent, until something drastically changes or traffic increases to one particular destination. This leads to strange behaviour at times, with data transmitting very quickly and poorly. To explain this one needs to examine the network packets with autotuning enabled/disabled (this is explained later).

Open up a command shell (Start > Run > cmd or Windows Key+R > cmd) and let’s take a look at your TCP settings:

C:\>netsh int tcp show global

netsh is the network shell, it contains almost every network setting one can imagine. The parameter we are interested in is “Receive Window Auto-Tuning Level”. It is probably set to “normal”. You can experiment with four possible values:

• normal
• highlyrestricted
• experimental
• disabled

To set it to one of the above values:

C:\>netsh int tcp set global autotuning=disabled

Check the globals again to make sure it has set. If you see a message at the bottom with something about heuristics it means the value is being overridden. To disable heuristics:

C:\>netsh int tcp set global heuristics=disabled

Upon modifying any TCP settings, a restart is required.

So when does this setting really matter? For the average user, it is probably just fine as it is. But if you use your PC as a server this might impact you significantly. The best way to determine what is best for your computer is to test systematically. And to really see autotuning at work, get a copy of Wireshark (PortableApp version recommended) and monitor those packets. Ideally you want to test local transfers and WAN transfers with access to both sender and receiver.

Everything in this article also applies to Windows Server 2008 and 2008 R2.