1 Hand-in 1. The design of the classes. 2. Run two programs one by - - PDF document

1

CMPT 300 All three Sections Project 2 Due: April 3, 2002, 430 pm In this project, a group of students (2-3 students per group) are asked to design and implement a simulation of a tiny operating system TOY-OS. The grading will be based on your written answers to questions posed in each of the following tasks, a technical report and a demo. You have 10-15 minutes to showcase your system and answer questions from TA. The marks assigned the project will be distributed as specified within this document. However, software (and personnel !) failures during the demo will result in marks deducted from the overall project. The hand-in of Tasks 1-3 should be clear and brief, while the technical report should be comprehensive. A virtual computer TOY: In virtual computer TOY, the time unit is called tick. There are only three kinds of instructions as follows.

• RUN: keep CPU busy for 1 tick.
• IO: do an I/O operation. It keeps the CPU busy for 1 tick and takes I/O devices 10-20 ticks to
• finish. The duration of an I/O operation is determined by a random number produced when the

I/O operation is started.

• END: the program ends.

Each program of TOY may be between 1M and 32M in size. Please assume that your operating system is stored in a separate space which is not part of the main memory used by user programs. In other words, you do not need to manage the memory of the operating system. Task 1: Simulate the hardware of TOY (20 points): Design and implement classes to simulate TOY and programs of TOY. The behaviors of a program are determined by three parameters as follows.

• Size of the program in megabytes s, 1<=s<=32
• Number of steps n_steps. The program ends after running n_steps ticks on the CPU, excluding

the I/O period.

• CPU workload w (10<=w<=90). In the program, w% of instructions are RUN and (100-w)% are

IO. A program P has a method P.current_inst(), which returns either RUN or IO randomly yielding to the distribution determined by parameter w. Hardware TOY accepts a batch of programs. A list of programs in a batch, as well as corresponding parameters, is given in a file called “batch.dat”. To run a program P, TOY fetches instructions by calling P.current_inst() and executes it iteratively.

2

Hand-in

• 1. The design of the classes.
• 2. Run two programs one by one with the following parameters. Report the number of ticks they

take to finish, including the ticks for I/O operations. Also provide statistics on I/O operations (how many times? How many ticks in total?) Here, you do not need to consider the memory management issues, i.e., please assume the main memory is large enough to hold the programs. Size N_steps W 10M 100 10 10M 100 90 Task 2: Design a job scheduler for TOY (35 points): You are to design a batch operating system TOY-OS for TOY. In this task, you still do not need to consider the memory management issues. You can assume that main memory can hold all jobs in a batch. Please design an operating system TOY-OS satisfying the following goals.

• Management of running processes. You should create a process for each program in the batch.

There are four possible states of a process: running, ready, I/O pending and terminated. Every process switch costs one tick. You need to design and implement a process table as well as the necessary management facilities.

• The performance goal of your operating system is to maximize the throughput. Meanwhile, if

possible, you should try to keep the CPU as busy as possible.

• You are to design and implement your own scheduling regime.
• For comparison purposes, you are also to design and implement a Round-Robin scheduling
• regime. Each job has a time quantum of 10 ticks.

Hand-in

• 1. Please state your scheduling strategy and argue why it maximizes the throughput.
• 2. Generate three sets of programs as follows. Show the performance of your scheduler against the

Round-Robin method in terms of total runtime (in ticks), average CPU utilization (in percentage), total number of I/O operations and total I/O times. For each test set, you need to run both methods 10 times and get the average performance. Test set Number of programs Specification of parameters 1 100 All programs are of size 20M, n_steps=100-1000 (uniform distribution) and w=80% 2 100 All programs are of size 20M, n_steps=1000 (uniform distribution) and w=20% 3 100 The size, n_steps and CPU workload of programs distribute uniformly from 1M to 32M, 100-1000, and 10%-90%, respectively.

• 3. If the system goal is changed to minimize total runtime, but keep maximal throughput as a second
• ptimization goal, what changes are needed for your scheduling strategy? Please implement such

changes and show the performance improvement.

3

Task 3: Achieve memory management (25 points): The last task is to achieve memory management in your TOY-OS. Suppose virtual machine TOY has 64M of main memory. An entire program must be loaded into main memory before it can run. It takes the CPU 1 tick to initialize loading a program to main memory, and takes a device 1 tick/M to do I/O. TOY has only one I/O port. So, I/O operations in programs and in loading programs cannot run in parallel. In this task, please design and implement a memory management module in your TOY-OS. You may need to coordinate the memory management and scheduling modules. Hand-in

• 1. State your memory management strategy. With the memory constraint, what changes, if any,

have you made to your scheduling strategy (ie that of the third bullet in Task 2) to commit to maximize throughput?

• 2. Show the performance of your memory management module in term of memory utilization on the

three data sets used in Task 2.

• 3. Adjust the main memory size to 32M, 128M and 1024M and test your operating system for each
• f these respectively. What is the trend in terms of CPU utilization, memory utilization and I/O

utilization? Task 4: Summarize your research (20 points) Please summarize your research in a technical report with no more than 10 pages, which should be computer generated, including text and diagrams, single-side printed, with the text NO smaller than 11- point font with AT LEAST 25-mm margins (left, right, top, bottom). The report should cover the following aspects.

• Introduction, e.g., background, highlight of the work
• System analysis, design and implementation
• Experimental results and performance study
• Discussion
• Conclusions

Please feel free to discuss any further issues you think important and/or interesting. The report will be graded based on

• Technical quality (10%): correctness, completeness, interestingness, depth of discussion and

analysis, exploration going beyond task 1-3.

• Presentation (10%): readable and understandable, convincing, format.

Any technical report over the page limit or violating the format requirements will be turned down immediately without notice. You should submit the source code and executable in a floppy diskette or CD-Rom as an Appendix. Put everything into an envelope and submit it as a whole. It is your responsibility to arrange a demo time with the TA (subject to any time constraints specified by the TA). During the demo, any team member may be asked any question about any aspect of the project. All group members are expected to be at the demo. Further details / guidelines concerning the demo will be disseminated closer to the demo period. Groups wishing to complete this project early may do an early

• demo. All demos must be completed by 330 pm on April 12, 2002.