Over the past two decades, Microsoft Windows and other multitasking systems have taken over the computer market to the point where there are no operating systems currently available for sale which can be used for interactive experiments involving reaction time or other rapid read-modify-write (RMW) operations.
Windows is written mainly for business use, and so is designed to give the maximum throughput as seen by the businessman sitting at the console. The demands of the business world for flashier, more attractive software for advertising and business operation, point and click operation, and the ability to run several programs at once, are putting an end to computerized experiments for scientific research.
A read-modify-write (RMW) operation is any operation where the computer samples the real-world variables of interest, and must react by sending out a real-world signal when a critical value is reached or exceeded. The latency time is the time it takes from the instant the critical value is attained to the instant the computer actually sends out the signal.
Each operating system has a latency period for RMW operations, which cannot be reduced below a value set by the operating parameters of the computer or operating system. The following table shows several operating systems whose latency periods have been measured, the measured latency periods, the fastest possible continuous RMW speed, and the reasons those latency limits exist:
|OPERATING SYSTEM||LATENCY||MAX REPET. SPEED||REASON LATENCY EXISTS|
|Tandy Color Computer BASIC||100 ms||10 Hz||Interpreter speed|
|Tandy Color Computer 6809 Assembly||1 ms||1 KHz||Processor speed|
|MS-DOS, interpreter BASIC||200 ms||5 Hz||Interpreter speed|
|MS-DOS, compiled program||2 ms||500 Hz*||Periodic OS interrupt stops program|
|MS-DOS with DMA||1 ms||1 KHz*||Periodic OS interrupt stops program|
|Windows 3.1/95/98/2000/ME||165 ms||6 Hz||I/O must occur in Windows timeslice|
|Windows 3.1/95/98/2000/ME with DMA||110 ms||9 Hz||I/O must occur in Windows timeslice|
|Windows NT||110 ms||9 Hz||I/O must occur in Windows timeslice|
|Windows NT with DMA||55 ms||18 Hz||I/O must occur in Windows timeslice|
|Windows NT with timestamp||4 s||.25 Hz||Process must wait its turn|
|Windows XP with DMA||55 ms||18 Hz||I/O must occur in Windows timeslice|
|Windows XP with timestamp||4 s||.25 Hz||Process must wait its turn|
|Windows Vista with DMA||55 ms||18 Hz||I/O must occur in Windows timeslice|
|Windows Vista with timestamp||4 s||.25 Hz||Process must wait its turn|
|Windows 7 with DMA||55 ms||18 Hz||I/O must occur in Windows timeslice|
|Windows 7 with timestamp||4 s||.25 Hz||Process must wait its turn|
|XENIX with timestamp||Infinite||0 Hz||Did operations in the wrong order|
* Assuming no extraneous drivers are installed. Additional load on the periodic interrupt can multiply the latency time by any positive integer.
In each case, the data were collected by connecting the start terminal of a stopclock to the producer of the critical value, and the stop terminal to the signal produced by the computer.
Notice that it takes several timeslices for Windows to be able to do one RMW operation. First, the read must occur in the Windows timeslice. Then the test and decision to send a signal must occur in the program's timeslice. Then the write must wait for the next Windows timeslice. Finally, the following read must wait for yet another Windows timeslice, since the program has not yet asked for it. The result is that no repeating RMW operation can occur at speeds faster than 9 Hz on computers running Microsoft Windows, unless Direct Memory Access (DMA) hardware is used.
Notice that it doesn't matter how fast the processor speed is. If there are interruptions in the flow of data that are longer than half the time between successive data points, the entire process fails.
Some Windows software has been written to achieve a higher speed. The collection, bossed by an external clock and using DMA, can reach speeds of several megahertz. But it works only if all of the data are being read, with no control outputs. The latency period still occurs, and the response to the critical value still occurs an average of 55 ms after the event occurs. There is no wait for the next read, so the second 55 ms delay does not occur, boosting throughput to 18 Hz. If the programmer is not aware of this variable delay averaging 55 ms, the experiment is ruined, and the results are tainted by the delay. Some results have already been published by experimenters who did not have any inkling that these delays exist.
Other software lets the data queue up, and timestamps it, so the software can reorganize it into the proper order later. This works well as long as all of the data are flowing in the same direction. But a live human subject can't be given a stimulus containing a timestamp telling the subject "The stimulus really occurred 43 ms earlier. React accordingly." Likewise, chemical reagents can't be told to wait until the time on the timestamp can be reconciled with real time before reacting. Delays caused by timestamp systems can reach several seconds.
Recently, software has been released which does I/O to a special port box when the program has control. But it misses the events that occur during the Windows timeslice.
UNIX and MAC OS have similar problems, but I have not had the opportunity to evaluate them. But the problem is one common to any multitasking operating system.
Using MS-DOS and QuickBasic, it was easy to make the computer operate a record changer for a phonograph. I simulated a Collaro Conquest:
Until motor power is off.
Using MS-DOS and QuickBasic, this worked quite well. The operations were performed in the correct order.
Using Windows (any version) and C+, this is what happened when I tried to run the same record changer:
Until motor power is off.
What a mess! The operations were done in the order Windows granted control of the devices, not in the order that made the record changer work properly.
There are the results of this change in the computer market that are disastrous to science.
In one program the page author tried to use, the computer first collected all of the data. Only after all of the data were on the disk did it do any of the error correction calculations that were supposed to be supplied to the experimental hardware during the data collection. Then, after it had done all of that, it sent the output signal to tell the experimental device to start the experiment.
Business has dominated the computer market, which has caused the following problems:
The best operating systems for RMW data collection and process control are the early ones, where the operating system stayed out of the way until it was needed. Examples are the Tandy Color Computer operating system (which didn't even run until actually needed), MS-DOS, and Apple OS. But most operating systems of this kind cannot run on new computers. When the older computers wear out, scientific research using RMW will effectively end, unless new solutions are found.
If it weren't for Microsoft's adamant drive to rid the world of it, MS-DOS could still be a contender for scientific work. But it is now totally unavailable and unsupported, and its interrupt-driven nature limits the speed. Yet many researchers are using it, mostly because they must use it to get anything done at all. Some of the MS-DOS systems used in research are bootleg copies by necessity.