6.824 Final Project Assignment

Due date for team list: October 11.
Due date for project proposal: October 18.
Due date for progress report: November 13.
Due date for completed project and paper: December 4.


In this lab you will define your own project, execute it, and write a paper about it. The final project is structured in three parts: In addition, on the last day of class we will run a mock program committee meeting, in which you will evaluate each others' papers and choose the ones most likely to be accepted at a good conference.

Doing a good project is a daunting task. In general, it is best to tackle a well-defined small problem and do a good job evaluating it. 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 us about your project ideas, 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 or 4 students. Find team-mates and send their names by e-mail to the TA. The email is due by Tuesday October 11 (that's pretty soon).

Suggestions for projects

You should feel free to propose any project you like, as long as it is related to operating systems or distributed systems and has a substantial system-building and evaluation component.

If you are in the PhD program, we expect your proposal to involve some new idea (i.e. look like research).

We suggest that you base your implementation on the asynchronous programming libraries you used for the labs. In past years students have found sfsusrv and their web proxies to be particularly useful starting points for projects. If your project needs to run on the client side of a network file system, you may want to use the software described in Section 6 of the user-level file system toolkit paper; you can find the software in /home/to2/labs/classfs and ccfs.tar.gz.

Here is a list of project suggestions. Some of them are more or less complete ideas; others are starting points from which to think about project ideas.

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.

You can look here to see the projects from this course last year.

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 ten 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 should summarize what a reader will learn by reading the paper. It should not be an outline of the organization of the paper. It should describe the problem to be addressed, the essential points of your solution, and any conclusions you have drawn. It should be about 150 words long.

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, and explain why the problem is worth solving.
  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, functionality, 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 learned from your work.
  7. Cite your sources as you mention them in the text of your paper, and list all references at the end of the paper; the format and style should be similar to the technical papers we read in class. When in doubt, cite the source; use "personal communication" citations if you have to (e.g. for ideas given to you by fellow students).

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 6.824-staff@pdos.lcs.mit.edu by October 11.

Your team should e-mail its proposal to 6.824-staff@pdos.lcs.mit.edu by October 18. It should be no more than two pages. It should be ordinary text, not an attachment.

Put a copy of the PostScript file containing your final paper in ~/handin/final/paper.ps, and a tar file containing your project source in ~/handin/final/source.tar. Do this by December 4th. 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!