6.824 2004 Final Project Information

Due date for team list: Feb 17
Due date for project proposal: Mar 2
Project conferences: Mar 15/16
Due date for first draft report: Mar 30
Due date for second draft report: Apr 15
Project demonstration day: Apr 29
Due date for completed project and paper: May 6 at 23:59


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 project has four deadlines: Your project grade will be based primarily on the quality of your paper, with some consideration for level of effort on the implementation.

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. We will not make exceptions: we will not allow smaller or larger teams. 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.

Feel free to base your implementation on the code that we supply you for the labs, or on your solution code. In past years students have found their NFS servers and 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: 2001 and 2002. You could also look at what's hot in the on-line proceedings of recent SOSP, OSDI, Usenix, and NSDI 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 reports: hand in your draft report by putting a PostScript file in ~/handin/final/draft1.ps and ~/handin/final/draft2.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 primarily based on the paper.

Your paper must not exceed ten single-spaced pages in length. This is a limit on the total length, including references and appendices. Please use 11-point fonts and 1-inch margins.

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

Suggestions on Writing Style

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.