Uh, why ? Based on the explanation of it from Mark Russinovich, fixing it should be fairly easy. A static limit that should be variable and a minor implementation bug that doesn't deal well with multiple interfaces.
After all, if they could, why ship with the reduced performance in the first place [...]
Because the impact zone is tiny. The vast majority of Vista users would never - will never - notice the problem. It well and truly falls into the "known but acceptable bug, fix it later" category.
[...] - remember, the network performance reduction was put on place intentionally as a hack to get around other flaws.
This is not an ordinary bug, as in wrong implmentation in code / hardware of a technically sound architecture.
In fact, that's *exactly* what it is. An implementation that produces less than ideal results in certain circumstances because of incorrect/bad assumptions.
How is that *not* a textbook example of a bug ?
The network stack in Vista uses 40% CPU time for simple file transfers - up from 15% in XP and 9% in Linux.
What ?
This proves that the design deision to rewrite the BSD-stack was a flawed approach, and not a BUG
Windows NT hasn't had a "BSD-stack" since NT 3.x.
Secondly, it is not necessary to probe the audio hardware and software 30 times a second, as is done in Vista. That overload on system resources is again not a bug, it is DEFECTIVE BY DESIGN.
What overload on system resources ? What evidence is there the system resources are being overloaded ? A poor understanding on your behalf of what the MMCSS is doing, does not equal "an overload on system resources".
Unless Microsoft can demonstrate superior performance with Vista on identical hardware, users will conclude that DRM is such a burden on resources, and avoid using Vista as long as they practically can. This isn't FUD, it's FACT.
The fact is that "DRM load" is irrelevant to current systems, largely because little (if any) media is actually DRM-encumbered and secondly because any machine capable of playing media that will be DRM-encumbered has a significant surplus of hardware resources.
He didn't cover multi-user advantages. In Windows for example, switch user logs me out and dumps my download so someone else can jump on and do a quick check of email. On Ubuntu, switch user leaves everything running while someone else can log in and check their email. My download, DVD rip, raytrace render, or video transcode job continues to run while they are logged in checking their email.
This is incorrect. "Switch user" in Windows XP leaves inactive users' processes running.
In other words Vista will display HD images but only in un-DRM mode, and if you try to pay a movie that you have bought and paid for but which has the flag set for 'trusted output path' or whatever they call it, Vista will refuse to display it.
Indeed. Just like every other player on the market will refuse to play it (or degrade the output).
Which is, I think, the point Peter Gutmann was trying to make.
Gutmann is disingenuously blaming Vista for this problem, when it is in fact the content providers who are responsible.
Vista plays HD video *fine*. Whether or not it is *allowed* to output that HD video on your particular hardware combination, is an something you need to take up with the people who sold you that content.
You may be referring to the MMCSS discovery recently. I call that moot.
I am referring to the OP's claim "as opposed to the unnecessary DRM-checking delays for all I/O in Vista?". You appear to be the one referring to the MMCSS.
The same media plays on Linux with trivially little CPU time dedicated to it. The fact that it requires so much CPU time that Windows has to fudge process priority far enough to impact network performance says to me that SOMETHING other than just playback is going on, and until it is proven otherwise I am willing to assume that DRM is the culprit. Playing a common MP3 should not eat 80%+ of my CPU.
No-one is saying it should (or does). Clearly you don't understand what the MMCSS is doing and have instead leapt upon the "zOMG !!11!! Vista and DRM !!eleventy!!1" Slashdot bandwagon.
(I should point out here, to avoid a pointless off-topic discussion, that I think the implementation outlined in Russinovich's blog was fairly short-sighted and needs to be fixed. However, this is an entirely separate issue to the baseless, ignorant FUD I am replying to.)
I do not believe there is any DRM checking involved when I am doing video or audio output on my linux desktop pc.
Yes. Exactly my point. Just like Vista.
(Unless, of course, you have some DRM-encumbered media).
Nothing is getting in the way of drive->cpu->gpu->screen, unlike Vista where even thinking about playing copyrighted audio can cut network performance by 90%.
I still find it an amusing shame that people are so willing to accept the huge performance penalties of anti-virus and now anti-spyware/adware for their utterly broken OS.
AV software isn't protectng your from problems in the OS, it's protecting you from problems in the user.
No amount of OS security can stop the user from deliberately doing something stupid - nor should it.
Do you think anybody can run Microsoft Vista on a PC from 2001?
At *least* as well as OS X will run on an old Mac (better, IME with OSX on a G4-anything vs Vista on comparably priced and upgraded PC hardware - but _certainly_ no worse).
The only people upgrading PCs "every 6 months" are hardcore gamers with more money than sense. If all you want to do is browse the web, send emails, etc, then a modestly upgraded high-end ca. 2001-2003 PC will be more than adequate, even running Vista. It's certainly the equivalent of what I use at home for most of my non-gaming PC use (running Vista).
The "hardware resources" argument against Vista has zero credibility.
I was always one of the "early adopters" in the OS space before the release of Vista. I tried it on a brand new computer (bought specifically to run Vista), hated it, removed it and ran back to XP Pro like to an old lover (who used to abuse me a bit, TBH). Vista is so bad that it may have actually transformed me from someone who used to love getting the latest OS to someone who just wants to run his programs, thank you very much.
Why ?
Most important, Vista is not only so bad, but it's so NOT what I want in an OS.
Maybe my setup is different. Preemptive kernel, 1000 Hz, CFS IO scheduler. So I'm not sure how a load average of 2 or 4 can disturb the Linux kernel at all.
Because "load average" in and of itself is a nearly meaningless number for comparing performance. Without knowing anything else about what's going on, a load average of <some number> tells you nothing about how "utilised" the system actually is.
Err...only slightly. Unix based operating systems separate user space from the rest of the system. Nothing much can be done without root access.
Pretty much everything malware might want to do, it can do without elevated privileges.
Installing Malware on a Unix system is, for this reason virtually impossible.
It's as simple as convincing an end user to execute a program with elevated privileges. Which is only marginally more difficult than convincing them to run a program at all. Which isn't particularly difficult.
MA large user base is often used as a rationalization for windows malware, but in reality it is just an incorrect excuse.
It's not an "excuse", it's an inescapable aspect of the "malware problem".
RAID6. Then a while after that, "RAID7" (or whatever they call triple-parity).
In ca. 4-5 years[0], the combination of big drives (2TB+) and raw read error rates (roughly once every 12TB or so) will mean that during a rebuild of 6+ disk RAID5 arrays after a single drive failure, a second "drive failure" (probably just a single bad sector, but the end result is basically the same) will be - statistically speaking - pretty much guaranteed. RAID5 will be obselete because it won't protect you from array failures (because every single-disk failure will become a double-disk failure). RAID6 will only give you the same protection as RAID5 today (because you will be vulnerable to a third drive failing during the rebuild in addition to the second) and "RAID7" will be needed to protect you from "triple disk failures".
On a more positive note, with current error rates, RAID10 should last until ca. 10TB drives before SATA array elements have to be "triple mirrored" (although this is far enough down the track that I expect the basic assumptions here to have changed). "Enterprise" hardware also has (much) longer to go, because the read error rate is better and drives typically (much) smaller.
(Even today, IMHO, anyone using drives bigger than 250G in 6+ disk arrays without either RAID6 or RAID10 is crazy.)
[0]This is actually being pretty generous. It's certain we'll see 2TB drives well before then, but I'm taking a timeframe where they will be "common" rather than "high end".
I never understood why the iPod became so immensely popular compared to other personal players in the first place. It locks you down to using iTunes, makes it difficult to use multiple machines or move music around, doesn't have particularly high sound quality, and doesn't support a lot of music formats.
Because most people don't want to do any of those things. They want to:
* Rip CDs
* Use existing MP3s
* Copy them onto a device
* Listen to it while they're jogging/commuting/riding through earbuds (ie: sound quality is not a high priority).
The iPod did these things and did them in a very clean, very simple, very easy to use way.
If ever there was an example of HCI being one of the most important aspects of technology with regards to uptake, the iPod is it.
Not gonna happen. The problem is that ECC memory costs more, simply because there is 12.5% more memory. Most people are going to go for as cheap as possible.
It'll happen for the same reason RAID5 on certain types of arrays will be obselete in 4 - 5 years. Eventually memory sizes are going to get so big that the statistical probability of a memory error will effectively guarantee they happen too frequently to ignore.
AMD was also selling 64 bit desktop CPUs and Windows XP 64-bit was not available for some time. Home users were not likely to be running Windows Server 2003, thus the GP's post I'm sure.
I doubt it, more likely he was referring to the x64 version of Windows 2003 lagging a couple of years behind (which I'd forgotten).
For the vast majority of XP users, 64 bit had pretty much zero benefit (and quite a few disadvantages) until maybe a year - 18 months tops - ago.
That's great, except x64-native versions of Microsoft Windows Server 2003 and Windows XP were not released until 2005. Until then, Windows Server 2003 was available only in 32-bit x86 and Itanium-compatible flavours.
Well, keep in mind that 32-bit OSs should be able to use Intel's PAE to address 64 GB of memory. The memory space usable by one process would still be limited to 4 GB (minus OS stuff, so 2 or 3 GB on Windows), but it would put off the wall by a couple more years, as one of the reasons you want more memory is to run more processes, not to give individual processes more space.
Not really. Most people only "run" a single program at once and some _games_ are already getting close to bumping into the 2GB process limit in Windows.
Of course, even Vista doesn't support PAE and is so limited to 4 GB physical memory. I personally find this mind boggling, and wouldn't be surprised if either they change that in a service pack release or it comes back to bite them.
It doesn't for the same reason XP doesn't - compatibility and reliability. *LOTS* of low-end consumer hardware (and/or drivers) breaks on systems running in PAE mode.
Linux kind of carried the Opteron for the first year or so, since it had 64-bit and NUMA support, while M$ obligingly waited to release any such thing until Intel had an offering as well.
Opteron released: April 22, 2003.
Windows 2003 released: April 24, 2003.
Slashdot Mirror
I find it highly unlikely that they can fix this.
Uh, why ? Based on the explanation of it from Mark Russinovich, fixing it should be fairly easy. A static limit that should be variable and a minor implementation bug that doesn't deal well with multiple interfaces.
After all, if they could, why ship with the reduced performance in the first place [...]
Because the impact zone is tiny. The vast majority of Vista users would never - will never - notice the problem. It well and truly falls into the "known but acceptable bug, fix it later" category.
[...] - remember, the network performance reduction was put on place intentionally as a hack to get around other flaws.
What flaws ?
This is not an ordinary bug, as in wrong implmentation in code / hardware of a technically sound architecture.
In fact, that's *exactly* what it is. An implementation that produces less than ideal results in certain circumstances because of incorrect/bad assumptions.
How is that *not* a textbook example of a bug ?
The network stack in Vista uses 40% CPU time for simple file transfers - up from 15% in XP and 9% in Linux.
What ?
This proves that the design deision to rewrite the BSD-stack was a flawed approach, and not a BUG
Windows NT hasn't had a "BSD-stack" since NT 3.x.
Secondly, it is not necessary to probe the audio hardware and software 30 times a second, as is done in Vista. That overload on system resources is again not a bug, it is DEFECTIVE BY DESIGN .
What overload on system resources ? What evidence is there the system resources are being overloaded ? A poor understanding on your behalf of what the MMCSS is doing, does not equal "an overload on system resources".
Unless Microsoft can demonstrate superior performance with Vista on identical hardware, users will conclude that DRM is such a burden on resources, and avoid using Vista as long as they practically can. This isn't FUD, it's FACT.
The fact is that "DRM load" is irrelevant to current systems, largely because little (if any) media is actually DRM-encumbered and secondly because any machine capable of playing media that will be DRM-encumbered has a significant surplus of hardware resources.
He didn't cover multi-user advantages. In Windows for example, switch user logs me out and dumps my download so someone else can jump on and do a quick check of email. On Ubuntu, switch user leaves everything running while someone else can log in and check their email. My download, DVD rip, raytrace render, or video transcode job continues to run while they are logged in checking their email.
This is incorrect. "Switch user" in Windows XP leaves inactive users' processes running.
Of course the "play audio and don't expect your gigabit card to work fast" easily disproves his whole counterargument.
How so ? It has nothing to do with DRM.
In other words Vista will display HD images but only in un-DRM mode, and if you try to pay a movie that you have bought and paid for but which has the flag set for 'trusted output path' or whatever they call it, Vista will refuse to display it.
Indeed. Just like every other player on the market will refuse to play it (or degrade the output).
Which is, I think, the point Peter Gutmann was trying to make.
Gutmann is disingenuously blaming Vista for this problem, when it is in fact the content providers who are responsible.
Vista plays HD video *fine*. Whether or not it is *allowed* to output that HD video on your particular hardware combination, is an something you need to take up with the people who sold you that content.
People bought the 486SX.
Uh, why wouldn't they have if they'd known (assuming they didn't - many probably did, back then) that it was often a 486DX with a disabled FPU ?
You may be referring to the MMCSS discovery recently. I call that moot.
I am referring to the OP's claim "as opposed to the unnecessary DRM-checking delays for all I/O in Vista?". You appear to be the one referring to the MMCSS.
The same media plays on Linux with trivially little CPU time dedicated to it. The fact that it requires so much CPU time that Windows has to fudge process priority far enough to impact network performance says to me that SOMETHING other than just playback is going on, and until it is proven otherwise I am willing to assume that DRM is the culprit. Playing a common MP3 should not eat 80%+ of my CPU.
No-one is saying it should (or does). Clearly you don't understand what the MMCSS is doing and have instead leapt upon the "zOMG !!11!! Vista and DRM !!eleventy!!1" Slashdot bandwagon.
(I should point out here, to avoid a pointless off-topic discussion, that I think the implementation outlined in Russinovich's blog was fairly short-sighted and needs to be fixed. However, this is an entirely separate issue to the baseless, ignorant FUD I am replying to.)
I do not believe there is any DRM checking involved when I am doing video or audio output on my linux desktop pc.
Yes. Exactly my point. Just like Vista.
(Unless, of course, you have some DRM-encumbered media).
Nothing is getting in the way of drive->cpu->gpu->screen, unlike Vista where even thinking about playing copyrighted audio can cut network performance by 90%.
False.
I still find it an amusing shame that people are so willing to accept the huge performance penalties of anti-virus and now anti-spyware/adware for their utterly broken OS.
AV software isn't protectng your from problems in the OS, it's protecting you from problems in the user.
No amount of OS security can stop the user from deliberately doing something stupid - nor should it.
Do you think anybody can run Microsoft Vista on a PC from 2001?
At *least* as well as OS X will run on an old Mac (better, IME with OSX on a G4-anything vs Vista on comparably priced and upgraded PC hardware - but _certainly_ no worse).
The only people upgrading PCs "every 6 months" are hardcore gamers with more money than sense. If all you want to do is browse the web, send emails, etc, then a modestly upgraded high-end ca. 2001-2003 PC will be more than adequate, even running Vista. It's certainly the equivalent of what I use at home for most of my non-gaming PC use (running Vista).
The "hardware resources" argument against Vista has zero credibility.
Except neither of those operating systems have the same level of difficulty with high performance network bandwidth and playing multimedia files.
The relevance to "DRM-checking delays for all I/O in Vista" being...?
And now ask yourself, who of us had chosen Windows?? Right, nobody. It's the thing which came preinstalled.
I did - and I an not in any way, shape or form unfamiliar with the alternatives.
I was always one of the "early adopters" in the OS space before the release of Vista. I tried it on a brand new computer (bought specifically to run Vista), hated it, removed it and ran back to XP Pro like to an old lover (who used to abuse me a bit, TBH). Vista is so bad that it may have actually transformed me from someone who used to love getting the latest OS to someone who just wants to run his programs, thank you very much.
Why ?
Most important, Vista is not only so bad, but it's so NOT what I want in an OS.
How so ?
As opposed to the unnecessary DRM-checking delays for all I/O in Vista?
Just like in Linux and OS X, you mean ?
Maybe my setup is different. Preemptive kernel, 1000 Hz, CFS IO scheduler. So I'm not sure how a load average of 2 or 4 can disturb the Linux kernel at all.
Because "load average" in and of itself is a nearly meaningless number for comparing performance. Without knowing anything else about what's going on, a load average of <some number> tells you nothing about how "utilised" the system actually is.
Err...only slightly. Unix based operating systems separate user space from the rest of the system. Nothing much can be done without root access.
Pretty much everything malware might want to do, it can do without elevated privileges.
Installing Malware on a Unix system is, for this reason virtually impossible.
It's as simple as convincing an end user to execute a program with elevated privileges. Which is only marginally more difficult than convincing them to run a program at all. Which isn't particularly difficult.
MA large user base is often used as a rationalization for windows malware, but in reality it is just an incorrect excuse.
It's not an "excuse", it's an inescapable aspect of the "malware problem".
Obsolete? What would you replace it with then?
RAID6. Then a while after that, "RAID7" (or whatever they call triple-parity).
In ca. 4-5 years[0], the combination of big drives (2TB+) and raw read error rates (roughly once every 12TB or so) will mean that during a rebuild of 6+ disk RAID5 arrays after a single drive failure, a second "drive failure" (probably just a single bad sector, but the end result is basically the same) will be - statistically speaking - pretty much guaranteed. RAID5 will be obselete because it won't protect you from array failures (because every single-disk failure will become a double-disk failure). RAID6 will only give you the same protection as RAID5 today (because you will be vulnerable to a third drive failing during the rebuild in addition to the second) and "RAID7" will be needed to protect you from "triple disk failures".
On a more positive note, with current error rates, RAID10 should last until ca. 10TB drives before SATA array elements have to be "triple mirrored" (although this is far enough down the track that I expect the basic assumptions here to have changed). "Enterprise" hardware also has (much) longer to go, because the read error rate is better and drives typically (much) smaller.
(Even today, IMHO, anyone using drives bigger than 250G in 6+ disk arrays without either RAID6 or RAID10 is crazy.)
[0]This is actually being pretty generous. It's certain we'll see 2TB drives well before then, but I'm taking a timeframe where they will be "common" rather than "high end".
You see, comments like yours are meaningless to a lot of us. What do you mean by 'form'?? It just doesn't grok.
"Form" is why you might prefer to implement a given piece of software in $YOUR_FAVOURITE_LANGUAGE instead of $SOME_OTHER_LANGUAGE.
Alternatively, substitute "aesthetics" for "form".
I never understood why the iPod became so immensely popular compared to other personal players in the first place. It locks you down to using iTunes, makes it difficult to use multiple machines or move music around, doesn't have particularly high sound quality, and doesn't support a lot of music formats.
Because most people don't want to do any of those things. They want to:
* Rip CDs
* Use existing MP3s
* Copy them onto a device
* Listen to it while they're jogging/commuting/riding through earbuds (ie: sound quality is not a high priority).
The iPod did these things and did them in a very clean, very simple, very easy to use way.
If ever there was an example of HCI being one of the most important aspects of technology with regards to uptake, the iPod is it.
Not gonna happen. The problem is that ECC memory costs more, simply because there is 12.5% more memory. Most people are going to go for as cheap as possible.
It'll happen for the same reason RAID5 on certain types of arrays will be obselete in 4 - 5 years. Eventually memory sizes are going to get so big that the statistical probability of a memory error will effectively guarantee they happen too frequently to ignore.
A meter is defined as the distance light travels in a vacuum in 1/299,792,458th of a second.
True, but it's still *based* on the dimensions of Earth - "retconning" it into somewhat more universal units won't change that ;).
AMD was also selling 64 bit desktop CPUs and Windows XP 64-bit was not available for some time. Home users were not likely to be running Windows Server 2003, thus the GP's post I'm sure.
I doubt it, more likely he was referring to the x64 version of Windows 2003 lagging a couple of years behind (which I'd forgotten).
For the vast majority of XP users, 64 bit had pretty much zero benefit (and quite a few disadvantages) until maybe a year - 18 months tops - ago.
That's great, except x64-native versions of Microsoft Windows Server 2003 and Windows XP were not released until 2005. Until then, Windows Server 2003 was available only in 32-bit x86 and Itanium-compatible flavours.
Good point. I'd forgotten about that.
Apologies to the GGP, my bad.
Well, keep in mind that 32-bit OSs should be able to use Intel's PAE to address 64 GB of memory. The memory space usable by one process would still be limited to 4 GB (minus OS stuff, so 2 or 3 GB on Windows), but it would put off the wall by a couple more years, as one of the reasons you want more memory is to run more processes, not to give individual processes more space.
Not really. Most people only "run" a single program at once and some _games_ are already getting close to bumping into the 2GB process limit in Windows.
Of course, even Vista doesn't support PAE and is so limited to 4 GB physical memory. I personally find this mind boggling, and wouldn't be surprised if either they change that in a service pack release or it comes back to bite them.
It doesn't for the same reason XP doesn't - compatibility and reliability. *LOTS* of low-end consumer hardware (and/or drivers) breaks on systems running in PAE mode.
Linux kind of carried the Opteron for the first year or so, since it had 64-bit and NUMA support, while M$ obligingly waited to release any such thing until Intel had an offering as well.
Opteron released: April 22, 2003.
Windows 2003 released: April 24, 2003.
2 days != a "year or so".