6.894 Lab 5: Do a cool project

Due date for team list: October 23.
Due date for project proposal: November 2.
Due date for paper: December 7.


In this lab you will define your own project, execute it, and write a paper about it. The lab is structured in two parts:

Doing a good project is a daunting task. In general, it is better to tackle a precise small problem and do a good job evaluating it than to tackle a large problem and get lost in the scope of the problem. To help you to define a project we will offer you some suggestions (see below). We also expect to be involved in all stages of your project. Please, come talk to use about your idea for a project, how you should execute the project, what you should write about in your final paper, etc.

The project is to be executed in teams of 3 students. Find someone else to work with and send email to the TA. Tell us the names of your teammates. The email is due by Tuesday Oct. 23 (that is in a couple days).

Suggestions for projects

We suggest you use as the SFS software that you have used in the last four labs as a base for project. This will allow you to explore easily an interesting problem in the context of distributed file systems without having to build a system from the ground up. Here is a list of specific suggestions:

Don't worry if some other group plans to work on the same suggestion as you do -- we can probably find a way for multiple groups to share a general project area without significant overlap.

Your Paper

This section provides some suggestions and guidelines on writing style and some of the things we will look for in your final paper.

Suggestions on Writing Style

Your paper should be as long as is necessary to explain the problem, your solution, the reasons for your choices, and your analysis of your solution. It should be no longer than that. The body of your paper must not exceed twelve 11-point, single-spaced pages in length. Please use 1-inch margins. In general, your paper's style and arrangement should be similar to the papers we've read in class.

A good paper begins with an abstract. The abstract is a very short summary of the entire paper. It is not an outline of the organization of the paper! It states the problem to be addressed (in one sentence). It states the essential points of your solution, without any detailed justification. And it announces any conclusions you have drawn. Good abstracts can fit in 100-150 words, at most.

The body of your paper should expand the points made in the abstract. Here you should:

  1. Introduce the problem and the externally imposed constraints.
  2. State the goals of your solution clearly.
  3. Describe the design of your solution. You may wish to divide the description into a high level architecture and a set of lower-level implementation decisions. This would be a good place for pictures and diagrams.
  4. Analyze how well the system you built fulfils your goals. Depending on your system, the analysis might deal with performance in the sense of throughput or running time; but keep in mind that factors such as reliability and useability may be as or more important goals than performance for some systems.
  5. Briefly review related work in the area of your project. The goal is to show either how you extended existing work or how you improved on it.
  6. Conclude with a review of lessons to be learned from your work.
  7. Document your sources, giving a list of all references (including personal communications). The style of your citations (references) and bibliography should be similar to the styles in the technical papers you're reading in this class. In particular, a bibliography at the end and no citations in the text of your paper is insufficient; we'd like to see what specific pieces of information you learned from where as we read your paper.

Write for an audience that understands basic O/S and network concepts and has a fair amount of experience applying them in various situations, but has not thought carefully about the particular problem you are dealing with.

How do we evaluate your paper?

When evaluating your paper, we will look at both content and writing.

Some content considerations:

Some writing considerations: You can find other helpful suggestions on writing this kind of report in the M.I.T. Writing Program's on-line guide to writing Design and Feasibility Reports. You may also want to look at the Mayfield Handbook's explanation of IEEE documentation style. A very good book on writing style is: "The Elements of Style," by William Strunk Jr. and E. B. White, Third Ed., MacMillan Publishing Co., New York, NY, 1979.

What to Hand In

You should e-mail your team list to jinyang@lcs.mit.edu by October 23.

Your team should e-mail its proposal to jinyang@lcs.mit.edu by November 2. It should be no more than two pages.

E-mail a PostScript file containing your final paper, and (separately) a uuencoded tar file containing your source by December 7th. Your project grade will be based on the paper, not on the source.

Make sure you save enough time to write a good paper, since that's what will determine your grade!