Introduction

Simulation is a powerful tool that can be employed when designing and selecting scheduling algorithms for an operating system. In this project you will implement and perform simulations to compare the scheduling algorithms from two popular flavors of unix: Linux and BSD Unix 4.4.

Assignment

Compare the performance of the credit based time sharing algorithm used by Linux to schedule processes in its OTHER queue to the multilevel feedback queue algorithm used by BSD unix 4.4. Implement these algorithms so that they work as they were described in class.

You will complete this project in 4 phases:

1. Project Proposal (10% Due: 4/4/02)
2. Simulation Development (30%)
3. Paper Submission (20% Due: 4/23/02)
4. Paper Revisions (40% Due: 5/2/02)

More details on each of these phases is provided below.

Project Proposal

Your project proposal must describe and justify the simulations you intend to perform and metrics you intend to use to make performance comparisons between the Linux and BSD schedulers. Be sure to include experiments and metrics that compare how these schedulers behave for collections of I/O bound processes, collections of CPU bound processes and various mixes of CPU and I/O bound processes. You should also consider process mixes designed to evoke the best and worst performance from each of the algorithms. I anticipate that good proposals will be 1 to 2 double spaced, type written pages. I will read and return your proposals with comments that you should ultimately integrate into your project. If necessary you may be asked to revise and resubmit your project proposal.

Simulation Development

You will be implementing the Linux and BSD schedulers using the simulation framework provided below. This simulation framework accepts as input a specification of a collection of processes. The framework then simulates the system calls and interrupts that an OS kernel would receive when executing the specified processes. The following sub-sections provide an overview of the simulation framework.

Downloading the Simulator

In order to execute the simulator you will need to download each of the following Java files:



• SystemDriver.java
• SystemTimer.java
• Event.java
• EventQueue.java
• Process.java
• ProcessOperation.java
• Kernel.java

You should also download the following data files to help you get started:



• processes.dat
• process1.dat
• process2.dat
• devices.dat

Compiling the Simulator

To compile the simulator use the command:

javac *.java

Running the Simulator

The general form of the command line to run the simulator is:

java SystemDriver <processes file> <device file> <scheduler type>

The command line parameters have the following effects:



<processes file>

Filename of a file containing a list of the files that describe the processes to be executed by the simulator. For example, the file processes.dat contains two (non-comment) lines indicating that the processes in the files process1.dat and process2.dat should be executed by the simulator. Lines beginning with # are comments and blank lines are ignored. The format of the files for each process is described below.



<device file>

Filename of a file containing a list of the devices that the system supports. For example the file devices.dat contains lines indicating three I/O devices and two Queue devices. Each (non-comment) line in this file specifies one device. Such a line must begin with either I/O or Queue to indicate the type of device and must conclude with the name of the device. Device names may not contain spaces. Lines beginning with # are comments and blank lines are ignored.



<scheduler type>

The type of scheduler to use when scheduling the processes. Currently the system only supports "FCFS" scheduling. You will be adding the "LINUX" and "BSD" schedulers as part of this project.

To run the simulator with the datafiles downloaded above use the command line:

java SystemDriver processes.dat devices.dat FCFS

If you successfully downloaded and compiled all of the above files the output of the program will appear as:

System Time: 385 Kernel Time: 30 User Time: 300 Idle Time: 55 CPU Utilization: 77.92%

This output indicates that the execution of the processes listed in the processes.dat file required a total of 385 time units. 30 of those time units were spend performing kernel operations, 300 were spent performing user operations and for 55 time units there were no runnable user processes and the Idle process was executed.

The Process Data Files

Each file listed in the file specified by the <processes file> command line parameter describes a single process to be executed on during the simulation. The syntax of these process data files is documented in the process1.dat file which appears below. Lines beginning with # are comments and blank lines are ignored.

# Process name: must be unique among all # processes for any given simulation. PROCESS1 # Process arrival time: 0 # Process profile. This must begin with # START and end with EXIT. In between # the lines may be: # CPU <time> # IO <device> <time> # WAIT <queue> # NOTIFY <queue> # NOTIFY_ALL <queue> START CPU 100 IO DISK1 100 CPU 100 EXIT

This process1.dat file describes a process named PROCESS1. Each process in a simulation must have a unique name. PROCESSS1 arrives in the system at time 0. This means that the system call for creating PROCESS1 will occur at time 0. PROCESS1 then goes on to have a CPU burst of 100 time units, followed by an I/O burst on DISK1 of 100 time units, followed by a final CPU burst of 100 time units. PROCESS1 is an example of a very simple process. It is likely that you will use several simple processes such as this to verify that your scheduling algorithms are working correctly. For example, I used the process1.dat and process2.dat processes that you downloaded when testing the simple FCFS scheduler. However, when performing the comparisons of your scheduling algorithms it is likely that you will want significantly more complex and lengthy processes.

The Kernel Class

All of the programming that you will need to do for this project will take place in the Kernel class. The Kernel class that is provided implements a simple FCFS scheduling algorithm and is capable of supporting only a single I/O device. You will need to modify this Kernel to implement the Linux and BSD schedulers and also to handle multiple I/O devices and Queues.

The methods in the Kernel are called by the the SystemDriver and other classes provided above. These other classes read the device and process data files and make calls to methods in the Kernel class to simulate the system calls and interrupts that would occur when executing the processes. The Kernel class contains one constructor and four methods that are used by the SystemDriver and the other classes. The purpose and use of each of those methods is discussed below:



public void systemCall(int callID, String param)

The kernel's systemCall method will be invoked when the system requires the services of the kernel. More specifically the systemCall method is invoked under three different circumstances:



1. At startup the SystemDriver invokes the systemCall once for each device or queue listed in the <devices file>. These system calls are indicated by callIDs of MAKE_DEVICE and MAKE_QUEUE. The kernel must respond to these system calls by creating a waiting queue for the device or queue. The param will contain the name of the device or queue as it was indicated in the <devices file>.
   
   
2. When a new process arrives in the system (as indicated by the arrival time in its process data file) a system call will be generated with callID of START_PROCESS. The param will contain the name of the new process as was indicated in the process' data file. The kernel must respond to this system call by creating a new PCB for the process and adding the new PCB to the appropriate location in the ready queue.
   
   
3. Each time the currently executing process would generate a system call the systemCall method will be invoked with the appropriate callID and param. When a process makes an I/O request (IO_REQUEST) or a request to wait on a Queue (WAIT), the PCB for that process must be moved to the end of the waiting queue associated with the I/O Device or the Queue. For simplicity, the waiting queues for both the I/O devices and the Queues should be FIFO queues. When a process notifies a Queue (NOTIFY) the process that has been waiting on that Queue the longest should be moved to the appropriate location in the ready queue. When a process notifies all processes in a Queue (NOTIFY_ALL) all processes waiting on that Queue should be moved to the appropriate locations in the ready queue. Finally, when a process exits (TERMINATE_PROCESSits PCB should be removed from the system.

The following table summarizes all of the callID and param values that may be passed to the systemCall method:

callID: param: ---------------------------------- MAKE_DEVICE Device ID MAKE_QUEUE Queue ID START_PROCESS Process Name IO_REQUEST Device ID WAIT Queue ID NOTIFY Queue ID NOTIFY_ALL Queue ID TERMINATE_PROCESS null

public void interrupt(String deviceId)

The kernel's interrupt method is invoked under two conditions:



1. Each time one of the I/O devices in the system completes an I/O operation the interrupt method is invoked with the deviceId parameter set to the name of the device that generated the interrupt. The kernel must remove the PCB from the head of the device's waiting queue and move it to the appropriate location in the ready queue.
   
   
2. The interrupt method is invoked at a regular interval by the system timer device (every 50 time units of user time). When invoked by the timer the deviceID will be set to the string TIMER. The kernel should use these interrupts to implement the Linux and BSD scheduling algorithms.




public String running()

The running method must return the name of the process that is currently in the running state. If no process is currently ready to run this method should return the string "Idle" indicating that the CPU is idle. This information is used by the simulator to credit execution time to the correct process.



public void terminate()

The terminate method is called automatically when all of the processes in the simulation have completed. The kernel should use the terminate method to calculate and report the statistics necessary for comparing scheduling algorithms.

You may add additional methods to the Kernel class for your own use. However, the methods described above must exist and must perform the indicated operations.

The SystemTimer Class

When the Kernel is constructed it is passed a reference to an object of type SystemTimer. This object contains four public methods that will be useful for computing the statistics you will need to compare your scheduling algorithms. These methods are:



getSystemTime()

This method return the number of time units that have elapsed since the simulation has begun.



getKernelTime()

This method returns the number of time units that the CPU has been dedicated to kernel operations such as processing system calls and handing interrupts.



getUserTime()

This method returns the number of time units that the CPU has been dedicated to processing user operations.



getIdleTime()

This method returns the number of time units that the CPU has been idle.

Paper Submissions

The paper for this project will be in the form of a scientific journal article. Your paper should be divided into 5 sections as follows:

1. Introduction

The introduction of your paper should present and discuss the question that is being investigated. Give the reader sufficient information to understand what it is you are investigating and why it is worth investigating.

2. Background

This section should contain a description of the Linux and BSD schedulers and the metrics you will be using for evaluation. Your description of the schedulers should describe the anticipated strengths and weaknesses of each scheduler (e.g. the types of processes they favor, etc...). Your descriptions of the metrics should include a discussion of the types of processes/systems to which they are most applicable. You should break this section into sub-sections as appropriate.

3. Methods

In this section you will describe the general structure of the experiments that you have conducted. I suggest one sub-section for each unique experiment. In each sub-section, clearly explain the purpose of the experiment and outline the types and numbers of processes used and specify the metrics that will be used for evaluation. It is not necessary to give an exact specification of the processes in this section.

4. Results

In this section you will give very specific information about the types and numbers of processes that you have used and provide values for the statistics that were collected and the metrics that were calculated. Based on this section and the previous section, a sufficiently knowledgeable reader should be able to reproduce your results. As with section 3, one sub-section for each experiment would make good sense here.

5. Discussion

In this section you will summarize your results and draw conclusions about the schedulers. You should focus on conclusions that integrate the results from multiple experiments. Also, discuss any inconclusive results as well as any strange or unexplained results. You should also discuss any possibilities for further work that would help to make your results more conclusive or would help to clarify inconclusive, strange or unexplained results.

If you would like to see an example of a paper in this format, here is a paper that I have written: "Investigating Chaos as a Source of Innovation in a Simple Model of a Co-Evolutionary System" in pdf format.

Paper Revisions

Details of the revisions that are necessary will be provided when the draft of your paper is returned.