6.824 2002 Final Project Assignment

Due date for team list: October 3
Due date for project proposal: October 10
Project conferences: October 16/17
Due date for draft report: November 7
Due date for completed project and paper: December 5th at 23:59
Mock program committee meeting: December 10


For the final project in 6.824 you'll form groups of three or four students, pick a system you want to build, design it, implement 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. The most successful projects tend to be very well defined and modest in scope. We (the 6.824 staff) are very happy 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 soon (see the list of deadlines at the top of this page).

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; that is, it should be a research project.

We suggest that you base your implementation on the asynchronous programming library you used for some of the labs. In past years students have found sfsusrv and their web proxies to be particularly useful starting points for projects.

If you're having trouble thinking of a project idea, some of the ideas below might help get you started. You might also want to look at projects from previous years: 2000 and 2001. You could also look at what's hot in the on-line proceedings of recent SOSP, OSDI and Usenix conferences.

What to Hand In

Check the top of this page for due dates.

Team list: e-mail your team list (three or four members) to 6.824-staff@pdos.lcs.mit.edu.

Proposal: e-mail your proposal to 6.824-staff@pdos.lcs.mit.edu. The proposal should be no more than two pages. It should be ordinary ASCII text, not an attachment or word processor file.

Draft report: hand in your draft report by putting a PostScript file in ~/handin/final/draft.ps.

Final report: hand in your final report by putting a PostScript file in ~/handin/final/paper.ps, and a tar file containing your project source code in ~/handin/final/source.tar. Please also put an anonymized copy of your report (without your names on it) in ~/handin/final/paper-anon.ps; the class will use this for blind review in the mock program committee meeting. 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!

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. 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 fulfills 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 usability 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 will 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.