Assignment #1: Warm-up Project

Notes

The TA (Matthew Allen) will be the "director" of the warm-up project. All questions should be directed to him via email (matthew@cs) or during his office hours (Mon at 2-3 and Thu at 3-4).

Read this assignment in its entirety before beginning!

Introduction

• To become familiar with the computing environments you may use for your project (i.e., crash-and-burn lab)
• To refresh you basic systems programming skills
• To gain (more) experience with measurement and evaluation
• To clearly and concisely summarize your results to others through tables, graphs, and text
• And, finally, to understand the costs of various OS primitives

The Measurements

On this platform, you will measure several operating system features. In each experiment, you need to ensure that your measurements do not capture some anomalous behavior; therefore, to increase the confidence of your measurements, you should run each experiment multiple times within a loop and have your code report the average. While there are different ways you can determine the number of times your code must loop, the simplest is experimental. With this approach, you run each experiment manually, increasing the number of iterations each time, stopping when adding more iterations does not change the average.

Clock precision

The operating system and hardware provide various ways to measure time. In this first step, you need to identify two ways of measuring elapsed, real time (as opposed to accumulated process time) and determine the resolution (or precision) of the timer.

One way to determine the resolution of the timer is to read the clock value at the start and end of a simple loop. Start with a single loop iteration, then increase the iteration count of the loop until the difference between the before and after samples is greater than zero. Try to get the smallest non-zero positive difference. If a single iteration of a loop takes too much time, try putting simple statements between the two timer calls.

Repeat this test for each of the two ways that you measure elapsed time. Use the more precise way in the rest of your experiments.

Kernel call:

Choose a simple kernel call such as getpid() and measure the elapsed time to perform the call. Choose two other kernel calls that you suspect perform trivial operations, and measure the time to perform these. Be careful that some versions of these simple kernel calls may cache their result in a variable on the first call, making subsequent calls artificially fast (if so, then report both results). Also be sure that the platform actually performs a system call.

Context switch:

Measure the time to context switch between two processes.
Choose one of the following two techniques for measuring this time:

• Use signals: Process A sends a signal to Process B. Upon receiving the signal, Process B sends a signal back to process A.
• Use a pipe: Process A sends a 1-word message to Process B. Upon receiving the message, Process B sends a 1-word message back to process A.

Page allocation:

Measure the latency of a page fault for a zero-filled page (i.e., a page fault in which the OS both allocates a free page frame and fills it with zero values). One way to measure the zero-filled page fault processing latency is the following: use malloc() to allocate a large region of memory, then touch one word out of each page in the region, and measure how long the whole operation takes. As reasonable, present your results such that you separate the cost of malloc from the time to touch each page. Explore this cost as a function of the number of pages, ensuring that your region is large enough to produce measurable results, but still fits in RAM.

File read:

Measure the time to read from a large file using two different techniques:

• directly calling the UNIX
read() system call

• map the file into memory using
mmap() and copy data from the mapped region into another buffer.

For both techniques, be sure to consider both files that are cached in RAM and on local disk. And, again, explore time as a function of the size of the read.

The Write-Up

Title: The title should be descriptive and fit in one line across the page.

Abstract: This is the paper in brief and should state the basic contents and conclusions of the paper. The abstract is not the introduction to the paper, but is a summary of everything. It is an advertisement that will draw the reader to your paper, without being misleading. It should be complete enough to understand what will be covered in the paper. This is a technical paper and not a mystery novel -- don't be afraid of giving away the ending!

Introduction: The introduction is a section of the main body of the paper. It should prepare the reader for the remainder of the paper, motivating the problem, and outlining the approach.

Experiments: The rest of the paper should be split into reasonable sections. You should begin by describing your experimental platform (e.g., the hardware, operating system, and compiler with versions, options, and flags as necessary). For each experiment, you should briefly describe your methodology (such that it could be replicated by someone with a reasonable OS background). For each experiment, you should present your results concisely and in table or graph form when appropriate; you should identify those variables which you control (e.g., by placing them along the x-axis), and identify your performance metric especially their units. For each experiment, you should describe any conclusions that you can draw.

Conclusions: This is a discussion of what the reader should have learned from the paper. You can repeat things stated earlier in the paper, but only to the extent that they contribute to the final discussion.

Figures: A paper without figures, graphs, or diagrams is boring. This paper will certainly need several performance tables and graphs. Your paper must have figures.

Conclusions