Software-based measurement and control systems have requirements for timing and synchronization that are distinctly different from those of ordinary applications. If you're writing an application that serves only a human operator (such as a word processor), chances are that your only timing requirement is to be fast enough that the user doesn't have to sit and wait for the computer to catch up. Exactly when an event occurs is not so important. But in a control system, there's a physical process that demands regular service to keep those boiling kettles from overflowing. Similarly, a data acquisition system needs to make measurements at highly regulated intervals, lest the analysis algorithms get confused. That's why LabVIEW has built-in timing functions to measure and control time. Depending on your needs, LabVIEWs timing functions can be simple and effective or totally inadequate. And the problems are not all the fault of LabVIEW itself; there are fundamental limitations on all general-purpose computer systems with regard to real-time response, whatever that means (1 second? 0.01 second? 1 ns?). Most applications we've seen work comfortably with the available LabVIEW time measurements that resolve milliseconds, and many more operate with 1-s resolution. A few applications demand submillisecond resolution and response time, which is problematic owing primarily to operating system issues. Those cases require special attention. So, what's with all this timing stuff, anyway?