After takin' a swig o' grog, Roy Schestowitz belched out this bit o' wisdom:
> [Vista scheduler is broken]
>
> ,----[ Quote ]
> | Critical optimizations such as zero-copy aside, there is no excusable reason
> | why processing IP packets should so damagingly affect the system.
> | resulting bugs in the implementation demonstrate.
> `----
>
> http://blogbeebe.blogspot.com/2007/08/robert-love-backs-up-my-very-simple.html
"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."
I like this little comment:
Has microsoft improved since Bill let go of the reins? Whoa! lets not
open THAT can of worms.
Robert Love's blog is even more incredible, in that he quotes a
well-known Windows internals guy, Mark Russinovitch. The following is
just a paraphrase, though:
Mark goes on to show that copying a file from one machine to another
consumes a staggering 41% of the available processor. In Joey's
words, that is horrid and just an awful situation.
I've seen this one for myself, a lot:
Unlike DPCs, however, the Linux parallel does not consume nearly half
of your CPU. In fact, in repeated tests involving both "copying a
large file from another system" and a simple unabated ping flood, I
was unable to consume any tangible amount of processor.
Not that that's really proof of anything, because I've also seen that
bad javascript in firefox can make the CPU run ragged (40% to 100%),
affects are normally noticeable only when compiling some code.
Anyway, Microsoft has its priorities right:
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.
Which priority is that, you ask?
"How many boxes will it sell?"
--
Tux rox!
|
|
