CS6963 Distributed Systems

CS6963 Fall 2016 Distributed Systems

Tuesdays & Thursdays
15:40 to 17:00 WEB L102

Instructor Ryan Stutsman stutsman@cs.utah.edu
Office Hours Wednesday and Friday 15:30 to 17:00 in MEB 3436

TA Candy (Tian) Zhang tianz@cs.utah.edu
Office Hours Wednesday 15:00 to 16:30 in MEB 3115

Course Calendar
Lab Setup
Lab 1 - Lab 2 - Lab 3
Lab Submission Status
CloudLab Signup


9/8 - No class. Make sure you watch the Raft video (see the calendar).

9/6 - No class.


3 credit hours

Prerequisites: CS 5460, CS 4480, or similar systems experience with a heavy programming component.

In the last decade, large-scale distributed systems have revolutionized the way we live and work. They form the basis for our communications platforms. They provide our only means of finding, aggregating, storing, and analyzing the massive data we collect each day. These systems will only need to grow larger, faster, and more reliable as more and more of our lives and devices are online.

Building distributed systems, especially those that operate at large-scale with high performance, presents special challenges. For example, scale introduces faults and the need for redundancy. Redundancy complicates consistency.

This class explores these issues and more through the lens of the latest in distributed systems research (often from SOSP, OSDI, and NSDI). Each lecture will be associated with an assigned research paper reading. Each reading is intended to highlight a unique distributed systems problem and/or solution. Students will be expected to read each paper before class and to actively participate in class discussions.

Largely, the focus of the class will be on full systems, so that students get a sense of how they might build similar systems capable of operating at large scale. The class includes a significant programming component.


  • To get an overview of practical modern distributed systems, with an eye toward data center systems in particular.
  • To learn, use, and implement standard distributed systems techniques and infrastructure (RPC, consensus).
  • To learn how to approach, discuss, and communicate about difficult and technical subject matter.


CS6963 is a special topics graduate class with lectures and several programming projects, quizzes, and a final group project.


Most class meetings will be part lecture and part paper discussion. You should read the paper before coming to class and be prepared to discuss it. You can find out what paper to read for each meeting in the schedule.


Classes with assigned preparation (e.g. paper reading) will have a very short quiz at the start of class before the paper is discussed to ensure that students are reading and understanding the papers.

Your lowest two quiz scores will be thrown out.

Programming Labs

Labs will be due every few weeks throughout the course.

Final Project

The final project will be in groups of 3. It includes a proposal, an implementation, a final report that details the project and the results, and an in-class group presentation.


Final course grades will be based on:

  • 40% for programming assignments.
    • 13% each.
  • 35% final project.
    • 10% for the project itself (that is the artifact, its novelty, quality, and usefulness).
    • 10% on the final report.
    • 10% on the final presentation.
    • 5% for the initial proposal.
  • 25% quizzes and code review.

You can hand in your lab solutions late with a few conditions:

  • You must notify the TA before the normal lab deadline that you will turn it in late and how many late days you'd like to use.
  • You have 6 late days to use at your discretion subject to the other constraints.
  • You can only use late days in whole integer units.
  • You cannot use late days on any part of the project (just on labs).
  • You must turn in all work before the last day of normal class or it will be an E.
  • If you fail to meet these requirements and a lab is late, we'll give it a D or E depending on whether it basically works or not.

If you want an exception to these rules, in any way you must get a letter from the appropriate office at the University.

No part of the project can be turned in late for credit.

Collaboration and Cheating

Collaboration and Cheating

  • Everyone needs to read the SoC Policy on Academic Misconduct.
  • Working with others on assignments is a good way to learn the material and we encourage it. However, there are limits to the degree of cooperation that we will permit.
  • When working on programming assignments, you must work only with others whose understanding of the material is approximately equal to yours. In this situation, working together to find a good approach for solving a programming problem is cooperation; listening while someone dictates a solution is cheating. You must limit collaboration to a high-level discussion of solution strategies, and stop short of actually writing down a group answer. Anything that you hand in, whether it is a written problem or a computer program, must be written in your own words. If you base your solution on any other written solution, you are cheating.
  • Never look at another student's code or share your code with any other student.
  • You must not make your code public (on github or by any other means).
  • We do not distinguish between cheaters who copy other's work and cheaters who allow their work to be copied. If you cheat, you will be given an E in the course and referred to the University Student Behavior Committee. If you have any questions about what constitutes cheating, please ask.


The entire structure and much of the content was blatantly lifted from MIT's 6.824 Thanks to Robert Morris, Frans Kaashoek, and Nickolai Zeldovich for developing the course.