In This Project We Are Going To Build A Discrete Time Event Simulator For A Number O 2892408

This project is going to take a good amount of work and time, so please start early. You would not be able to
finish if you start few days before the due date. Late submissions would incur a penalty of 20% per day for
up to 2 days, then they will not be accepted. Leave the last few days for documentation, further testing and
formatting the results. Please read the description carefully and come see me (hopefully early) if you have
any questions. You may discuss this project with other students. However, you must write your code and
your report on your own.
1 Overview
In this project, we are going to build a discrete-time event simulator for a number of CPU schedulers on a
single CPU system. The goal of this project is to compare and assess the impact of different schedulers on
different performance metrics, and across multiple workloads.
1.1 CPU Scheduling Algorithms
We are going to implement the following scheduling algorithms that we discussed in class:
1. First-Come First-Served (FCFS)
2. Shortest Remaining Time First (SRTF)
3. Highest Response Ratio Next (HRRN)
4. Round Robin, with different quantum values (RR)
1.2 Performance Metrics
We are interested to compute the following metrics, for each experiment:
• The average turnaround time
• The total throughput (number of processes done per unit time)
• The CPU utilization
• The average number of processes in the ready queue
2 The Simulator
The simulator needs to generate a list of processes. For each process, we need to generate its arrival time and
its requested service time. We can assume that processes arrive with an average rate ? that follows a Poisson
process (hence exponential inter-arrival times). The service times are generated according to an exponential
distribution. We will vary ? to simulate different loads while keeping the average service time fixed. The
simulator should stop after processing 10,000 processes to completion (without stopping the arrival process),
then it should output the statistics (i.e., the metrics above).
Events (e.g., process arrival, process completion, time-slice) that occur causes the simulator to update its
current state (e.g., cpu busy/idle, number of processes in the ready queue, etc.) To keep track and process
events in the right order, we keep events in a priority queue (called “Event Queue”) that describes the future
events and is kept sorted by the time of each event. The simulator keeps a clock the represents the current
time which takes the time of the first event in the Event Queue. Notice that when an event is processed
at its assigned time, one or more future events may be added to the Event Queue. For example, when a
process gets serviced by the CPU, another process can start executing (if one is waiting in the ready queue)
Page 2 of 4
CS4328 (Mina Guirguis ): Project #1 4 SUBMISSION DETAILS
and under FCFS, we know exactly when this process would finish (since FCFS is non-preeptive), so we can
schedule a departure event in the future and place it in the event queue. Notice that time hops between
events, so you would need to update your simulator clock accordingly.
The simulator should take few command-line arguments. The first is to indicate the scheduler, a 1
through 4 value based on the list above. Also, it should take other arguments such as the average arrival
rate, the average service time and the quantum interval (for RR). Running the simulator with no arguments,
should display the parameters usage.
Each scheduler would need to maintain a queue (the “Process Ready Queue”) for the ready processes
that are waiting for the CPU. A scheduler will select a process to run next based on the scheduling policy.
Clearly, this queue should not be confused with the Event Queue that is used to hold events to be processed
in the future.