EE 463 Operating Systems Date: 03/07/1439

Spring 2018 Term Project 20/03/2018

Dr. A. M. Al-Qasimi Due: 30/04/2018

Objectives
The purpose of this programming project is to gain some experience involving the design of a
few OS components by simulation. These components include CPU management and
scheduling, process management, system queues, system statistics gathering and reporting.

Project Summary
Students work in groups of two or three, to write a simulation program in Java for testing the
performance of their designs of a few CPU scheduling algorithms for a simple computer with
limited HW / SW system, then report their findings, conclusions, and suggest improvements.

System Description
1. The Available Hardware
a. A single CPU.
b. One I/O Device.
c. Unlimited amount of Main and Secondary storage.
d. System Timer and all necessary support.

2. The User Processes

All processes created in this system fall under any one of the following types:
Type-1: Consists of:
10 CPU bursts of the following lengths: (1,2,1,1,1,3,1,2,2,1) Time Units,
9 I/O bursts of the following lengths: (6,4,10,3,5,3,2,10,6) Time Units.

Type-2: Consists of:

15 CPU bursts of 50 Time Units each, and
14 I/O bursts of 150 Time Units each.

Type-3: Consists of:

12 CPU bursts of 1000 Time Units each, and
11 I/O bursts of 5 Time Units each.

Type-4: Consists of:

A repeated pattern of (CPU, I/O1, Think, I/O2), where:
Each CPU burst takes 3 Time Units,
Each I/O1 burst takes 3 Time Units,
Each I/O2 burst takes 10 Time Units,
Think time takes 60 Time Units.

Any one of the types above can be created at any time. Type-4 has a maximum of N
instances. No new processes of this type can be created after this limit. Processes of Type-1
to Type-3 terminate after executing their last CPU burst, while processes of Type-4 never
terminate, they cycle through their pattern forever. Assume that a process in its think period
stays out of the Ready Queue, say in a special list.

Dr. A. M. Al-Qasimi EE463 Term Project – Spring 2018 Page 1 of 6

3. The Operating System Components
The OS supports multi-programming and priority-based, pre-emptive CPU-scheduling. Each
of the following OS components shall be written by the students participating in this project,
according to the specifications given for each component below:
a) A modularly designed generic CPU Scheduler that supports a number of short-term
scheduling algorithms including, FCFS, SJF, RR, MLFQ (Multi-Level Feedback Queue of
n-levels) and -- for extra credit -- lottery (more about this is given below). Assume
that the particular scheduling algorithm to be used in any simulation run is given as an
input parameter on the command-line.
Other parameters that are required for a particular scheduler, depends on your design,
such as the number-levels of MLFQ, time-quanta, … etc. These are part of your
design decisions and they shall be saved in a suitable data-structure for fast access
during execution. In particular, designing RR, MLFQ and lottery, you would choose the
parameters and data structures to satisfy your goals which must be to achieve the best
system performance possible.
b) A Supervisor, its job is to control all system operations, including the timer functions,
interrupt handling, preemption decisions, …etc.
c) A Dispatcher, its job is to do the context switching and assign the CPU to the process
selected by the CPU scheduler.
d) A Creator, is responsible for creating new processes of a given type. This is done by
creating their PCBs and putting them in the ready queue.
e) A Terminator, is responsible for terminating finished processes by removing their PCBs.
f) An I/O Monitor, it is responsible for monitoring the processes completing their I/O. It
generates an I/O Completion interrupt to the CPU each time a process finishes its I/O
burst. For simplicity of simulation, it also takes the process's PCB to the ready queue.
g) The Job Generator, its purpose is to generate new jobs and select their types
randomly, then, calls the creator to create their PCBs and enter them into the system.
Job types are selected using an integer random number generator in the range [1,4]
that has a uniform distribution over that range. The Java rand() function can be used.
Jobs are assumed to arrive randomly according to Poisson distribution with an
expected value, v, in the range [0,1] provided to the program at run time. Use the
following Poisson generator at each time step to get the number of new jobs to be
created at that time step, then use the random number generator, rand() to get its type.
h) The Poisson Generator: Given an expected value, v, it generates a random integer to
be used in the simulation, such that the expected value and Poisson distribution are
satisfied. It is assumed that you already seeded the random number generator.
int poisson (double v) {
double x, em;
int n;

em = Math.exp(-v);
x = rand(); // returns 0 < x < 1
n = 0;
while (x > em) {
n++;
x *= rand();
}
return n;
}

Dr. A. M. Al-Qasimi EE463 Term Project – Spring 2018 Page 2 of 6

 i) A Statistics-Collecting Module, used to keep record of important information about
the system and report the following statistics about the simulation run:
1- The total number of time-units used.
2- The total number of jobs created.
3- The total number of each job-type created.
4- The total number of each job-type terminated.
5- The Maximum, and Average queue-lengths for each of the queues in the system.
6- The Minimum, Maximum, and Average response-times for jobs of Type-4 only.
7- The Minimum, Maximum, and Average turnaround-times for each job type other
than Type-4.
8- The Minimum, Maximum, and Average turnaround-times for all jobs other than
those of Type-4.
9- The total system throughput for jobs of Type-1 to Type-3.
10- The Minimum, Maximum, and Average of CPU-overhead-time.
11- The Percentage of CPU-idle-time.
12- The Percentage of CPU-utilization.

4. Assumptions
a) The CPU context-switching time takes 0.1 Time Units. i.e. each 10 take 1 time uint.
b) The SVC-start-I/O-interrupt takes 2 Time Units.
c) I/O-completion-interrupt takes 3 Time Units.
d) Job-scheduling overhead takes 1 Time Unit.
e) All other supervisor activities take 1 Time Unit per call.
f) The time-quantum of RR is left for each group to decide.
g) The MLFQ design parameters as given in class are left for each group to decide.
h) When the MLFQ is used, all processes are initially entered into the first level queue.
i) The response-time is defined for Type-4 jobs only, as the total time period spent from
the end of I/O2 operation to the start of I/O1 operation. This includes the CPU-burst time,
CPU-overhead and all queue delays during this period.

What to do
Write a Java program to simulate the above system. The input to the program should be
through command-line parameters as follows:
1. The total number of time steps for the run, S, integer > 100; default = 100.
2. The ready queue type, integer, 1:FCFS, 2:SJF, 3:RR, 4:MLFQ, 5:lottery; default = 1.
3. The minimum quantum size, Q, to use as a basis of RR and MLFQ, integer > 0; default = 1.
4. The maximum number of Type-4 jobs, N, integer [0 .. 100]; default = 5.
5. The expected number of new jobs arriving per time unit, v, double [0 .. 1]; default = 0.5.
6. If implemented, the minimum number of tickets, t, integer > 0; default = 5.
7. If implemented, the maximum number of tickets, T, integer > t; default = 100.
8. If implemented, the speed of giving/taking tickets, c , multiple of Q, integer > 0; default = 0.

Choose an appropriate value for Q and v, Let N=20 and S=100,000 and run your program 5
times using the same values of Q, v, N, and S but each time with a different Queue type. Also, if
implemented, choose suitable values for lottery parameters, t, T and c. Show the contents of all
system queues, only for the first 20 time steps. After each run, your output should also show all
your input values, the queue type used, and all the statistics reported by the statistics-collecting
module.

Dr. A. M. Al-Qasimi EE463 Term Project – Spring 2018 Page 3 of 6

Discuss the statistics coming out of the five runs as to the effect of the scheduling algorithm,
quantum time, job types and their numbers, the expected value, and so on.

What to turn in
Your project shall be submitted through Moodle in two parts:
• A progress report is due on Monday 09/04/2018, at 11:59 pm sharp.
• A final full report is due on Monday 30/04/2018, at 11:59 pm sharp.
Your first submittal shall include the following items:
1. Your design document for the simulator. This is an important project document. It shall
include your overall system design, architecture and queuing diagram(s), your design
decisions with justification, all non-trivial algorithms and formulas, all required data
structures, and a detailed description of each function / method, that includes: its
purpose, inputs, outputs, preconditions, author and the date of last modification.
2. A project assignment schedule showing which part(s) of the project is/are assigned to
which team member and for what period of time.
3. A brief, two-page memo, summarizing the current state of the project, including: finished
parts, parts you are still working on, parts not started yet and any difficulties or problems
still not resolved (other than the usual excuses like, we had exams, computer problems,
…etc.).

Your final report shall be in one .zip file as described in item 7 below. The final report shall
include the following items:
1. The final updated version of your design document, including any critical changes you
have made since the first report and the reason(s) for the change.
2. The revised project assignment schedule showing which part(s) of the project is/are
done by which team member.
3. The program outputs of the five runs.
4. A discussion of the results of your simulation including your observations, your
conclusions and your suggestions of any possible improvements.
5. A PowerPoint presentation for your part of the project – One presentation per student.
6. A README .txt file that describes:
a. What are the difficulties, if any, that negatively affected your project outcome.
b. What requirements that you designed and realized.
c. What requirements that you designed but failed to realize, and why.
7. One .zip file containing the compressed files of your project as follows:
a. Source programs: Only .java file(s), fully documented and commented. No
executable or .class files. You must submit a clean set of files, no messy files in the
.zip file please! I will copy them to my computer and build the executables using your
source files only and run them there. So, please test your files thoroughly before you
submit them. Please note that I use Java JDK 8.
b. Your cover-page and all the documents from items 1 to 4 in .pdf form.
c. Your project presentation in .ppt form.

8. You will be asked to present your work in the project in class. To be scheduled later.

Dr. A. M. Al-Qasimi EE463 Term Project – Spring 2018 Page 4 of 6

Grading the project
The intent in grading this project is to identify those students who (i) don't do the assignments
and/or the labs (ii) don't think carefully about the design, and therefore end up with a messy and
over-complicated solution. You need to do a careful design and implementation of the project.
Remember that you can't pass this course without at least making a serious attempt at this
project assignment. Doing this project properly provides a test-bed for other OS components not
done in this project by expanding it to include them, such as memory management, file system,
… and so on.
The grade for this project will be divided as follows:
• 10% for a meaningful, acceptable progress report showing a real, time-relative progress.
• 15% for a well written, detailed and clear design document and README file.
• 30% for the complete and working implementation, i.e. the simulator.
• 20% for a well organized, clear and meaningful test report.
• 15% for a clear, well documented and commented program.
• 10% for a well organized and clear presentation.

Important
1. We have given you a relatively long time period to complete your project. Should any
group submit a broken program or a non-working implementation, and no sensible
design, this will only show that the whole group is incompetent, careless or did not work
hard enough to successfully complete their project. Therefore, their entire project is
worthless and will not be evaluated. Such a group (if any) will receive zero (0) for the
project.
Please … Do not be that kind of a group.

2. All requirements must be submitted on the due dates. No late submittals will be
accepted at all.

Do not worry too much. Start working early and Enjoy. Good Luck.

Dr. A. M. Al-Qasimi EE463 Term Project – Spring 2018 Page 5 of 6

A Lottery Scheduler
A lottery scheduler assigns each process some number of tickets, and then randomly draws a
ticket among those allocated to ready processes to decide which process to run. That process
is allowed to run for a defined time quantum, after which it is interrupted by a timer interrupt,
and the process is repeated. The number of tickets assigned to each process determines both
the likelihood that it will run at each scheduling decision as well as the relative amount of time
that it will get to execute. Processes which are more likely to get chosen each time, will get
chosen more often and thus, will get more CPU time.
One goal of best-effort scheduling is to give I/O-bound processes both faster service and a
larger percentage of the CPU when they are ready to run. Both of these things lead to better
responsiveness, which is one subjective measure of computer performance for interactive
applications. CPU-bound processes, on the other hand, can get by with slower service and a
relatively lower percentage of the CPU when there are I/O-bound processes that want to run.
CPU-bound processes need long CPU time, but they can get most of it when there are no ready
I/O-bound processes. One easy way to accomplish this in a lottery scheduler is to give I/O-
bound processes more tickets – when they are ready, they will get service relatively fast, and
they will get relatively more CPU than other CPU-bound processes.
To determine which processes are I/O-bound and which are CPU-bound, look at whether or not
processes block before using up their time quantum. Processes that block before using up their
time quantum are doing I/O and are therefore more I/O-bound than those that do not. On the
other hand, processes that do not block before using up a time quantum are more CPU-bound
than those that do.
So, one way to make the system more responsive is to start every process with some specified
number of tickets. If a process blocks before using up its time quantum, give it another ticket (up
to some set maximum, say 10). If it does not block before using up its time quantum, take a
ticket away (down to some set minimum, say 1). In this way, processes that tend to do
relatively little processing after each I/O completes, will have relatively higher numbers of tickets
and processes that tend to run for a long time will have relatively lower numbers of tickets.
Those that are in the middle will have medium numbers of tickets.
This algorithm has several important parameters: time quantum, minimum and maximum
numbers of tickets, and the speed at which tickets are given and taken away.
You can use one queue that contains all of the user processes, each of which has some
number of tickets.
The default number of tickets for a new process is 5. However, processes can add or subtract
tickets by calling setpriority(ntickets), which will increase the number of tickets by ntickets
(a negative argument will take tickets away).
Each time the scheduler is called, it should randomly select a ticket (by number) and run the
process holding that ticket number. Clearly, the random number must be between 0 and
nTickets-1, where nTickets is the sum of all the outstanding tickets. You may use the rand()
call to generate random numbers and the srand() call to initialize the random number
generator. A good initialization function to use would be the current system time.
For dynamic priority assignment, your lottery scheduling algorithm should decrease the
number of tickets a process has by 1 each time it receives a full quantum, and increase its
number of tickets by 1 each time it blocks without exhausting its quantum. A process should
never have fewer than 1 ticket, and should never exceed its original (desired) number of tickets.
See references for lottery scheduling in the course web site or search for that in the Internet.

Dr. A. M. Al-Qasimi EE463 Term Project – Spring 2018 Page 6 of 6