MICROSOFT WINDOWS VS SCIENCE



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.


The Big Operating Systems that Can't

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:

Observed Latencies in Various Operating Systems

OPERATING SYSTEMLATENCY MAX REPET. SPEEDREASON LATENCY EXISTS
Tandy Color Computer BASIC100 ms10 HzInterpreter speed
Tandy Color Computer 6809 Assembly1 ms1 KHzProcessor speed
MS-DOS, interpreter BASIC200 ms5 HzInterpreter speed
MS-DOS, compiled program2 ms500 Hz*Periodic OS interrupt stops program
MS-DOS with DMA1 ms1 KHz*Periodic OS interrupt stops program
Windows 3.1/95/98/2000/ME165 ms6 HzI/O must occur in Windows timeslice
Windows 3.1/95/98/2000/ME with DMA110 ms9 HzI/O must occur in Windows timeslice
Windows NT110 ms9 HzI/O must occur in Windows timeslice
Windows NT with DMA55 ms18 HzI/O must occur in Windows timeslice
Windows NT with timestamp4 s.25 HzProcess must wait its turn
Windows XP with DMA55 ms18 HzI/O must occur in Windows timeslice
Windows XP with timestamp4 s.25 HzProcess must wait its turn
Windows Vista with DMA55 ms18 HzI/O must occur in Windows timeslice
Windows Vista with timestamp4 s.25 HzProcess must wait its turn
Windows 7 with DMA55 ms18 HzI/O must occur in Windows timeslice
Windows 7 with timestamp4 s.25 HzProcess must wait its turn
XENIX with timestampInfinite0 HzDid 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.


Why They Don't Work

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.


Effects Caused by the Shift to Multitasking

A COMPUTER
CONTROLLED
RECORD CHANGER

Using MS-DOS and QuickBasic, it was easy to make the computer operate a record changer for a phonograph. I simulated a Collaro Conquest:

Repeat:

  1. Using Input Unit A, wait for either the Reject Control or the pickup arm moving toward the spindle faster than 1/8 inch per turntable rotation.
  2. Using Output Unit X, raise the pickup arm to free swinging level.
  3. Using Output Unit Y, swing the arm to directly over the rest post.
  4. Using Output Unit X, raise the pickup arm to the height of the unplayed stack
  5. Using Output Unit Y, swing the arm toward the stack to feel the record size.
  6. Using Input Unit B, detect when the arm touches the rim of a record. Store the size so measured. If the arm does not touch a record, store a size of 0.
  7. Using Output Unit Y, swing the arm to directly over the rest post.
  8. Using Output Unit Z, move the record pusher to drop the next record.
  9. Using Output Unit X, lower the pickup arm to free swinging level.
  10. Using Output Unit Z, retract the record pusher.
  11. Using Output Unit Y, swing the arm to the record size remembered earlier. If the record size remembered is 0, leave the arm over the rest post.
  12. Using Output Unit X, lower the pickup arm to the record or the rest post.
  13. Using Output Unit W, turn off the motor if the record size remembered is 0.

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:

Repeat:

  1. Using Input Unit A, look for either the Reject Control or the pickup arm moving toward the spindle faster than 1/8 inch per turntable rotation.
  2. Using Input Unit B, detect when the arm touches the rim of a record. Store the size so measured. If the arm does not touch a record, store a size of 0 (fails because the arm is still playing the record).
  3. Windows granted control of Output Unit X:
  4. Using Output Unit X, raise the pickup arm to free swinging level.
  5. Using Output Unit X, raise the pickup arm to the height of the unplayed stack (hitting the bottom of the next record)
  6. Using Output Unit X, lower the pickup arm to free swinging level.
  7. Using Output Unit X, lower the pickup arm to the record or the rest post.
  8. Windows granted control of Output Unit Z:
  9. Using Output Unit Z, move the record pusher to drop the next record (because the arm is playing the record, the next record drops on the pickup arm).
  10. Using Output Unit Z, retract the record pusher.
  11. Windows granted control of Output Unit Y:
  12. Using Output Unit Y, swing the arm to directly over the rest post (since the arm is not raised, the needle scratches the record).
  13. Using Output Unit Y, swing the arm toward the stack to feel the record size (since the arm is not raised, the arm touches the record on the turntable - but no size is stored because Input Unit B has already finished).
  14. Using Output Unit Y, swing the arm to directly over the rest post.
  15. Using Output Unit Y, swing the arm to the record size remembered earlier. If the record size remembered is 0, leave the arm over the rest post.
  16. Windows granted control of Output Unit W:
  17. Using Output Unit W, turn off the motor if the record size remembered is 0.

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.

  1. Often the operating system alters the order of the operations the program calls for, so the program does not do what it was written to do. Often disk operations are given priority while calculations are delayed. The computer does thing in the order the operating system wants them done, not in the order the experiment calls for.

    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.

  2. It has become impossible to develop software that can meet the need for rapid RMW operations. Any software that can do this also causes error traps. Windows reserves control of all I/O operations for itself, but will not start I/O operations often enough for scientific experiments or process control.
  3. Some experimenters are using software that they think is working properly, and are collecting data that are badly distorted in time. This, of course, will lead to wrong conclusions.
  4. The experimenter has no way of verifying that the software actually does what the experiment calls for. Because many functions actually make operating system service calls, the precise operation of which are guarded secrets, the user can't know the timing.
  5. Many producers of scientific experiment software went out of business, because they couldn't get their software to work on new operating systems.

Other Business-oriented Practices that Destroy Science

Business has dominated the computer market, which has caused the following problems:

  1. The computer market has turned into a virtual monopoly.
  2. New versions of operating systems are being released, not to correct errors, but to keep income flowing into the software companies. The old software won't work with the new operating system, and the new software won't work on the old OS. This creates turmoil in the scientific world, because a single research project can last much longer than an operating system.
  3. Every time a new operating system is released, any program doing I/O to proprietary devices must be rewritten to be able use it. This causes gaps in the supply of scientific software. It also forces users to buy new software to keep doing what they had been doing before the upgrade.
  4. Many business managers overseeing laboratory operation do not understand the need for unbroken continuity in a research project, and order that the latest operating systems must be installed in every computer in the firm. This can cause months of delay in any scientific project.
  5. New computers have connectors or card slots that don't fit the existing laboratory equipment or I/O cards.
  6. The Intel platform itself is unsuited for RMW use. Business has forced out the more viable processors in favor of this interrupt-driven system.
  7. In order for computer manufacturers to be allowed to supply Windows with their computers, they are required to use it in every computer they sell.
  8. As soon as the new operating system comes out, the older versions are discontinued. This makes it impossible to expand an existing laboratory without changing everything out.
  9. No new computers or operating systems designed for this purpose are being made. The excuse is that business dominates the market, so all computer manufacturers are going after that market.
  10. Salesmen cannot be convinced that the superfast computers they are pushing can't do the RMW jobs. Some even lie to make the sale, and the unsuspecting scientist is left with a computer that can't do the job.
  11. Software companies won't support old versions of their products.
  12. Copyright restrictions prevent purchasers of new equipment from legally installing older operating systems on them.

The Little Operating Systems that Could

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.


What You Can Do to Change This:



Links