MICROSOFT WINDOWS VS SCIENCE

Over the past few 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 properly designed scientific experiments.

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.

There are several troubles that the latest operating systems cause for scientists. They include the following problems:

  1. Updates and upgrades destroy the Ceteris Paribus required by science
  2. Automatic Updates and Upgrades Interrupt a Running Experiment
  3. Upgrades make the scientific equipment stop working
  4. Inability to get the timing needed by the experiment
  5. Inability to react fast enough to changes.
  6. Inability to sequence the experiment in the correct order

Each problem has a different cause and a different solution:

  1. Updates and Upgrades Destroy the Ceteris Paribus Required by Science

    Microsoft Windows and other multitasking systems now have automatic update and even automatic upgrade functions that change the operating system. This destroys the continuity of the integrity of the way the data are handled.

    WHAT IS CETERIS PARABUS?

    "Ceteris Parabus" is Latin for "All else being equal".

    Whenever a scientific experiment is performed, the experimenter must provide proof that nothing has changed except the variables that are supposed to change. This includes all aspects of the handling of the data, including anything in the computer, the operating system, the means of storing the data, and the programs used to handle the data. It also includes anything that affects the sequencing and timing of the experiment.

    HOW DOES UPDATING OR UPGRADING THE SOFTWARE DESTROY CETERIS PARABUS?

    • A new version of the operating system may change the way numbers are used or stored. This can cause numbers stored using the old software to change to different values.
    • A new version of the operating system may change the way the experiment itself runs, or the timing of the experiment. A major change can even cause parts of the experiment to be performed in the wrong order.
    • A new version of a spreadsheet or database can affect how new numbers are stored and how existing numbers are read.
    • A new version of the file system can make old files unreadable or alter how they are read or interpreted.

    AREN'T THESE RARE CHANGES? WHY IS THIS SUCH A PROBLEM?

    The problem is that the experimenter does not know whether or not any change that affects the data has actually happened. So the experimenter must prove that nothing has changed that can do anything that could change the procedure of the experiment, change some of the data, or change how it is processed. He must do this EVERY TIME an update occurs. Obtaining this proof can take a large amount of time and can disrupt the experimental process.

  2. Automatic Updates and Upgrades Interrupt a Running Experiment

    Microsoft Windows and other multitasking systems now have automatic update and even automatic upgrade functions that take over the computer while it is busy controlling an experiment. This ruins the operation of the experiment.

    Microsoft used to allow users to control when updates occur. Now Microsoft stops whatever the computer was doing to force the update to occur.

    Such an interruption can damage processes that must not be interrupted.

  3. Upgrades Make the Scientific Equipment Stop Working

    Microsoft Windows and other multitasking systems take over the computer to the point where every time an upgrade is performed, the timing of input/output operations is changed enough that the scientific equipment being accessed can't use the new bus timing or protocol.

    This means that the computer suddenly can no longer control the scientific equipment the laboratory already owns.

  4. Inability to have the Timing Needed by the Experiment

    Microsoft Windows and other multitasking systems have taken over the computer market to the point where there are no operating systems currently available for use in interactive experiments involving reaction time or other short time intervals.

    Often when the critical event occurs, Windows has control of the computer and is doing something unrelated to the experiment. This destroys the timing needed by the experiment.

    Microsoft says to have the equipment issue timestamps and resolve the timing issue later. But this does not solve the problem, because you can't put a timestamp on a chemical process or an organism telling it that the change should really have happened at a certain earlier time.

  5. Inability to React Fast Enough to Changes.

    Microsoft Windows and other multitasking systems have taken over the computer market to the point where there are no operating systems currently available for use in interactive experiments needing rapid read-modify-write (RMW) operations.

    It thus becomes impossible to use a computer in a feedback loop to control a process. When an unwanted change occurs in the process, the computer often reacts too late to correct it because Windows had control of the computer at the time.

    The time between I/O timeslices is often longer than the needed time to make the adjustment.

  6. Inability to Sequence the Experiment in the Correct Order

    Microsoft Windows and other multitasking systems have taken over the computer market to the point where there are no operating systems currently available for use to control the sequence of complex experiments correctly.

    Too often Windows optimizes the order of the operations of the experiment to save time or improve disk operations. But this can cause the portions of the experiment to occur in the wrong order.

    One consequence of this is that the computer collects the data for the process before issuing the command to start the process.

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 Hz Interpreter speed
Tandy Color Computer 6809 Assembly1 ms1 KHz Processor speed
MS-DOS, interpreter BASIC200 ms5 Hz Interpreter 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 Hz I/O must occur in Windows timeslice
Windows 3.1/95/98/2000/ME with DMA110 ms9 Hz I/O must occur in Windows timeslice
Windows NT110 ms9 Hz I/O must occur in Windows timeslice
Windows NT with DMA55 ms18 Hz I/O must occur in Windows timeslice
Windows NT with timestamp4 s.25 Hz Process must wait its turn
Windows XP with DMA55 ms18 Hz I/O must occur in Windows timeslice
Windows XP with timestamp4 s.25 Hz Process must wait its turn
Windows Vista with DMA55 ms18 Hz I/O must occur in Windows timeslice
Windows Vista with timestamp4 s.25 Hz Process must wait its turn
Windows 7 with DMA55 ms18 Hz I/O must occur in Windows timeslice
Windows 7 with timestamp4 s.25 Hz Process must wait its turn
Windows 10 with timestamp4 s.25 Hz Process must wait its turn
XENIX with timestampInfinite0 Hz Did operations in the wrong order

* Assuming that 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.

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 these variable delays 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 the page author has 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 scientific 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 version.
  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.

    In many cases, it also renders useless the expensive laboratory equipment the lab is using.

  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