1 Basic Information

Time and place: MW, 10:05-11:20, LSRC D106

Instructor: Landon Cox, lpcox@cs.duke.edu, LSRC D304


2 Course Overview

CompSci 510 is intended to satisfy a number of objectives:

  1. CompSci 510 is a graduate-level overview of the basic knowledge, skills, and research directions in the field of Operating Systems.
  2. CompSci 510 is a Quals Course. This means that it can be used to meet one of the requirements for PhD students. To get quals credit, a student must pass the exams with a "quals pass," and receive a B+ or better overall.
  3. CompSci 510 is a gateway course for prospective systems students. This means it will present a view of the research currently of interest to the systems faculty. Students who are considering pursuing systems research (either Ph.D. or Masters level) within the systems group must demonstrate research potential. It will be impossible to convince any of the systems faculty to agree to be your advisor without doing a good job in this course.

Because the course instructors rotate from year to year, each offering is different. This year there will be two programming assignments in addition to a semester-long research project. The research project should in no way discourage non-systems students; systems is a broad area and translating an existing AI or theory interest into a systems problem should be straightforward. My emphasis on a course project and research papers is meant to help students of all backgrounds work through the difficult transition from class taker to researcher. You are here because you have already demonstrated that you are very good at taking classes; one of my primary goals is to help you become good researchers.

The prerequisite for this course is CompSci 310 (or its equivalent). The intended audience is computer science graduate students and undergraduates who already know operating-systems basics. Undergraduates who did well in and enjoyed CompSci 310 are particularly encouraged to take this course.

3 Course requirements

The work for this course consists of:

  • Reading, analyzing, and actively discussing systems research papers.
  • As part of a team, completing two programming projects.
  • As part of a team, designing a semester-long project, carrying it out, and reporting the results through a written paper and in-class presentation.
  • Taking a mid-term and a final exam.

3.1 Paper summaries and discussion (5%)

This course has no text book; instead, we will cover between 25 and 30 original research papers. If you would like a textbook to help you review concepts, Remzi's book is a great one.

It is important that you digest each assigned paper before lecture. You will need to turn in a short summary of the lecture's paper before lecture begins via Piazza. Summaries should be no more than five sentences long, followed by two positive aspects, two negatives aspects, and two questions that you would ask the authors. This is intended to fuel class discussion and help you study, so think of good questions!

Sign up for piazza here: http://piazza.com/duke/spring2018/compsci510

3.2 Research Project (25%)

In addition to reading papers, you will design, carry out, and report the results of an operating systems project.

I will give you ideas for projects, but they are purposefully vague—a question well asked is already half answered. It is perfectly fine to work on a project that contributes to your own research agenda, but you must be able to convince me that your project has some relationship to operating systems, broadly defined. If you are an AI or theory student, I do not anticipate this being a problem. Some projects may require special hardware or privileges. If you would like to pursue such a project, please talk to me so that I can make the appropriate arrangements.

Projects are carried out in teams, preferably of three people. You may want to use the class discussion group to find project partners. I will make some suggestions about possible project groupings. Your project partners will have a substantial impact on your grade, so choose them wisely. There are four components to your project grade: a project proposal, a midterm status report, a final project report, and a project demo/presentation. Each group will meet with me after turning in their proposal and status report to discuss future direction.

I would like to make project proposals and reports available to students who take 510 in this and future semesters. If your group would prefer not to do this, let me know over email.

3.2.1 Project proposal

Your proposal should explicitly state the problem your project will address, your project's goal and motivation, related work, the methodology and plan for your project, and the resources needed to carry out your project. Be sure to structure your plan as a set of incremental milestones and include a schedule for meeting them. The proposal is approximately 5% of the project grade.

3.2.2 Status report

Your status report should contain enough implementation, data, and analysis to show that your project is on the right track. You should include your original proposal with my comments, along with any surprising results or changes in direction, schedule, etc. You should also have a refined version of the problem statement and goals, as well as a more developed related work section. The status report is approximately 20% of the project grade.

3.2.3 Final report

Your final report should be in a form ready to submit to an OS conference or workshop. It must be well written and give convincing evidence of any conclusions you can draw from your project. It must contain the following:be in a form ready to submit to an OS conference or workshop. It must be well written and give convincing evidence of any conclusions you can draw from your project. It must contain the following:

  • Concise abstract.
  • Problem motivation.
  • Design goals or performance questions.
  • Design architecture or performance metrics.
  • Description of code or scripts: major data structures and control flows.
  • Description of difficulties in coding or performance measurement and analysis: whether, why, and how the original goals, architecture, and/or metrics needed to be changed.
  • Evaluation showing achievement of goals.
  • Future work, related work, summary, and references.

3.2.4 Project presentation and demo

You must effectively demonstrate your project through an in-class presentation and live walk- through. The presentation should be about 15 minutes long. The talk should convey to the rest of the class 1) what problem you tried to solve and why it matters, 2) why the current state-of- the-art inadequately addresses this problem, 3) your alternative vision of how to solve the problem, 4) some results demonstrating the validity and limitations of your approach. The goal of a good talk is not to regurgitate your paper, but to convince the audience that they should read your paper. There is a difference!

The demo happens after the talk and lasts about five minutes. This is your opportunity to call attention to aspects of your project that may not be readily apparent in the final report (a nice user interface, cute features, hideous bugs, etc). Each group receives a single grade for the report, demo and presentation—in total, the report, demo, and presentation are worth 75% of the total project grade.

3.3 Programming projects (20%)

Each student will complete two programming projects. Each project will take two weeks to complete, and each will be worth 10% of your total grade.

3.4 Mid-term exam (25%)

The midterm will be an in-class, closed-book, open-note, no-computing-device exam, and you MAY NOT discuss the exam with anyone else—including faculty members, family, or others who are not enrolled in the class.

3.5 Final exam (25%)

Similar to the midterm, the final exam will be an in-class, closed-note, no-computing-device exam, and you MAY NOT discuss the exam with anyone else—including faculty members, family, or others who are not enrolled in the course. The final is scheduled for May 1st from 2-5p. The final exam should take a well-prepared student two hours to complete.

4 Late work, exam conflicts

Paper summaries must be posted to Piazza before you come to class. No late summaries will be accepted. All project deadlines are 6:00 PM on the day each component is due. Work submitted after 6:00 PM but before midnight is penalized 5%. Thereafter, each day is charged an additional 10%; weekend days count as―days. If you have a conflict with an exam, you must see me no later than three weeks prior to the exam to make arrangements.

5 Cheating and collaboration

Acts of cheating and plagiarism will be reported to the appropriate administrative bodies. You are responsible for knowing, and will be held to, the University Honor Code. With the exception of exams, discussion of course material is not considered cheating and is strongly encouraged. If you receive substantial help from another person you must acknowledge them in your work. If you use any published or unpublished source in any of your own work, you must give full citation.