Reading List

Please check the Schedule and Resources menu items to see which papers will be discussed next. If you have difficulties accessing a paper, please inform the instructor! Make sure you understand each paper in broad strokes by addressing the following questions:
  • Problem. What is the fundamental problem the paper is trying to solve?
  • Solution. What is the basic approach to solving the problem, temporarily leaving out the ugly details?
  • Assumptions and Complications. What assumptions do the authors have to make to arrive at their solution? Are these assumptions realistic or could they be relaxed? What complications and challenges do the authors have to address for their solution?
  • Evaluation and Results. Was the solution evaluated via a working system, via a simulation, or via a mathematical model? What exactly is measured and what was it compared against? Are both pros and cons of the solution discussed?
  • Conclusions. What as achieved or proven? Was the idea a complete success or does it work only for particular situations? What next steps should be taken?
Please feel free to form reading groups to discuss the papers.

Annotated Bibliography

Before you begin your course project, you must spend some time learning about the general subject area. You don't have to have a specific project in mind just yet, but you should select an area that is of interest to you and begin to read about it. Your goal in this assignment is to produce an annotated bibliography on a medium-sized topic. An annotated bibliography is a list of publications accompanied by a short explanation of the value and purpose of each item. Details about this assignment can be found here.

Project Proposal

Before you begin working on your course project, you must submit a formal project proposal. The project proposal is meant to help you crystallize the details of your project and focus your energies on producing a high quality final paper. It will also help to clarify between you and the instructor what resources are needed, and what will be expected by the end of the semester. Projects will be performed in teams of 1-3 students. Your semester project must involve the construction, quantitative evaluation, and scholarly exposition of some aspect of an operating system. The term "operating system" may be interpreted broadly to include any kind of management software, including conventional kernels, virtual machines, run-time libraries, distributed systems, etc. You may use whatever languages and tools are appropriate for the task. You may carry out a project that has never been done before, or you may repeat an old idea (e.g., a filesystem usage study), as long as you do everything from scratch, and clearly compare your results to what has come before. The proposal should be no more than three pages long, with a font size of no smaller than 11 and margins of about 1 inch on each side. Consider the audience for your proposal to be fellow students that are smart and capable, but are not taking this particular class and may not have read the papers that we have.

Your proposal will be submitted as PDF file via Canvas. While the final report will have to be written using LaTeX as typesetting tool, the proposal can be written using your preferred text editing software, but the document must look professional (ideally in the style of a paper). The proposal should have the following sections:
  • Title and Project Members. Start the proposal with a descriptive title, followed by the names of the project members.
  • Abstract. The abstract should summarize the entire project in one paragraph. State a problem, the general solution technique, the expected complications, the solution to those complications, and the nature of the evaluation that you will conduct. (It's usually easiest to write the abstract after you have finished everything else.)
  • Introduction. Begin by describing the big picture, describing the context that you are working in. Even if you are researching something that has been discussed in class, you must give a short introduction to the topic in your own words. Describe how this system or idea is used (or could be used) by real people. Give a short example of why this topic is difficult or interesting. Briefly state the problem that you wish to solve. For example, if you are working on the performance of virtual machines, then you should begin by describing what a virtual machine is, how it works, and what it might be used for. Then, write a compact, precise statement of the problem to be solved, such as: Virtual machines impose a high penalty on I/O. In this project, we will improve the I/O performance of the XYZ virtual machine monitor.
  • Related Work. Using your annotated bibliography as a starting point, discuss the related papers that is most relevant to what you are doing. If what you are proposing as been done before, state so plainly, and clearly indicate a few papers, If you are doing something completely new, then pick out a few papers that are in the same general area, and explain how your work is different or better.
  • Proposed Work. Once you have laid out the background, describe exactly what you intend to accomplish. What will you build? What will you demonstrate? What machinery and software will you require? Where and how will you get such resources? What complications do you expect to encounter? Clearly state how your proposed work will address the problem stated in the introduction. If you will be constructing a system out of existing software, then include a diagram that shows how the various parts connect to each other. If you will be creating a large piece of software, then sketch the various modules and how they fit together.
  • Evaluation. Next, you must give a very specific statement of what quantitative evaluation you will perform in order to evaluate your work. Will you demonstrate that one system is more scalable than another? Will you demonstrate that one system performs better than another? Are you expecting a certain result? If you expect that your final paper will have some graphs (and it should), then you can also add some draft graphs. Of course, they won't contain any data, but decide on the axes, the units, and the nature of the experiments that will produce the graphs. If you have a hypothesis as to what the data will look like, then you can sketch in a curve with a pencil. Be sure to explain carefully how your results will support your evaluation goals. For example, if you are going to evaluate the scalability of a system, then you should be very sure to have a graph with the system size on the X axis and a performance metric on the Y axis.
  • Timeline. Give a timeline indicating what each group member will accomplish each week until the final paper is due. Also, consider the milestones listed in the course's schedule (course website), e.g., your progress report after midterm break should have some preliminary results in terms of development and/or evaluation. It might also be wise to leave a week empty as "catch up" time during some point of the semester.
  • Team Composition and Responsibilities. Describe the team composition (e.g., names of each team member, 1st/2nd year grad student, background, particular skills or experience that may be helpful in this project, etc.) and responsibilities for each team member, i.e., how you will split the work between each other. Be detailed; responses such as "we all will work together for all tasks" are not acceptable! Each part/phase of your project should have somebody responsible.

Instructor Meeting and Feedback

After submitting your project proposal, the instructor may schedule a brief meeting with a team, specifically if in-person clarifications are needed or if there are any major concerns. At this meeting, be prepared to give an informal pitch as if you were describing your project to a funding agency. If needed, we will make any adjustments in the scope or detail of your project. Also, the instructor may request modifications and clarifications to the proposal document; if that is the case, the team must resubmit a new version of the proposal within the time constraints provided by the instructor in the feedback. Do NOT wait to receive proposal feedback to begin your project; immediately after proposal submission, it's time to get to work!

Project Topics and Ideas

The proposed project can be a brand-new idea, an extension/modification of a prior research idea, or an attempt to revisit an old idea. The annotated bibliography will hopefully provide an opportunity to investigate different project opportunities. To help with identifying a suitable project topic or project idea, follow the link provided here.

Progress Report

Following the Fall break, you (and your team) will give a short written progress report describing your research project, the progress that you have made so far, and what remains to be done. The report should be no more than two pages, containing the following sections:
  • The Problem - What problem are you attacking? Why is this an important problem and why is it tricky to solve? (1-2 paragraphs)
  • The Solution - What is your approach to solving the problem? What makes your solution unique, difficult, or non-obvious? Your solution should be clearly conveyed, ideally including a figure or diagram that shows all components of your software, system, or algorithm, and how they interact. (2-3 paragraphs)
  • Initial Results - Whas been accomplished so far? Demonstrate that your basic idea works, albeit in some incomplete fashion. If your project involves performance measurements, show a measurement that verifies that your basic hypothesis stands. If your project involves collecting data, show some real data and explain some interesing aspects (e.g., anomalies) in the data. (2-4 paragraphs)
  • Next Steps - What remains to be accomplished? Are there any unexpected technical issues that changed (or might change) the direction of your project? What are your risks and how will they be addressed? What results will you demonstrate at the end of the semester. (1-2 paragraphs)

The goal of the report is to provide a clear description of the progress made so far and what remains to be done. It is important to indicate where you stand compared to the original plan (e.g., one way to represent this could be a table that shows all steps/tasks required to complete your project and indicating which ones have been completed, are in progress, or are yet to be done). Grading is primarily based on the perceived progress (or lack thereof) in the project! The report must be submitted by 11.59pm on the day of the deadline using Canvas (only one team member has to submit the report).

Draft and Final Paper

The final report for your class project will be written in the style of a conference or workshop publication. The paper must be written in LaTeX and the IEEE manuscript documents and templates must be used (available here: IEEE Templates). Use the "bare_conf.tex" file for your manuscript. There are various Unix, Windows, Mac OS LaTeX tools you can use for writing your paper; I suggest to identify, download, and investigate one of those tools asap if you do not yet have LaTeX experience. For both the draft and the final paper, these are the requirements:
  • Page limit: 8 pages (minimum: 6 pages), including all figures and references.
  • Font size: 10pt; do not change the font of the template.
  • Use a meaningful title for your work and list all team members as authors (order does not matter).
  • The paper should have all typical sections that are appropriate for your type of paper, e.g., Abstract, Introduction, Related Work, Conclusions and Future Work, etc.
  • The bibliography should be in a separate .bib file that is used by your main tex file.

The draft paper should also conform to all the above requirements, except that the minimum number of pages is reduced to 4. All sections need to be present, even if certain sections have very little information (e.g., if you do not have results yet, you still provide a section describing what you expect your results to show, etc.).

Submission of both documents (draft and final report) is via Canvas; there will be separate directories created for the draft and final reports. It is sufficient if one team member submits the reports. Place the following files into these directories: the source (tex) file(s), the bib file, and the compiled pdf file. The pdf file should be named report_studentid.pdf with the studentid of the team member submitting the report.

Paper Review

Within 24 hours of the draft paper deadline, each student will receive two draft papers for review via Canvas (details to be announced). The purpose of this exercise is to provide each team with feedback on their paper draft and to practice the paper review process. The paper review form is available here; please make sure to submit it as word document (and not PDF)! Strive to be accurate, honest, and polite in your reviews. Keep all items except j as brief as possible. For item j, elaborate in detail why you ranked the paper the way you did, any problems or questions you found when reading the paper, or any suggestions for improvement you may have. Your name and the last item in the form (confidential information to instructor) will NOT be shared with the team receiving your review and please make sure not to disclose your name or other information that hint at your identity in the review form. There is no limit, but provide at least a 1/2 page review in item j. Once you receive your review, please read through it carefully and consider the comments when finalized your project paper.

Final Presentation

For the final project presentation/demonstration, you will have the opportunity to present your work and outcomes to the class. Note that for earlier presentations, it is understood that there may be a few things that are not completed yet. Later presentations should present a near-complete solution. Clearly describe the problem you were solving, the solution you pursued, your methodologies or design choices, how you evaluated your solution, results obtained, etc. Your talk can also end with a brief outlook onto future steps or work, i.e., ideas how your work could be continued or further improved. Each team member should participate in the presentation. The presentation should be about 5 minutes long and each presentation will be followed by a brief Q&A. Demonstrations are encouraged if feasible, but recorded demonstrations are preferred (live demonstrations are risky) and they should not consume more than 30% of your presentation time. Submit your presentation slides via Canvas by 7am the morning of your presentation so that the instructor can prepare them before class (i.e., no need to bring your own laptop, etc.).