| Role | Name | |
| Instructor | Akshay Narayan | akshayn@brown.edu |
| HTA | Ting He | th@brown.edu |
| UTA | Ethan Park | epa@brown.edu |
You can reach staff in office hours, via the class discussion board, or (for private questions) via email. Course logistics are also available on this calendar. Lecture recordings are available on Panopto.
Schedule | Current Week 2026 9 9 | Registration FAQ | Description
How can we understand the performance of network systems and make them faster? To explore this question, we will break it down into pieces, including (i) how to define and measure a system’s performance, (ii) how to determine what factors in the system’s design affect its performance, and (iii) how to use this information to make the system faster. Through lectures, labs, readings, and hands-on programming projects, we will explore topics including throughput-latency curves, tradeoffs between open and closed request generation, and concurrency. Hands-on projects will involve modern Linux technologies such as perf and io_uring, as well as modern microservice architecture tools such as Kubernetes. The class will consist of lectures, short homework assignments that reinforce lecture content, and 4 project assignments with programming and technical writing components that explore these topics in greater detail.
Course components and schedule are subject to change.
Due to constrained TA resources, this offering of CS 1675 will be capped. Students requesting an override must (a) have fulfilled the prerequisites (CS 1680, 1670, 1380, or equivalent) and (b) complete course assignments and attend lectures during shopping period. All registered students will be responsible for completing all course assignments regardless of when they register for the class. If requesting an override, please email Akshay and state which prerequisite(s) you fulfilled.
If you wish to audit the class, note that the aforementioned limits on TA resources still apply, so we won't be able to offer auditors grading support or support in office hours.
The largest component of this class is a series of four course projects. Each project will involve an implementation task, an experimental evaluation task, and a project writeup. Course staff will grade projects based on the correctness of the implementation and experimental evaluation components, and the clarity and completeness of the project writeup. Projects will be graded during meetings with course staff, and students should be able to answer technical questions about the project during these grading meetings.
Projects in this offering of CS1675 will be implemented in Rust. While using Rust is not strictly required since the primary project deliverable is a report rather than code, some projects require using Rust libraries we provide, so students need at least some knowledge of Rust to use those libraries. Our colleagues at Brown have recently published a great book to help students learn Rust; we expect that Chapter 4, "Ownership" will be especially helpful for this class. There are also great traditional resources such as The Rust Programming Language book, the standard library documentation, and Rust by Example.
Project grading in CS1675 is based on live meetings with course staff in which students explain their project report and defend its correctness. To conserve the course staff's grading effort and ensure grading meetings are useful, projects should be completed by the time of the grading meeting, and there will be no "late days" for projects. Instead, CS1675 offers flexibility via a regrade process. If students fix issues the grading process identified with their project and submit a revised report by the subsequent project's grading meeting, they can retroactively re-gain up to 40% of the project's grade.
The primary evaluation mechanism for CS1675's projects is live face-to-face meetings. At these meetings, students must thus demonstrate understanding of the project's concepts and their code. With this in mind, CS1675 does not disallow the use of LLM-based coding agents to complete class projects, subject to the stipulation that learning how to program effectively with LLM coding assistants is not a pedagogical goal of CS1675.
The course staff encourages writing project code by hand. The amount of code required to implement each project is not large, and completing all course projects without LLM assistance is entirely possible.
Further, students should be able to understand and explain their code, no matter how they wrote it. This applies across all interactions with course staff, including at office hours, when asking EdStem questions, and of course during the grading meetings. Students who cannot explain their code (e.g., because they generated it with an LLM or copied it from the Internet and did not read it) should expect to lose points in grading meetings. During office hours or on EdStem, students who cannot explain their code should expect to be told to first understand their code before seeking further help.
This class will also involve reading-based homework assignments. Students will read a technical document that reinforces lecture content and answer questions to test their understanding. Homework assignments will be graded on writing clarity and response correctness.
Homework assignments in CS1675 are graded via Gradescope. Students are allowed one late day for the semester to submit a homework assignment past its deadline with no penalty. This late day is for homeworks only and does not apply to projects. Homeworks won't be accepted for grading beyond their last possible submission date or if no late days remain. There is no credit for an unused late day at the end of the semester. Any fraction of a late day used counts as one late day. If serious extenuating circumstances arise after late days are exhausted, contact Akshay.
While a blanket ban on use of LLMs is not practical, the course staff strongly discourages the use of LLMs to complete homeworks because the objective of CS1675's homeworks is to encourage criticial and independent thinking about the course's concepts. As above, students are responsible for the assignments they submit. Without editing, LLM-generated text is often less clear.
Students should expect to spend 3 hours per week in lecture, a further 3 hours per week on homework assignments, and approximately 100 hours on the class projects, for a total of at least 180 hours over the course of the semester.
Students should understand and follow the Brown Academic Code and the Code of Student Conduct.
Additionally, specific to this course, we encourage working with other students to build conceptual understanding and debug software issues. However, each student is responsible for their own project implementation and writeup, and their own homework response. As mentioned above, students must understand their submissions; instructors will interview and quiz students about their answers as part of the grading process to determine this.
For all class assignments, students must cite all sources (people, websites, papers, etc.) that they consult as a part of their work. External sources include but are not limited to previously published articles, blog posts, Stackoverflow or similar sites, conversations with other people, etc. This policy is not meant to discourage the use of external sources, but rather to codify a standard academic practice. Be generous with citations.
Finally, by taking this class, you agree to never post solutions for any assignments publicly.
Some lecture material in this class is inspired by Amy Ousterhout's UCSD CSE291. Some project material is inspired by Simon Peter's UW CSE453.
| Date | Assignment | Event |
| 10 Sep | HW 0: Evaluating Systems | Released |
| 15 Sep | Project 0: Woonsocket | Released |
| 17 Sep | HW 0: Evaluating Systems | Due |
| 22 Sep | End of Shopping Period | |
| 29 Sep | HW 1: C10K | Released |
| 2 Oct | Project 0: Woonsocket | Due |
| 6 Oct | Project 1: KVonset | Released |
| 6 Oct | S/NC Deadline | |
| 8 Oct | HW 1: C10K | Due |
| 13 Oct | HW 2: Scheduling | Released |
| 16 Oct | Credit -> Audit Deadline | |
| 29 Oct | HW 2: Scheduling | Due |
| 6 Nov | Project 1: KVonset | Due |
| 10 Nov | HW 3: Microservices | Released |
| 10 Nov | Project 2: Microservices | Released |
| 19 Nov | HW 3: Microservices | Due |
| 11 Dec | Project 2: Microservices | Due |
📨 HW 0 released
💡 Intro
📬 HW 0 due
📨 Project 0 released
💡 What is performance?
⚙️ 22 Sep: End of Shopping Period
💡 Instrumentation
📨 HW 1 released
📬 Project 0 due
💡 IO
📬 HW 1 due
📨 Project 1 released
⚙️ 6 Oct: S/NC Deadline
💡 Kernel APIs
📨 HW 2 released
⚙️ 16 Oct: Credit -> Audit Deadline
💡 Kernel Bypass
💡 Concurrency
📬 HW 2 due
💡 Scheduling
📬 Project 1 due
💡 Isolation
📨 HW 3 released
📨 Project 2 released
💡 Services
📬 HW 3 due
💡 Caching and Storage
💡 The Tail at Scale
💡 Energy Efficiency