The course is organized around discussing important research papers in operating systems. Students are required to read and evaluate papers in the reading list in advance of each class session; preferably a day earlier so that the ideas can sink in. Many of the assigned papers are classical papers and some had won the ACM SIGOPS Hall of fame award. Many of these papers are not long though most of them are dense (the premier conferences in OS - SOSP&OSDI are biennial conferences. Perhaps the papers refect at least two years worth of effort). It is expected that each student will require substantial amount of preparation time to read and understand the paper. Students are strongly encouraged to first read the paper by themselves (at least twice - once to understand the overall goals and then to understand the details) and then as a group to understand the problem that a particular paper was attempting to solve, the technique used and the trade-offs employed before the class. In general, we will discuss one paper per lecture. We violate this one-paper policy during two lectures where multiple assigned papers are assigned that are very closely related to the topic of discussion. Though not required, papers noted for further reading may help you in understanding the context for the assignment paper. During class, students are encouraged to ask questions, suggest new ideas, point out weaknesses and make general observations. Every student is expected to be ready to answer questions such as a) what is the problem that this paper is addressing? b) what are the design tradeoffs employed? c) how relevant are these choices for specific scenarios etc. Most ideas in systems are developed through such healthy discussions. Even though the questions are expected to be related to the topic, students will not be judged by the quality of questions that they ask.
Grades will be determined as follows (30% - exams, 30% - assignments, 30% - projects, 10% - exit interview):
At the end of the semester, I will schedule a one-on-one exit interview with each student. I will use this opportunity to quiz you on what you learnt from your project and how it related to the ideas discussed in the papers. This is an excellent opportunity for you to high light your understanding of the course material (and perhaps convince me regarding any grade short-comings in prior exams).
I expect every student to come prepared for the paper under discussion and participate in the class discussions. Most of the exams and assignments are based on topics discussed in the papers. In order to ensure that all students are adequately prepared for the lectures, I will use the following policy:
- Send me (via email) a brief summary of the main points of a particular paper, points that you liked and disliked by 5:00 pm on the day prior to the actual lecture. You are strongly encouraged to read the paper and discuss the ideas with other colleagues in the class until the end of a particular lecture. A group can send a single email summary listing the group members.
- questions in take home assignments and exams will test your understanding of the papers. Once the relevant lecture was over, you are not allowed the discuss the paper with anyone else (till the due date for the relevant assignment). All assignments and exams are individual effort and will test your understanding of the material.
There will be a open-book, open-paper and closed laptop, take home mid term and final exam. Mid term will be a 1 hour exam and the final will be a 2 hour exam.
We will have five take home assignments which cover each of the topics covered: OS, CPU, Memory, Storage and Distributed Systems. These assignments are assigned at the end of each topic and are designed to help you prepare for the midterm and final exam. You may have to perform simple experiments to answer some of the questions.
The course will require two group (preferably groups of size two) projects. Each of these projects will identify a systems problem and propose a simple solution to solve the problem. You will perform experiments to a) show the validity of the chosen problem and b) performance benefits of your simple solution. Ideally, with followup work, the projects can lead to publications in peer reviewed workshops and conferences. You will report the outcomes of the project in a six page paper (ACM, USENIX or IEEE format). Your paper will clearly describe the problem and succinctly analyze the experimental results. In case of any doubts, I might request the raw data, otherwise we willl not look at the source code or the raw data - the grade evaluations are entirely based on your writeup as well as the in-class project presentation. Your presentation will likely be X minutes (depends on the class size)- it is important to be able to clearly explain the important points without being distracted by unimportant minutae. If you already have a research project in mind, you are free to perform that project in two steps (as project 1 and project 2). For the vast majority of the students, I will encourage you to choose a measurement project for Project 1 where you will measure some aspect of a real system. You will then attempt a solution for Project 2. I will list some sample projects in this page - you are strongly encouraged to discuss potential project ideas with the instructor.
I reserve the right to make minor modifications in the grading breakups. Any such changes will be announced in the class and posted on this web page.
This principle (which applies throughout this course) simply states that a reasonable request made in a reasonable fashion shall be reasonably handled by reasonable persons. The TAs and instructor are reasonable people, and we expect that everyone else involved in this class is as well. Asking to be a special case to turn stuff in late is not a reasonable request, barring extreme circumstances. In general, I do not accept late submissions (even if you are late by a second). Please contact the instructor regarding unforeseen emergencies.
Collaboration is a very good thing. Students are encouraged to work together and some programming projects will require a team effort with everyone expected to contribute.
On the other hand, cheating is considered a very serious offense. Please don't do it! Concern about cheating creates an unpleasant environment for everyone.
So how do you draw the line between collaboration and cheating? Here's a reasonable set of ground-rules. Failure to understand and follow these rules will constitute cheating, and will be dealt with as per university guidelines.
This rule says that you are free to meet with fellow students(s) and discuss assignments with them. Writing on a board or shared piece of paper is acceptable during the meeting; however, you may not take any written (electronic or otherwise) record away from the meeting. This applies when the assignment is supposed to be an individual effort. After the meeting, engage in a half hour of mind-numbing activity (like watching an episode of Gilligan's Island), before starting to work on the assignment. This will assure that you are able to reconstruct what you learned from the meeting, by yourself, using your own brain.
To assure that all collaboration is on the level, you must always write the name(s) of your collaborators on your assignment. Failure to adequately acknowledge your contributors is at best a lapse of professional etiquette, and at worst it is plagiarism. Plagiarism is a form of cheating.
In the same spirit, this course organization and policy rules were adopted from Prof. Carla Ellis and Prof. Amin Vahdat @ Duke.
In intra-team collaboration where the group, as a whole, produces a single "product", each member of the team must actively contribute. Members of the group have the responsibility (1) to not tolerate anyone who is putting forth no effort (being a sponge) and (2) to not let anyone who is making a good faith effort "fall through a crack" (to help weaker team members come up to speed so they can contribute). We want to know about dysfunctional group situations as early as possible. To encourage everyone to participate fully, we make sure that every student is given an opportunity to explain and justify their group's approach.