Modern computer systems are increasingly being used to perform a large variety of difficult data gathering and analysis tasks. With the growing prevalence and complexity of computers, it is frequently desirable to obtain information and answer questions about the computer system itself. Due to the complexity of the machine, it is difficult to obtain useful information purely by manual methods. Since the computer has been used to solve such a large variety of problems, it is only natural that the computer be used for introspective tasks as well. For example, computer systems have been designed with capabilities to diagnose hardware failures, provide performance and usage information, assist debugging of programs, etc.
When solving introspective problems, a computer is often required to answer hypothetical questions. It may need to know how it would respond to a given external workload, how long it would take to run a particular program, what would be the effect of temporary loss of a hardware component, etc. One type of application in which such questions must be answered is the capacity planning application. Capacity planning involves forecasting future workload to be imposed on a computer system. predicting how the system will respond to such workload, and determining how such response may be improved (as by attaching additional hardware to the system). Another such application is hardware and software development, in which it is desirable to know how a system will respond to a hardware or software component under development in a variety of prospective environments. Still another possible application is in defect diagnosis, particularly defect diagnosis of an intermittent error condition, in which re-creation of the intermittent error condition requires that a particular environment be assumed. Another possible application is performance analysis and diagnosis, in which it is necessary to determine how the system behaves under given conditions and how system behavior can be altered.
In theory, it is possible to duplicate the hypothetical conditions with actual hardware running appropriate software on behalf of real users. In reality, such a solution is seldom practicable. For example, a commercial enterprise planning for future expansion may wish to know how its system would respond to increased workload from a larger number of attached terminals and interactive users. In theory it could buy the required equipment, hire the terminal operators, create additional workload for input to the system, and observe the results. In reality, such an approach is prohibitively expensive. In another example, a software development house may wish to know how its software will behave on a particular family of computer systems, under a variety of system configurations and workloads. It could buy all the hardware required to duplicate the various configurations, hire the required number of interactive users, and observe the results; again, this approach would be prohibitively expensive and time consuming. In addition to being prohibitively expensive and time consuming, the duplication of real conditions as described above is frequently undesirable because it is impossible to obtain repeatable results. When real users enter data at a keyboard, there will naturally be some variation in the actual timing of input streams, causing observed results to vary. In some applications, such variation is a serious drawback. For example, a developer who is attempting to diagnose an intermittent error condition will want to establish a repeatable sequence of events by which the error condition can be induced.
Another approach to providing data for hypothetical problems is the use of special purpose hardware simulators, which take the place of attached devices with real users. Such hardware simulators obviate the need for live interactive users, and can be made to generate simulated workload in a repeatable manner. However, hardware simulators are still a very expensive method of providing this information. Typically hardware simulators are more expensive than the devices they replace. As a result, the use of hardware simulators is generally confined to system development laboratories.
It is possible to create simulation software. This software attempts to duplicate the hypothetical conditions by issuing instructions from the central processing unit (CPU), causing simulated workload to be processed by the system. Such software is adequate for some tasks, but often lacks the ability to simulate many conditions on the system. The computer system typically comprises a single CPU, which is coupled to various memory devices and slave processors via one or more communications buses. The slave processors are in turn coupled to I/O devices such as disk drives, interactive workstations, printers, etc., or may be coupled to other slave processors. System behavior will depend not only on the number and type of such devices, but the connection topology as well. Simulation software running in the CPU will not always accurately represent the state of other parts of the system, in particular the slave processors and I/O devices.
When a computer performs introspective tasks, it may obtain some information from the operator, but generally the source of its information is the computer itself. As with any task performed on a computer, the quality of the output information can be no better than the quality of the input. Unfortunately, the computer systems of the prior art lack the ability to obtain accurate information for answering many hypothetical questions at reasonable cost.