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).
"THERE IS NO REASON NOT TO PROPERLY SUPPORT AUDIO ON A SERVER SKU."
Indeed server SKUs do properly support audio if you configure them properly, it is just not enabled by default.
"Furthermore, going by that weird logic of yours, why don't you rip out the GUI from server SKUs?"
I actually once wished that you could rip out the GUI completely from NT just like you could with OS/2. When I thought about the "Windows=On" option on csrss's command line, I thought about that. Larry Osterman, is that technically possible? Or is Windows Server 2008 Server Core the best Windows can do on ripping out the GUI?
"Finally, going back to SERVER .vs. CLIENT -- the only differences (even though Microsoft would like us to believe that there is more to it) are in scheduling quantums and priority boosts, security settings, and services configuration.
There is no special SERVER kernel, no special files, no voodoo magic that differentiates SERVER from CLIENT OS. IT IS THE SAME PRODUCT CONFIGURED SLIGHTLY DIFFERENTLY."
I once justified adding real PAE support to client OSes using this.
Tell your idiots in the SharePoint team to make an SDK that runs on your consumer OS then.
If random people can hack apart sharepoint to run on XP then you guys can do it in a dev-only supported way...
Hmm. Views of the average student home-user here, and I realize this might make me sound like a moron, but I'll have a go anyway.
I currently run the Win7 Beta as primary OS (and I like the experience so far), but previously I've always been an XP/Linux user. Primarily XP, due to gaming and various other doodads, Linux mostly for the heck of it.
There's two reasons I gave 2k3 a run as general purpose OS.
1. Rapant curiosity. I heared that it was supposedly some sort of 'miracle OS' that was better than XP in every respect. And while that obviously is exaggerated, I wanted to see for myself. The free evaluation stuff for 2k3 made that easily possible, so I just gave it a go.
2. 64-Bit LBA support. To my confusion, 64-Bit LBA support never trickled down to XP 32-Bit. Silly dumb me assumed it'd likely be an undocumented feature of SP2 (Don't ask. For some reason it made sense to me at the time.) and I invested into a large-ish RAID array. Of course XP promptly gave me the "Only 2TB for you, fool." shtick. Pretty much everyone I knew told me "Trust me, do not touch XP 64-Bit, friend." at the time, so 2k3 was pretty much the only Microsoft OS that did what I wanted. Vista was a no-go, as there were no Vista/2k8 drivers for my Raid Controller at the time. (There are now.) Of course, there's always Linux (which actually cooperated with the Raid controller without needing additional drivers), but it gave me another convenient excuse to check out 2k3.
Also, there's something about Vista that makes me feel uncomfortable about using it. I've never exactly been able to place what exactly causes this (and it's likely some sort of irrational effect), but it definately irked me the wrong way. I'm happy that this seems to have gone with Win7.
Anyway, I'm straying off the subject here.
To my positive surprise 2k3 actually held up to what I was promised by word of mouth. Very fast out of the box, runs anything XP does just fine with an hour or two of tweaking, and that's despite me giving the 64-Bit version a go. Luckily there were 64-Bit 2k3 drivers for every bit of hardware in my compy, so zero issues on that front as well.
2k3 seemed to run faster with all the necessary-for-desktop-use stuff turned on than XP with not-necessary-stuff switched off. Especially the UI seemed amazingly responsive.
Plus, 2k3 seemed virtually unkillable. I didn't have a single crash or BSoD in the time I have used it. It still handled gracefully enough when (multiple) processes got caught in infinite loops, and allowed me to close them without major waits. Even doing ridiculous stuff like starting three taxing 3d games and alt-tabbing between them didn't really faze it at all. Led to some paging, waits, and one of the games shot itself in the process, but 2k3 acted like nothing happened afterwards. Something I was not accustomed to from XP.
I realize that most of this is possibly easy to accomplish on 64-Bit XP as well nowadays (now that driver issues are largely out of the way?) but I found it somewhat ironic that a slightly tweaked 2k3 seems to run (a lot?) better, faster and easier on the RAM than an out-of-the-box XP.
If it weren't for the prohibitive pricetag this would make it a very useable SKU for home use in my opinion. If it were half the price it was at the time, I'd have bought a license or two. Sadly it stayed with the trail. (Which killed itself a few months early when I had to reset CMOS due to memory voltage issues. It went "You naughty guy played with the system time!" and locked itself. Bummer.)
Plus, there's always the benefit of domain controller/active directory stuff, which, while not really useful for home use, is at least an interesting learning experience.
There are a lot of good comments here but there is one aspect that is completely overlooked.
Vista and Server 2008 are split into a god awful number of SKUs.
When you give a customer that many choices, there is bound to be a segment that is confused. More choices is not always better.
I don't know, pre-Vista audio worked OK for me, in properly written software. I mean, the software written by people who understand what thread priorities are used for. If audio stack runs on thread priority 15, there should not be much possibility of it getting starved. Why there should be other CPU intensive threads running on 15? Isn't MMCSS just a big kludge to plug a design weakness in scheduler? Maybe just change the scheduler to downgrade CPU intensive threads (those that routinely fully consume their time slice) in priority?
It's not a big secret that the (XP) round-robin scheduler just sucks; thanks to multiprocessors that this suckiness is somehow concealed. On a single processor, if IE7 gets stuck in an infinite loop (which it does very often, thanks to crappy JS engine or something), your whole UI gets so sluggish. It doesn't even help that thread that owns a foreground window has a priority boost, ho help at all (or maybe it doesn't really get it?).
Alexandre, unfortunately there are lots of threads in the system that run at higher priority than Pri15. XP would glitch like crazy whenever you did something even vaguely CPU intensive, there was a ton of work done in Vista and WIn7 to allow applications to render multimedia even when background processes were thrashing the system.
If there are CPU intensive threads with priority 15 (THREAD_PRIORITY_TIME_CRITICAL) , those who start them need a good knock in the head. I mean, if they think their _CPU intensive_ job is too important, they don't understand the concept. NORMAL_PRIORITY_CLASS/THREAD_PRIORITY_NORMAL is 7 or 9, depending on whether this is a background or foreground thread. You only need 15 if starvation of those threads is completely unacceptable, which is pretty rare. The only valid case I see is realtime resampling, and even it is NOT that CPU intensive.
Maybe instead of bothering with writing MMCSS, the scheduler just needed to reduce time slice to 1ms for high priority threads. With the high resolution interval timer present in modern chipsets it's completely feasible. Then, even with a lot of threads of priority 15 running, their latency would still be somehow acceptable.
PS. Somebody, please fix this blogs.msdn.com blog engine. It's so unreliable. No, don't fix, just replace it with the one that works. I don't mind if it's PHP based instead of aspx. Just make it work.
"Pretty much everyone I knew told me "Trust me, do not touch XP 64-Bit, friend." at the time, so 2k3 was pretty much the only Microsoft OS that did what I wanted".
Big surprise for you. Windows XP x64 is just a client SKU of W2K3. The same stuff inside.
If I recall correctly, one of the major issues fixed in Vista SP1 was very poor network performance while playing audio... something like the MMCSS service limiting the number of interrupts per second to a number that wouldn't matter to 10 mbit ethernet, would control 100mbit, but would cut gigabit networks to 100mbit speeds.
ahh, here it is http://blogs.technet.com/markrussinovich/archive/2007/08/27/1833290.aspx
So it's more than just percentages of CPU time, there are a lot of little things.
"Big surprise for you. Windows XP x64 is just a client SKU of W2K3. The same stuff inside."
In fact, that is true of the previous "Windows XP 64-bit Edition Version 2003" for Itanium as well.
Well, I'll answer your question directly - because the server OS certainly seems capable of doing it (with the right hardware installed). So why not?
I am a developer - I "live" in my OS. I'd rather live in a normal appartment, with video wall and a nice hi-fi thatn in a server room :)