Experience with the central server model on a lightly-loaded system

Analytic models potentially provide an elegant means of estimating the performance of computer systems at a rather nominal cost. The assumptions which must be made about a system in order to construct a mathematically tractable model, however, are usually severe enough to cast doubt on the validity of the results produced by such a model. Further, relaxation of an assumption often renders an analytic technique inapplicable, such that simulation becomes the preferred approach to system modeling.

To investigate the boundary between analytic models and simulation models a computer program has been developed which provides a framework within which to develop and compare both analytic and simulation models. A general queuing network architecture has been adopted. The program is extensible with respect to analytic techniques, queuing disciplines and probability density functions.

Using this program, models of a lightly loaded batch multiprogramming system were constructed. The system was viewed as a network of servers preceded by queues. The central processing unit was one server and each I/O channel was treated as a separate server. The channels were organized in parallel with respect to each other, and in series with respect to the central processing unit. Tasks were viewed as tokens flowing through the network, being delayed by each server for queuing delays and service. Delays between task termination and initiation of a new task were modeled by additional servers operating in parallel to the I/O channel servers. An analytic solution was computed for this model for the steady state case with exponentially distributed service times and the first-come-first-served queuing discipline with unlimited capacity queues. Typical errors of 18% were observed for cpu utilization and I/O activity. The model was then modified to more realistically account for the behavior of partitions. The delay servers were modeled with unit capacity queues. This model was solved by simulation, yielding errors of 4% for cpu utilization and I/O activity.