Sometimes the expectations of our customers mystify me.
One of the senior developers at Microsoft recently complained that the audio quality on his machine (running Windows Server 2008) was poor.
To me, it’s not surprising. Server SKUs are tuned for high performance in server scenarios, they’re not configured for desktop scenarios. That’s the entire POINT of having a server SKU – one of the major differences between server SKUs and client SKUs is that the client SKUs are tuned to balance the OS in favor of foreground responsiveness and the server SKUs are tuned in favor of background responsiveness (after all, its a server, there’s usually nobody sitting at the console, so there’s no point in optimizing for the console).
In this particular case, the documentation for the MMCSS service describes a large part of the root cause for the problem: The MMCSS service (which is the service that provides glitch resilient services for Windows multimedia applications) is essentially disabled on server SKUs. It’s just one of probably hundreds of other settings that are tweaked in favor of server responsiveness on server SKUs.
Apparently we’ve got a bunch of support requests coming in from customers who are running server SKUs on their desktop and are upset that audio quality is poor. And this mystifies me. It’s a server operating system – if you want client operating system performance, use a client operating system.
PS: To change the MMCSS tuning options, you should follow the suggestions from the MSDN article I linked to above:
The MMCSS settings are stored in the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile This key contains a REG_DWORD value named SystemResponsiveness that determines the percentage of CPU resources that should be guaranteed to low-priority tasks. For example, if this value is 20, then 20% of CPU resources are reserved for low-priority tasks. Note that values that are not evenly divisible by 10 are rounded up to the nearest multiple of 10. A value of 0 is also treated as 10.
The MMCSS settings are stored in the following registry key:
This key contains a REG_DWORD value named SystemResponsiveness that determines the percentage of CPU resources that should be guaranteed to low-priority tasks. For example, if this value is 20, then 20% of CPU resources are reserved for low-priority tasks. Note that values that are not evenly divisible by 10 are rounded up to the nearest multiple of 10. A value of 0 is also treated as 10.
For Vista, this value is set to 20, for Server 2008 the value is set to 100 (which disables MMCSS).
"How about a small business that uses a server to play audio for on hold music or perhaps for the overhead speakers?"
That sounds like a job for a different server SKU, like the Home Server. Whether Home Server is tuned that way, though, is unknown to me; if I had to wager money, I'd put it on MS not having a "personality" for that particular use case (IIRC they at one point had a bunch of names of "users" on a wall to represent different customer archetypes and thus SKUs; please correct me if I'm wrong) and assume the scenario would be a server SKU paired with a Media Center.
That being said, it should be possible to tune Server2008 to function in this manner, right? That would be more suprising to me than it not working that way out of the box.
Where to begin?
- remote desktop in client SKUs is neutered
- software RAID in client SKUs is neutered
- virtualization in client SKUs is neutered
- web development in client SKUs is neutered
- default start menu / quick launch icons / cmd.exe settings / explorer views / etc in client SKUs are annoying
Fix that stuff first, then we can talk.
Richard: That doesn't answer my question. My question was "Why do people think server SKUs should be tuned like client SKUs" not "why do people use server SKUs".
There are lots of reasons for people to use server SKUs on their desktop. But they shouldn't expect that their OS is anything other than a repurposed server OS. In fact all of the "is neutered" you listed above are aspects of servers and not client OSs.
Why do people think server SKUs should be tuned like client SKUs ?
Because they assume that a machine that is able to run Win Server 2008, with (most likely) multiple 2GHz+ cores should have enough horsepower to play an audio file ? Maybe because they remember that they were able to play audio on their 300 MHz Celeron back in 1998 ? But I guess those people have unrealistic expectations, those fools. Because in 2009, playing audio is so difficult and demanding that it only works on a special client-tuned OS that devotes so many billions of cycles per second to audio that it has to slow down its network throughput to handle the monumental task of playing Burt Bacharach.
Instead of the numerious nonsense Vista SKUs, Microsoft should provide a _real_ high-end 'Workstation' SKU for professional users.
And what about the Hypervisor concept? is it really a server-only story? IMHO no, not in the long-term.
ncgloy: People also forget about how really fragile their audio experience was on that 300MHz Celeron box. In 1998 there was only one app that could play audio on the system at a time (the mixer functionality was added in WIn98). And if anyone did anything that vaguely stresed the CPU or disk, audio glitched like crazy.
In fact, the server SKU degredation that you get is basically similar to what you had back in 1998, except that because we have the MMSS, the audio engine has been tuned to be more responsive to applications (it runs on a 10ms cadence not a 50ms cadence).
Under what situations does this setting matter? Is it only when the CPU is under heavy (100%) load?
Jon: When MMCSS is disabled, the audio stack runs a priority 15 thread. If anything on the system runs at a higher priority for more than 10ms at a time, it can and will preempt the audio stack.
Unfortunately there's a lot of stuff on the system that will run at higher than priority 15.
So it's not when it's under heavy load, it's when high priority stuff runs.
Actually, the people are complaining there's too many places to tweak and there isn't any centralized information on what to tweak on the web.
I think if there's some kind of centralized "Performance tweaks" applet in Control Panel, people won't complain that much... (Actually, I think people would still complain such panel should merge with "Power Management" settings, and people will also complain when you really merged it... so there have to be complaints anyway... :P)
"Why do people think that a server SKU works well as a general purpose operating system?"
People using a server OS as a client OS should know about the caveats,
"It’s just one of probably hundreds of other settings that are tweaked in favor of server responsiveness on server SKUs. "
And most of them can be changed, if you know how, for example:
"To change the MMCSS tuning options, you should follow the suggestions from the MSDN article I linked to above"
"The single machine may be a laptop that you lug around. Carrying 2 laptops is a sub-optimal traveling proposition."
Unfortuately in this case, Hyper-V do not support suspend or hibernate.
BTW, you could in theory mix workloads and run both a game and a server app on a server OS. I am sure that that kind of stress test will expose many bugs and race conditions.
Richard Berg: Add PAE to the list.
I actually asked Larry Osterman about adding PAE to client versions of Windows and unfortunately he said it would take too much testing cost to add it as an update to client versions of Windows, in fact I recently sent another email to him about after a recent issue of the Windows Secret Newsletter shows how to enable PAE, I know it would not work but wished that it did.
One reason I thought it would be a good idea was that if you are only running 32-bit apps, 64-bit offers little benefit over 32-bit+PAE, in exchange you lose 16-bit support and requires a reinstall, while enabling PAE requires a simple switch.
Maybe, since there will be a 32-bit version of Windows 7 or Vista SP2, that full 36-bit PAE (not only 32-bit as in current client versions of Windows) can be added there, or a hotfix that has to be requested from MS that requires less testing than an update. Late, but better than nothing.
Note that I was reluctant to post this comment.
"People also forget about how really fragile their audio experience was on that 300MHz Celeron box. In 1998 there was only one app that could play audio on the system at a time (the mixer functionality was added in WIn98). And if anyone did anything that vaguely stresed the CPU or disk, audio glitched like crazy."
It is still happening today, see this:
Yuhong: The VirtualDub example is a good of the kind of things that happened on XP (the post doesn't say if it's XP or Vista).
The entire purpose of the MMCSS service is to avoid that kind of problem - essentially when a thread is managed by MMCSS it runs at an EXTREMELY high priority for a very small amount of time.
And I was not the only one wanting PAE on client versions of Windows, I visited the forum and seen some other people wanting the same thing as well.
"64-bit offers little benefit over 32-bit+PAE"
Other than increased kernel address space, which is sometimes important, such as Exchange, but more often not.