Robert Love backs up my very simple performance experiment

It didn't take long for a member of the Linux kernel developer community to provide a more proper analysis of what I was able to observe on my own; that the Linux kernel, and Linux in general, is just so much superior to Vista when it comes to multimedia and network processing.

Robert Love, in a blog posting of his own, deconstructs the Vista networking problem by showing how to do it right, via the Linux kernel. Robert nailed it when he said:

Critical optimizations such as zero-copy aside, there is no excusable reason why processing IP packets should so damagingly affect the system. Thus, this absolutely abysmal networking performance should be an issue in and of itself. Unfortunately, however, the Windows developers decided to focus on a secondary effect:

Tests of [Multimedia Class Scheduler Service (MMCSS), a mechanism for the automatic priority-enhancement of multimedia playback,] during Vista development showed that, even with thread-priority boosting, heavy network traffic can cause enough long-running DPCs to prevent playback threads from keeping up with their media streaming requirements, resulting in glitching.

In other words, consuming half of your processor is (surprise!) detrimental to multimedia playback performance. At this point, it becomes clear that the process scheduler folks and the networking folks are bitter enemies and do not converse. Consequently, the obvious solution of fixing the abhorrent networking performance was bypassed for a quick bandaid:

MMCSS’ glitch-resistant mechanisms were therefore extended to include throttling of network activity. It does so by issuing a command to the NDIS device driver, which is the driver that gives packets received by network adapter drivers to the TCP/IP driver, that causes NDIS to “indicate”, or pass along, at most 10 packets per millisecond (10,000 packets per second).

Putting aside the larger problem for the moment, there are several issues with this solution. It prioritizes multimedia playback over networking performance, which, as the resulting clamor has shown, is not everyone's personal policy preference. It is almost assuredly a layering violation. It picks a fixed and hard-coded packet limit (ten per millisecond), which won't scale across different hardware—think significantly faster processors or substantially slower networking drivers. It ignores the commonality of GigE. And, finally, the solution is complicated, as the convoluted description and resulting bugs in the implementation demonstrate.

What I find so amazing about this entire episode is it exposes to the world how Microsoft's software development process works (not very well) and how they are going to add insult to injury by padding the band-aid rather than fixing the root cause of this problem; a poorly designed and/or implemented network stack.

If you'll recall, Microsoft announced during Vista's development that they were completely rewriting their network stack for Vista and later versions of Windows. The re-wrote it because they admitted that the then-current stack used in Windows NT up to XP was convoluted, complicated, and a hack. They chose to start over and redesign everything they needed, and then to reimplement the clean design. The goal was a networking subsystem that would have better security and (dare I say it) better performance. While the jury is still out on security, I think judgement has been passed on performance, and it's a big fat thumbs down.

As Robert says at the end of his piece, if you must wait for Vista then there are indeed viable alternatives to Vista while you wait for Microsoft to finally finish Vista. And who knows; you may find you like Linux so much it won't matter if Vista is every finished.