Project 1 -- I/O and Devices

NOTE: This assignment, like the other projects in this class, is due at a particular time, listed above. This means that if you are even a minute late, you lose 20%. If you are worried about potentially being late, turn in your project ahead of time. Do this by submitting it electronically before it is due and giving the hard copy to me during office hours or by sliding it under my office door before it is due. Do not send assignments to my personal email address. Do not leave hard copies in my departmental mail box or attempt to give them to departmental staff (who cannot and will not accept them).

As discussed in class, buffering I/O can both improve and degrade system performance in various ways. In particular, buffering speeds up processes by allowing them to continue with their other activities while I/O is taking place but at the same time increasing the risk of data loss or corruption if the I/O has not completed before an unexpected action takes place.

You are to write two programs and associated testing protocols to demonstrate the benefits and costs of I/O buffering. You will follow the testing protocols you devise and report the results you find.

1. Part one of the assignment will demonstrate the speedup gained within a single process by buffering I/O. You should carry out the following steps while carrying out part one of the assignment.
   1. First, determine the appropriate performance metric to measure for these tests (e.g., amount of CPU time used, amount of "wall time" used, or amount of device time used) and the system call(s) you will need to use to measure this.
   2. Second, determine the testing protocol you will use to gather your data. In broad outline, this could consist of something like the following:
      1. Run an I/O intensive program of your devising n times with buffering and record results (measurements of performance).
      2. Run you I/O intensive program n times without buffering and record results.
      3. Compare results using appropriate statistical measures that will convince the reviewer (me) that you really have demonstrated a performance improvement due to buffering.
   3. Third, write the program you will use to collect your data.
   4. Fourth, follow your testing protocol and write up your findings.
2. Part two of the assignment will demonstrate the increased risk of data loss or corruption that can occur when buffering I/O. The steps you will take for this part of the assignment will be similar to those you took for the first part.

While the second part of this assignment will require you to stop a process in a way that is "unexpected" by the process (that is, does not allow for normal process completion), proper ways to do this DO NOT INCLUDE TURNING OFF, SHUTTING DOWN, OR CUTTING POWER TO ANY LAB COMPUTER. Really, don't do that.

You will turn in both a hard copy and an electronic copy of your assignment. Please follow the instructions on how to send electronic copies. Do not send them to my email address.

Both the hard copy and the electronic copy will contain a write-up explaining, for each part of the assignment, the performance metric you decided to use and your reason for choosing that metric, the testing protocol you arrived at in enough detail that the person grading your project to easily follow that protocol (this would require much more detail than the protocol outline given above) and an explanation of why you think your protocol is appropriate, all data you collected and your analysis of it along with your justification of both your analysis methods and conclusions, plus all source code you created for these two programs. The electronic copy will also contain executables of the programs you wrote. The electronic copy of your write-up should not be in a proprietary format (such as MS Word); it should be either in plain ASCII text or in a portable format (such as Postscript or PDF). Your source code for each program should be in a single file called Part<X>.c (for C code) or Part<X>.cxx (for C++ code) where <X> is replaced with the appropriate project part number (e.g., Part1.c) and your executable code should be called Part<X> where <X> is again replaced with the appropriate exercise number (e.g., Part1).

Your source code should be well structured and well commented. It should conform to good coding standards (e.g., no memory leaks).

Your write-up will include 1/2 to 1 page (roughly 80 characters per line, 50 lines per page) explaining the data structures and algorithms used in your code. This page limitation does not include figures used in your explanations, which are encouraged and may take up any amount of space. (The explanations do not remove the requirement that your code be well commented.)

You may write your program from scratch or may start from programs for which the source code is freely available on the web or through other sources (such as friends or student organizations). If you do not start from scratch, you must give a complete and accurate accounting of where all of your code came from and indicate which parts are original or changed, and which you got from which other source. Failure to give credit where credit is due is academic fraud and will be dealt with accordingly.

As noted in the syllabus, you are required to work on this programming assignment in a group of at least two people. It is your responsibility to find other group members and work with them. The group should turn in only one (1) hard copy and one (1) electronic copy of the assignment. Both the electronic and hard copies should contain the names and student ID numbers of all group members. If your group composition changes during the course of working on this assignment (for example, a group of five splits into a group of two and a separate group of three), this must be clearly indicated in your write-up, including the names and student ID numbers of everyone involved and details of when the change occurred and who accomplished what before and after the change.

Each group member is required to contribute equally to each project, as far as is possible. You must thoroughly document which group members were involved in each part of the project. For example, if you have three functions in your program and one function was written by group member one, the second was written by group member two, and the third was written jointly and equally by group members three and four, both your write-up and the comments in your code must clearly indicate this division of labor.

Some commands and system calls for you to consider using in this assignment (besides the ones covered already in class) are:

• fflush
• fsync
• times