Using the Process Scheduling Simulator

An experimental run consists of a scheduling algorithm and a collection of processes to be run under that algorithm. An experiment consists of a number of experimental runs which are to be compared and analyzed. The simulator organizes the input information in order to make it simple to do experiments in which one or more parameters is varied. After the experiment has completed, you can produce tables or graphs of various statistics such as average waiting time, and throughput.

To perform an experiment, you must create two files. One file contains (the run file) contains information about the parameters that are common to all of the runs. The other file (the experiment file) contains a list of runs to be made and the parameters that vary between runs.

Information about the experiment including the specification of the processes and the statistics and graphs resulting from the experiment is stored in a log file in HTML format suitable for viewing from a browser.

This document describes how to use the simplest features of the process scheduling simulator locally on the system at UTSA. The simulator is not ready to be used remotely at other locations because of the problems with standardization of methods to bypass the Java sandbox security. This situation should improve when browsers support Java 1.2.

The simulator is of beta quality, and this documentation is of alpha quality. As the simulator is still being revised and the user interface has not been fixed, this documentation may be inaccurate in some of its details. General information about an earlier version of the process scheduler can be found here.

Table of Contents

Basic Operation

The yellow subwindow in the upper left corner labeled History shows the initial configuration read in from the configuration files. There are five columns of buttons at the bottom of the main window. The rightmost column of buttons allows you to choose the experiment to run and to run it. Pushing the top button in this column advances through the available experiments. Pushing the second button, Run Experiment, runs the chosen experiment.

The fourth column of buttons controls the log file. The top button allows you to open the log file. When the log file is opened, the button is changed to a Close Log button as shown in the diagram above. As runs are made they are logged in the log file and statistics about the run are saved. Pushing the Log All Table Data button puts two tables of statistics in the log file. The tables contains entries for all selected runs. All runs are selected by default. A sample set of tables is shown in Figure 2.

The first table contains information about average CPU utilization, throughput, turnaround time, and waiting time for each run. The second table contains more detailed information about the turnaround time and waiting time. In addition to the average, the minimum, maximum, and standard deviation are given for each.

The third column of buttons controls the creation of graphs. The top button allows you to choose the type to graph to create. The entry Graph: All Waiting means that a graph containing information on the waiting time for the processes of each run is to be produced. Each run is in a different color, and the distribution of waiting times is shown as a bar graph. The quantity graphed is the ratio of the CPU time to the total time in the ready queue plus the CPU time. Pushing the Draw Graph pops up a window containing the graph. This window contains a Log button that causes the graph to be inserted in the log file. A sample graph is shown in Figure 3.

The first two columns of buttons give you finer control over the running of the simulator and are described later.

Figure 1: The main simulator window.

Figure 3: A graph created by the simulator when the Graph: All Waiting is selected and the Draw Graph button is pushed.

Starting the Simulator from the UTSA Network

Copy all of the files from /usr/local/courses/java/psfiles into this directory. Edit the file psconfig so that the logdir line points to a directory that you have write access to and is accessible by a browser. Use a complete absolute path name. Edit the user line to include your full name. You must be logged onto a machine on the network using an X environment. Make sure that /usr/local/courses/java/bin is in your path and execute runps.

Specifying an Experiment: Overview

• The experiment file with extension .exp specifies a number of experimental runs. Each run is specified by a base name and a possible list of modifications.
• The experimental run file, which is also called the run file for short, has the extension .run and contains information about the scheduling algorithm to use, the processes to run, and when the processes arrive.

Time

Processes

• Arrival time
• Total CPU time
• CPU burst time distribution
• I/O burst time distribution

Probability Distributions

The following distributions are supported:

• The constant distribution. Example:
  
  constant 23.45
  represents a constant distribution with constant value 23.45.
• The exponential distribution. Example:
  
  exponential 23.45
  represents the exponential distribution with mean 23.45.
• The uniform distribution. Example:
  
  uniform 23.45 47.89
  represents the uniform distribution in the interval [23.45,47.89]

Experimental Runs

name experimental_run_name
comment "experimental_run_description"
algorithm algorithm_description numprocs number_of_processes
firstarrival first_arrival_time
interarrival interarrival_distribution
duration duration_distribution
cpuburst cpu_burst_distribution
ioburst io_burst_distribution
basepriority base_priority

Here is a sample experimental run file that must be stored in the file myrun.run.

name myrun
comment "This is a sample experimental run file"
algorithm SJF
numprocs 20
firstarrival 0.0
interarrival constant 0.0
duration uniform 500.0 1000.0
cpuburst constant 50.0
ioburst constant 1.0
basepriority 1.0

Experiments

In the simplest case, an experimental run can be specified by the name of the run. In may cases, you will want to make several experimental runs in which almost everything is the same, except that one or more parameters are changed. For example, you might want to vary the quantum used for the round robin scheduling algorithm but use the same set of processes.

The simulator allows you to do this by specifying the same experimental run in each case and giving a new value to one or more parameters. The general format for a run line in the experiment file consists of the word run followed by the name of an experimental run, followed by a list of modifications to that experimental run.

The experiment file format is as follows:

name experiment_name
comment "experiment_description"
run run_name1 optional_modification_list1
...
run run_namen optional_modification_listn

Here is an example experiment file that must be stored in the file myexp.exp

name myexp
comment "This experiment contains 3 runs"
run myrun
run myrun cpuburst uniform 10 90
run myrun cpuburst exponential 50

Experimental Run Modifications

Only the simplest case is described here in which the modification applies to all processes in the run.

A modification specification is a string of tokens separated by one of a small number of key words indicating which parameter is to be modified. The key word is followed by parameters specific to the value to be modified. For example, if the value to be modified is a distribution, then a distribution is specified in the format described under Probability Distributions.

Here is a list of the key words and the appropriate parameters:

• numprocs: The parameter is the number of processes to create.
• randomize: The parameter is an integer representing the number of times the random number generator should be called before starting the run. See Random and Not So Random Numbers .
• firstarrive: The parameter is the arrival time of the first process, a floating point number.
• basepriority: The parameter is the base priority of the processes created. Currently this base priority is not used.
• interarrival: The parameter is a string representing the distribution of the interarrival times of the processes.
• duration: The parameter is a string representing the distribution of the total CPU time used by the processes.
• cpuburst: The parameter is a string representing the distribution of the CPU burst times of the processes.
• ioburst: The parameter is a string representing the distribution of the I/O burst times of the processes.
• algorithm: The parameter is a string representing the scheduling algorithm to use. See Scheduling Algorithms Supported.

Scheduling Algorithms Supported

• Round Robin: The user can set the quantum. Processes are removed from the ready queue in the order that they arrive.
• First-Come/First-Served: Processes are taken from the ready queue in the order that they arrived. Once a process is using the CPU, it stays there until its CPU burst expires. It then goes into the I/O waiting queue until its I/O burst expires.
• Shortest Job First: The next process to be removed from the ready queue is the one with the shortest CPU burst time. If there is more than process with the smallest time, the one that arrived first is taken.
• Shortest Job First Approximation: An estimate is made for the next CPU burst time based on the past behavior of the process and the process with the shortest estimated burst time is used. The initial estimate is 0 so new processes have priority. A user-settable parameter, alpha, has a value between 0 and 1. If the last estimate was b, and the last burst time was actually B, the next estimate is alpha*B + (1-alpha)b.

• RR quantum represents the Round Robin algorithm with the given quantum.
• FCFS represents the First-Come/First-Served algorithm.
• SJF represents Shortest Job First scheduling.
• SJFA alpha represents the Shortest Job First Approximation using the given value of alpha.

Configuration

At this time the supported key words are:

• logdir: key value is the directory that will contain the log file
• logfn: key value is the name of the log file
• imagename: the key value is the base name of the GIF file graphs used when graphs are inserted into the log file.
• user: key value is the full name of the user that is inserted into the log file.
• portable: key value is either the word "true" or the word "false" (without the quotes). If true, a portable random number generator is used that allows experiments to be repeated and give exactly the same results.
• run: key value is the name of an experimental run. A file with the appropriate name must be present.
• exp: key value is the name of an experiment. A file with the appropriate name must be present.

logdir /home/myname/public_html/pslogs
logfn logfile.html
imagename gifim
user Steven Robbins
portable true
run myrun
exp myexp

The second table describes the number of processes and their arrival times.

The third table describes the scheduling algorithm to use.

The fourth table is a list of runs corresponding to the one experiment, myexp. Three runs are done each using the base run file myrun. The modified runs are labeled myrun_1 and myrun_2 and the modifications are shown.

Using the Simulator

The leftmost text area is labeled History. When active, it displays various information about the progress of the simulation. It also shows the results of any of the information buttons, some of which are located just below the other text area.

The rightmost text area is labeled Event List. When it is active it shows events are they occur.

Below the Event Log are 6 buttons which display information about processes and events.

• Events: displays all of the events in the event queue.
• Waiting: displays all of the processes waiting for I/O to complete.
• New: displays the processes that have been created but not yet arrived.
• Ready: displays the ready queue.
• Finished: displays the processes that have completed.
• All: displays information about all processes.

To the right of these buttons are three text fields in which the process ID of a process can be entered. When a value is entered, information about that process is displayed in the History text area.

• History: displays the complete history of the process including when it entered each queue and the CPU and how long it was there.
• Waiting: displays totals of waiting time, time in the ready queue, and execution time.
• State: displays detailed information about the process.

Below the scheduling algorithm are various buttons grouped in 5 columns.

The first two columns of buttons give the user finer control of the simulator than previously discussed.

The first column contains buttons related to creating processes with finer control than described in the section on experimental runs. It will not be described here.

The second column of buttons is for running the simulator. Normally these will not be used. Instead, an experiment will be run using the Run Experiment button.

• Next Event: executes one event
• 10 Events: executes 10 events
• 100 Events: executes 100 events
• 500 Events: executes 500 events
• 5000 Events: executes 5000 events
• Run Until Done: executes events until all processes have completed. When events are being run, this buttons changes into Abort which stops the execution of events.

• Graph: All Waiting, Graph: Waiting, or Graph: Completed toggles among the three types of currently supported graphs. The first two graph waiting time and the last graphs the fraction of the processes completed. Graph: All Waiting graphs all selected runs while Graph: Waiting just graphs processes from the most recent run. Normally the first option will be used.
• Draw Graph: draws a graph of the type indicated by the button above. A window pops up containing the graph.
• Add Graph: Adds a graph from the current run to the graph currently displayed. Several graphs can be displayed on the same set of axes. This option is not applicable if Graph: All Waiting is used.
• Save Graph: Saves the current graph in a GIF file on the disk. This is currently not supported.
• Debug: for debugging. Not currently supported.

• Open Log: opens the log file and enables the other logging buttons. This button then changes to Close Log.
  Closing the log and reopening it erases the old log file.
• Start Log or Stop Log toggle between these states and starts or stops the logging process. The log file remains open.
• Log Comment: pops up a window which allows the user to enter a comment in the log file.
• Log All Table Data: creates two tables in the log file containing statistics about all saved data. Data is saved with the button below.
• Edit DataAllows you to select a subset of the saved data to be saved or graphed. See Selecting Data to be Saved or Graphed.
• Save Data Save current statistics so that it can be logged by pushing the above button.

• Exps: expname advances through the experiments that were read in when the scheduler was started.
• Run Experiment runs the experiment corresponding to the above button.
• Create New Run allows you to specify an experimental run and save the specification in a file. This has not yet been implemented.
• Create New Exp allows you to specify an experiment and save the specification in a file. This has not yet been implemented.
• Show Runs displays information about the experimental runs in the History window.
• Show Exps displays information about the experiments in the History window.

Below the buttons are two narrow progress bars showing the progress of the simulation. The first is red and shows the fraction of total CPU time that has been used so far. When the red bar reaches the end, all processes are complete. The second progress bar is blue and shows the fraction of processes that have completed.

Finally, at the bottom of the window are two buttons.

• Reset: removes all processes and initializes all variables. The table data previously saved is not erased.
• Quit: exits the simulator. If the log file was open it is closed.

Random and Not so Random Numbers

There are times in which you run an experiment and want to run it again to look at it in more detail. The option portable true allows you to do this. The simulator uses a portable pseudo-random number generator with a fixed seed so that if the same run is repeated, it should produce exactly the same results. The seed is reset at the start of each run, so that a run is not affected by previous runs.

The option randomize n in the modification list allows the same run to be done with different values of the seed. It causes the random number generator to be called n times after it is initialized. If the same run is repeated with a different randomize value, it can produce different results.

Selecting Data to be Displayed or Graphed

Pushing this button brings up a window containing one line for each run that has been finished. Each line contains the name of a run and two buttons. Pushing the Log button changes it to NoLog and indicates that the corresponding run should not be included. Pushing the same button again resets it. The other button is marked Show. When it is pushed the line disappears from the data editor window. You can show the missing lines by pushing the Show Some button which changes it to Show All. Pushing it again resets it. When finished, you can push the Done button.

Starting the Simulator from Outside the UTSA Network

You will soon be able to run the simulator with logging by using the URL /java/pstest/jar2/PS.html and setting up your system to allow file I/O privileges to this Java code. Currently this requires JDK1.2 and has been tested with JDK1.2beta2.

It is not recommended that you do this at this time due to the security problems involved. These problems will be reduced as the security (breaking) features of Java are standardized.

Once your system is properly set up, you can run the simulator by executing
appletviewer /java/pstest/jar2/PS.html

Instructions for setting up your machine to allow this will be available here shortly.

Eventually, you will be able to do this through a standard browser.