Lessons Learned when working with Windows

Just some things to think about if you find yourself working in a Windows environment for scientific purposes. This thread will grow over time. I'll try to bump it as it gets updated.

Reconsider

Windows is an environment fraught with perils for the unsuspecting scientist who is trying to figure out how that cool new part works, or who wants to measure something in anything like real time. There are lots of situations where people are now virtually forced into using Windows (LabView, I'm looking at you) because people like to use in-house, custom-built drivers that us scientists have to buy from the people who develop the instrument. It's sometimes possible to avoid these situations; a number of PCI vendors are now providing *nix drivers for their units. Some still aren't. After dealing with two project's worth of development of Windows drivers for data input devices, it now seems clear that in many cases the "ease" of use with Windows isn't worth the pain of troubleshooting away the unintended interactions of the operating system with what you're trying to do.

Keep in mind that Windows doesn't play nicely, in real time


Attempting "real time" data input with Windows is a lesson in futility. The operating system jumps in and takes control of the processor at seemingly random, and unavoidable, times. If your data stream is constantly hitting your input buffer and you care about millisecond accuracy in your timing, tread carefully. Especially make sure that your buffer is large enough that it can handle the OS taking over the processor for a few hundred milliseconds without having your data overflow the buffer and be lost.

Never trust the Windows system clock for absolute time


It returns an absurdly high-precision time stamp. This doesn't appear to have anything to do with reality. Even if you're using a Network Time Server, you still are dealing with a few milliseconds of lag between your computer and the time server. Use a local GPS unit with a 1 pulse per second (PPS) signal so that you can synch the local (Windows) time with GPS time.

This is especially true if you're using some sort of "real time" runtime software (e.g. LabView or LabWindows and a "one second clock"). It doesn't take too long for that clock to start getting off by a few parts per thousand (e.g. milliseconds). If you never care about sub-second timing, this probably doesn't concern you. If all you care about is, say, data logging the security cameras at your store, the Windows clock is fine. If you want to synch your data with other phenomena in the outside world, then you need to use something external to the system to synch things up.

Turn off everything that you can


Windows boots with a large amount of unnecessary software at launch. Most people know about this, but sometimes we forget that we've changed machines are we're no longer working with a clean build and you need to open the task manager and clear out anything that looks extraneous without killing the OS. Sometimes this is difficuly; sometimes this is not. If you have a good one (and congratulations if you do!), consult your sysadmin to try to turn everything off that you can. It sounds like a silly thing to have to track, but having the Windows updater boot while you're in the middle of an overnight data acquisition isn't fun.