Why is Windows not considered suitable for real time systems/high performance servers? [closed]

Question

I hope this question isn't too subjective, but why is Windows considered an unsuitable operating system for real time systems and high performance servers? Are there any technical papers or studies that gauge it's performance compared to *nix alternatives?

I've never actually heard any explanation of why developers are against using Windows for these types of systems, aside from the extremely common 'Windows is not a real time operating system' statement, as if it's some kind of well known fact that doesn't need to be justified.

Note that I'm asking about Windows CE/Windows Server, not the desktop versions of the operating system.

Answer 1

A real-time OS needs a certain amount of deterministic behavior. You want to be able to set up specific task priorities that are always honored and have interrupts that have a specific priority. You can't have an OS that might decide to give priority to a daemon or task that is outside your application. Depending on your system microseconds might matter, an OS that goes off for 50 usecs to handle a daemon outside your application might be deadly.

Now, with that said it doesn't mean you can't use Windows for a real time application. In fact I've done it several times, it's just the real-time aspects were handled by hardware cards and buffering built into the system. If the OS was hundreds of milliseconds late it just meant the display might have a perceptible hiccup in the data. No data was ever lost or not collected. We were also able to avoid problems by customizing what other tasks were running (pretty much the same thing hard core gamers do).

Alternately, I had a recent request to do a real-time system where the real-time hardware would issue a callback that the windows code would see and then send out a USB message. The message had to be sent within microseconds and whatever the delay was it HAD to be deterministic so that the system receiving the USB message could compensate for the delay. This struck me as something that Windows is not suited for and the design was reworked.

Even though this question is now closed I thought I would udpate this response with a link to lengthier blog post I wrote on the topic.

Answer 2

Windows has a long-standing reputation about that, based primarily upon isolated bad experiences (everyone has a few, don't they?) which persists through major revisions that obsolete old reasons. Unfortunately, the vast majority of system administrators have never seen any of the performance tuning documents freely available from Microsoft, and even fewer have bothered to tune their systems appropriately.

Real-time critical systems can work on Windows. Look at call center solutions, for example - this is one of my areas of expertise, and I oversee several dozen servers doing exactly this. These machines can have hundreds of lines simultaneously processing voice recognition and speech synthesis at the same time, communicating with databases and programmable call routing systems. Delays in responding to the telephone company's equipment can cause some or all of those calls to be dropped or call quality to degrade severely. We still have to implement antivirus and other security measures, and these systems run.

The most important things you need to do are: * Eliminate periodic automated jobs and processes, like checking for and applying updates, disk maintenance (such as defrag operations and cleanup) and full scans, and move them to regularly scheduled downtime for maintenance. * Have enough memory so the system doesn't get bogged down with swapping * Put your swap on its own partition so fragmentation doesn't interfere with the swapfile (some of my systems don't have this and still work) * Work with the antivirus vendor to fine-tune their product such that it interferes with your server(s) as little as possible while still providing adequate protection - most antivirus software is meant for desktop use, not server use, and will require tuning * Tune your group / local security policies

In the end, UN*X systems can have the same problems if you don't administer them properly: Scheduled jobs, inadequate swap configuration, and intrusive 3rd party security software. They also get overlooked when it comes to security so often that it's no more surprising when they are compromised than when a Windows server is compromised.

You've got to have balance. Both platforms can be equally mismanaged, and both platforms can be well-tuned. If you're talking primarily to UN*X platform people, well, they have reasons they like their platform and have a lot of bias against Windows and you'll get answers that reflect that. If you're talking to Microsoft people, you'll get the same from their angle.

The most important thing when you're choosing the platform should be vendor support for the APPLICATION you're running - which one are they more invested in, and which one have they favored in their development? What has been proven to work the best, and what will continue to be available in the future?