An Interactive Web Simulation of CPU/Disk Performance

An Interactive Web Simulation of CPU/Disk Performance

Paul Fishwick, Matthew Belk, Bradley Spatz

We present a functional model of a CPU/Disk subsystem with an interactive execution using SimPack. Aside from providing technical data on the model, the paper serves as an experiment in publishing an interactive simulation on the World Wide Web. See Citing and Referencing Web Publications for further information. Let's consider a combined CPU/Disk system (Audio Introduction):

Point to a feature for an explanation.

Let's simulate this system!

There is a single CPU (Central Processing Unit) that will execute a set number of tasks. Each task will have disk I/O requirements. The cyclical nature of this model reflects the fact that a single task will be simulated as follows:

Use CPU
Access a disk (1-4)
Use CPU
Access a disk (1-4)
Use CPU
Access a disk (1-4)
Use CPU
Access a disk (1-4)
... etc ...

This occurs until a set number of tours have been completed. Sample tours are shown in an MPEG Video created from individual frames with the POVRAY Ray Tracing Package. One tour for a task is the use of the CPU followed by the disk before cycling back. Let's now consider the CPU/Disk system primary code (within the switch statement). This will be shown using SimPack. The code for the CPU/Disk system is now specified:

The first thing to note is the selection of events that have been defined after constructing the graph. Events have no time interval associated with them; they occur at an instance of time. Therefore disk-operating would not make a good event since it involves an inherent time duration. Start Disk would be fine since it ``brackets'' (along with end-disk) the disk operation procedure. In this model we have events that bracket the 1) operation on the CPU, and 2) the operation on the Disk. Let's now discuss the switch statement code.

The purpose of schedule is to allow you to place time durations in the simulation. For instance --- the CPU will take a certain amount of time per task. This time can be obtaining by sampling a probability distribution. By scheduling the ``end of CPU usage'' for a token (i.e. task), we are simulating the use of the CPU for that time period. The CPU resource is a preemptive resource whereas the disks are not. This means that the CPU can be preempted but the disks cannot. Let's consider the piece of code where we request the use of the CPU:

case 2: /* request cpu */
if (preempt(cpu,i,j) == FREE)
schedule(3,expntl(tc[j]),i);
break;

This states that token i with priority j wants to use the facility. If the facility is free then there is no need to preempt anybody. It is only when the facility is busy that preemption can take place.preempt returns FREE in one of two cases: 1) the facility is not busy and can therefore be obtained by the incoming token, or 2) the facility is busy but can be preempted due to the incoming token's high priority -- that is, the incoming token's priority is higher than the minimum priority of token(s) being presently being served. The schedulesimply tells the simulation how long the CPU is to ``operate'' for this token.

We will study the effects of each of the key routines by seeing what the main internal system data structures look like before and then after each routine is executed. The visual trace output can, therefore, be coordinated with the C source by comparing the current command being executed (schedule,release,preempt,request,etc.) against the corresponding C routine in the main program.

request
Request a facility. If the facility is free then the requesting token obtains one of the facility's servers. If the facility is busy, then this token is placed behind all queued tokens with the same or higher priority.
preempt
Preempt a facility. If the facility is free then the preempting token obtains one of the facility's servers. If the facility is busy then is a check is made to compare the server token's priority with the priority of the preempting token. If the preempting token has a higher priority, then preemption takes place. This means that
  1. The preempting token is placed in the server, and
  2. The token that was just displaced from service is placed in the front of the queue awaiting service (again)
The preempted token only need wait the remaining length of time necessary until its next event. On the other hand, if the preempting token has a lower or the same priority as the server token, then the preempting token does not preempt, and is placed behind all queued tokens with the same or higher priority. In this latter case, preempt behaves like request.
release
Release a server of a facility so the the token waiting on that server (if one exists) can now occupy it.

For another example of a Web-based simulation, consider an Indoor Pool Simulation based on GPSS.

Maintained by: Matthew Belk and Paul Fishwick.
Last Edited 20 September 1995