Brian's Rant-o-Rama - provided free of charge provided you free me from charges

November 13^th, 2007

Windows Vista headaches part 1

I wanna talk about Windows Vista.

Let's start with the obvious, since I'm pretty sure I have a good grasp of that: Vista is sexy and attractive. It has an "ooh ... aah ..." factor that is undeniably why the people who like it ... er, like it. Computer geeks of the world should always remember that: Sex sells (including great-looking sexy UI). And, in case you are wondering, that statement is definitely directed right around in a 180-degree U-turn at myself: I forget this lesson in life frequently.

It often irritates me to realise that I am many times wrong about "what people like" simply because I like things that most other people don't. I foolishly have an expectation that the rest of the world will see through the glitz and glitter as quickly as I do, and reject something on its functional grounds. But right now the UI designers at Microsoft are making fools of people like me and building their empire (v.6.0) in the process. Oh, and it would do me very well to remember that fact, and subsequently leave the populist crap to the populist minds: I may be outside the polis, but I'm not leading any charges. (Fringe is not always the next mainstream.)

Where was I? Oh yes, Vista:

Networking (or, rather net-not-working)

My first troubles came when I started wirelessly networking Windows Vista with two Windows 2000 machines, and a Windows XP (SP2) machine. It wasn't just that there were communication errors, the whole damned network stopped working! The 2000 boxes stopped talking to each other, and the XP machine clammed up too. Even when I repeatedly reset the wireless router (hard reset = unplugging the box and plugging it back in) I got only a very slow trickle of dataflow for a few minutes, then everything ground to a halt.

Why? Well, one culprit was a part of the new TCP stack called AutoTuning. So what does it do? Well, let's start by looking at the pieces:

RWIN: There is this thing called the Receive Window (RWIN) which is just a fancy name for the maximum number of bytes your computer can receive before it acknowledges the transmission. So the sender sends the RWIN number of bytes then waits for some signal back. If it doesn't get an acknowledgement, it tries again. (And again. And again.) And it won't send the second packet of data until it gets acknowledgement of the first. And so on and so on ...

In theory (and maybe in practice too), adjusting the RWIN could improve network throughput if there are long delays between acknowledgements but fast connection speeds (e.g., new gigabit networking technologies). Windows users since at least Windows 98 days have been tuning and tweaking their TCPReceiveWindow registry values trying to find this networking sweet spot.

But with Windows Vista comes this new feature AutoTuning, which does it automatically and dynamically. This little piece of fuzzzy logic adjusts RWIN sizes for each individual connection, looking for better throughput. So it changes the packet size up or down a bit, monitors that for a while, then makes some sort of guess about the best size, then tries again. OK, just hold that in memory for a while.

MTU: There is also a limit on the size of packets for the whole network connection known as the Maximum Transmission Unit (MTU). It determines size of the biggest packet of data. Anything larger must get broken up into multiple packets. So a packet of data up to the size of MTU is sent, then the network device that sent it sits and waits for acknowledgement before sending the next packet.

Network MTU settings can be retrieved from the router. There is a full rich API available for developers of drivers and other software to retrieve the MTU and adjust local system settings accordingly. (This is because MTU values can change, depending on the networking device you are connected to.)

Like TCPReceiveWindow, there is a registry setting, MTU that users have traditionally fiddled with to try and increase their neworking speeds. OK, hold that in memory too.

SMB: Messages sent by Windows when sharing files and devices must comply with a certain format known as the Server Message Block (SMB) format. In fact, all of NetBIOS is based on the SMB format. So when sharing files or printers or folders or whatever, Windows talks to other Windows machines (or any other machines for that matter, e.g. Samba) using the SMB message format.

The problem: So think about this: AutoTuning is busy mucking with RWIN values, looking for efficient throughput, when, through its adjustments, the SMB size grows larger than the MTU size. Suddenly, the Windows box that is sharing the file or printer (or whatever) is sitting waiting for an acknowledgement for the SMB it just sent. But the SMB never finished being sent because the MTU size is smaller. No acknowledgement, no throughput.

And that is what was happening with my router. Its MTU size was fine when communications started, but as soon as AutoTuning started working its ...er... magic on my network, the router's MTU size (which cannot change because it is an older router—yes, it is possible to blame my router for the troubles) prevented one complete SMB from being sent and acknowledged. So it sat waiting forever, and even the other machines on the network were being held in queue while something happened with the connection to the Vista machine.

I don't know a lot about these things, really, but I do know that you can get the reported MTU size from each individual device. I don't know what layer takes care of it, but the driver code would know. So why, if you know the max MTU size already, would you keep mucking around with it? (Or perhaps this "feature" was paid for by router manufacturers everywhere who would now like you to go out and buy their new high-falutin routers with dynamic MTU sizes?)

Anyhow, there is nothing wrong with my router except its age, so I had to turn off AutoTuning. There was no GUI for this! I had to fire up a command prompt and enter this command line command:
netsh interface tcp set global autotuning=disabled
Let me add two things here:

First, if this does deleterious things to your network, you can turn it back on with this command:
netsh interface tcp set global autotuning=normal
Second, neither of these commands work unless you open the command prompt as an administrator. (From the Start Menu, right click the Command Prompt item, then click Open as Administrator.)

So once I turned off AutoTuning, things got a bit better. But they weren't perfect either. My networking was still elephantine slow. I'll talk some more about it tomorrow.

Read more rants - - Comment on this rant - Email me