Today : Sun, 05 Jul 20 .


CS537 Student Wiki


Writing

Homeworks

Sections

Projects

Project Discussion

edit SideBar

Project2

Page: PmWiki.Project2 - Last Modified : Mon, 26 Oct 09

Project 2: Scheduling Simulation

This project entails writing a simulator for experimenting with scheduling algorithms. This project will be done in groups of 3. The project is due on Tuesday 10/27 at 9 pm, and the write-up is via email to the TA on Thursday, 10/29 at 9 pm .

Notes

  • Monday 10/26: You can hand in the code in the p2 directory for any of your team members; please do not put it in more than one directory, and please make sure your readme file says who your team members are.
  • Monday, 10/26: For the average wait time of all processes, you should average the total waiting time (time spent on the ready queue) for all processes.
  • Monday 10/26: Some clarifications based on questions from office hours. First, shortest job first should consider only CPU burst length, and not the total remaining CPU time. Second, when I said that you don't need to do scheduling when I/O completes, it means that you don't need to preempt the running process. You will need to have code that runs to move the job from the I/O wait queue to the ready queue. Third, I/O can be concurrent. So, if you have I/O that starts at time 1 ms, 2ms, and 3 ms and takes 5 ms, then the I/O completes at times 6 ms, 7 ms, and 8 ms.
  • Monday, 10/26: People have asked about the input for multi-level feedback queues. You can assume that the input is in order, starting at the lowest priority and going to the highest. Low priorities are lower numbers, high priorities are higher numbers. The lowest possible priority is zero, the highest will be 127. The data in each row will be correctly formatted (don't worry about handling bad inputs), and the numbers will be separated by one or more spaces, with possible extra spaces at the end of the line.
  • Sunday, 10/25: People have observed that the list sample code leaks memory because queue_add_fifo() calls malloc(), but the memory is never freed. I have put up new sample code that shows how to free the memory.
  • Sunday 10/25: Several people have observed that their code is very slow. There are two reasons I've seen. one is running out of memory (see above). The second is if you are counting every cycle when nothing changes; it is better to calculate when the next event occurs, and fast forward to that time.
  • Friday, 10/23: People have asked about report format. A sample report for a different project from a past semester can be found here.
  • Thursday 10/22: there may be rounding error when computing burst length: the product of burst length and the number of I/O operations may not add up to the total CPU time the process executes for. You have two options: before a process terminates, have its last burst consume any remaining CPU time; or ignore the problem and execute for less than the total time. Either one is o.k., but you must document your choice and use it consistently. For the first choice, your code would look something like this: last_burst_length = cpu_time - (burst_length * io_count);
  • Tuesday 10/13: I clarified the project description a bit and removed all references to virtual memory. This is just a scheduling simulation. In addition, I relaxed the design requirements: they are really just suggestions of how you should approach the project and organize your groups, but are not requirements.

Goals

The goals for this project are to:

  • Get experience with scheduling policies
  • Get experience with writing simulation
  • Get experience with software engineering techniques

Project Overview

Your primary goal for this project is to implement and experiment with scheduling policies. To do this, you will write a scheduling simulator. It will read in a set of data files specifying the arrival time, CPU time, and I/O count for a set of processes. It will simulate a number of scheduling policies on those programs.

As input, you will receive scheduling traces traces. Support code for parsing these files is available in ~cs537-2/public/Projects/P2/537-parse.c, 537-parse.h. Test code for parsing is in test.c. Feel free to copy and modify this code.

Scheduling Traces

Scheduling files contain a trace of process start time, CPU time, and I/O count. The format of these files is illustrated below:

  xlogout       0          8.58      102720
  login.kr      3          1.36      137024
  rm            4          0.03      96

The format is:

 Program  Start time    CPU time   I/O Count
 name   (in seconds) (in seconds) 

This trace indicates that xlogout started at time 0, required 8.58 CPU seconds to execute, and issued 102,720 I/O operations. The login.kr program started at time 3, required 1.36 CPU seconds to execute, and issued 137,024 I/O operations.

The trace is in order, meaning that each process has a start time later than or equal to the previous start time.

Code for parsing this file will be provided with the functions open_sched_trace(), close_sched_trace() and get_next_process().

The traces are available in the ~cs537-2/public/Projects/P2 directory and are named "p2sched.small", "p2sched.medium", and "p2sched.large".

Simulating scheduling

You will need to simulate a simple scheduling algorithm that allows programs to alternate running. You should assume that programs execute until they wait for I/O, and I/O occurs even spaced. Thus, if a program runs for 10 seconds and does 10 I/O operations, it executes for 1 second, then waits, then executes for one second. All I/O operations take 5 ms.

For this project, you will implement a variety of scheduling policies. For policies that have a time quantum (the length of a scheduling time slice), your simulator should take as input the length of the time quantum in milliseconds.

Your scheduler will keep track of the current time in terms of microseconds.

Your scheduler should run (1) when the curent quantum expires, to decide whether to context switch the process, and (2) when a process blocks on I/O, as described above. You do not need to run your scheduler when I/O completes.

Context switching should take 1 microsecond.

The scheduler should pick the next process to run and then account for the time it runs before blocking. When a process completes its run time, it terminates. Like a real scheduler, your simulated scheduler must keep track of which process is running, which are ready, and which are blocked.

Your simulator should maintain the current time (e.g., the number of microseconds since the simulation started). A process from the trace should be put in the ready queue (or run) when the current time equals the start time in the scheduling trace file.

The scheduler should report elapsed time (time between when it started and when it completed) for each process. In addition, at the end of the simulation (when all processes have completed), it should report the total number of microseconds where something was executing and the number of microseconds where no process was executing (i.e., there was nothing runnable). It should also report the amount of time lost to context switching (i.e., the number of context switches times the cost of a context switch).

You should experiment with quanta values of 1 millisecond, 10 milliseconds, and 100 milisseconds.

Code for managing and manipulating linked lists is available in ~cs537-2/Projects/p2/list.h, list-sample.c. Feel free to copy and modify the code.

Write-up

You should write a 3-5 page document describing your system and explaining your results. You should explain the architecture of your simulator: what are the components, what are the interfaces between components, and why you chose this deisgn. In addition, you should document policy decisions you made, such as:

  • Do new processes go at the head of the ready list or the end?
  • Do processes end with I/O or do they end with computation?

This is not a complete list -- you should include any policy decisions you made.

You should present two sets of experiments. For each one, you should present your results graphically (e.g., with a chart):

  • Scheduling with each policy
  • Varying the time quantum for round robin. Show the difference that the time quantum has on wait time and overhead. You should present the results of your simulations with the three quantum values (1 millisecond, 10 milliseconds, and 100 milliseconds).

Methodology

This project will be done in groups of three. For the last two projects, you were free to organize the work however you liked. For this project, you must decide an architecture and division of labor in advance.

Week 1

In the first week of the project, you should design your simulator, figuring out what the major modules are and what they do. You should write a specification of the interface to each module. For example, you may have a scheduling module that decides which process is running, a page table module that tracks which pages are in memory, and a memory simulator modue that simulates each memory reference. You need to write the interface, in terms of what functions they provide and what structures they use, to each of the interfaces so that other members of your team can program against the interface before it has been implemented. Simulator speed is important: if you use inefficient algorithms or data strctures, it may take days for your simulations to run. For this reason, you should think about how you will efficiently maintain implement each module. Consider the complexity (linear, quadratic, exponential) of each piece of your simulation as part of the design.

In addition to specifing the interface, you should create a division of labor that includes (at least) these roles: Programmer for each module: the person who writes the code. Tester for each module: the person who writes test code for the module. Experimenter: the person who runs the experiments for the paper After the first week, each team will meet with an instructor to discuss their design.

Week 2

After the second week, you should have a working scheduling simulator that simulates just the scheduling traces, ignoring memory simulations. You should also have an working memory trace simulator, that keeps track of what is in memory and can report the number of page faults experience by a memory trace. You do not need to implement any specific replacement policy here.

Project Specification

The command line for your simulator should be:

  sched-sim  quantum  policy trace-file

where

  • quantum is the number of cycles in a scheduling time slice.
 * policy is one of "fcfs", "sjf", or "rr" and indicates which scheudling policy to use.
  • trace-file is the name of the scheduling trace file

The output of the simulator should be:

  • For each process, the average wait time (average time in the ready queue after the start of a burst) and completion time (time between when process is created and completes).
  • For the entire simualtion, the average wait time of all processes.
  • The total time spent context switching

The simulator should handle these events:

  • Process creation
  • Timer interrupt for time slices

The costs of events for the simulation are:

  • Context switch: 1 microsecond

Other overheads, such as running the scheduler or handling a page fault, need not be considered.

You should experiment with quanta values of 1 ms, 10 ms, and 100 ms.

You should run experiments with first-come, first-served, shortest job first, and round robin scheduling. Only the round robin scheduling uses preemption.

Hints

Here is some linked list code that may be helpful for managing queues. Here is example code that uses it. Create a PCB structure for each running process, that records statistics about that process

What to turn in

Turn in your code and writeup to the directory ~cs537-2/handin/P2 by the specified due date for the code.

Grading Policy

  • 35% does it work -- we will run it on traces to make sure it computes the correct runtime and number of page faults.
  • 20% code quality -- is the code clearly written, well structured and documented, and does it handle possible errors appropriately.
  • 20% writeup -- do you clearly explain the design of your system, clearly present your performance results, and clearly explain the differences between different algorithms, memory sizes, and quantum size.
  • 25% group grade -- did you work well with your group?

Extra Credit

For 15% extra credit, implement the Solaris table-driven multilevel feedback queue. As input, you should take a table of table entries in the following format:

  priority-level time-quantum expired-prio wakeup-prio max-wait wait-prio

Find settings that achieve good response time for I/O bound programs (frequent I/O operations) but that provide low overhead (few context switches).

To implement this feature, add a new policy to your simulator:

  mlfq policy-file-name

If this is specified, the next parameter should be the file containing the policy table.

This page may have a more recent version on pmwiki.org: PmWiki:Project2, and a talk page: PmWiki:Project2-Talk.


Powered by PmWiki
Skin by CarlosAB

looks borrowed from http://haran.freeshell.org/oswd/sinorca
More skins here


PmWiki can't process your request

Cannot acquire lockfile

We are sorry for any inconvenience.

More information

Return to http://pages.cs.wisc.edu/~swift/classes/cs537-fa09/wiki/pmwiki.php