Introduction How to read and write systems papers

Introduction: How to read and write systems papers CPS 210 Spring 2006

Course basics ê What is CPS 210 about? êOperating systems research ê Who should take it? êGraduate students and smart undergrads ê Who is the instructor? êLandon Cox (lpcox@cs. duke. edu) êDuke systems faculty since September ‘ 05 êDuke alumnus (Trinity, class of ’ 99) êRecently received my Ph. D. from Michigan (Dec. ‘ 05) ê More at the end of class

Outline êHints for Computer System Design êButler Lampson êAn Evaluation of the Ninth SOSP Submissions êRoy Levin and David Redell êCourse mechanics

Hints for designing systems êWhat is a system? êComponents, interconnections êInterfaces, environment êSystems do something for their environs êExhibit this behavior via interface êCleanly divides the world in two êParts of the system + the environment

Systems from 10, 000 feet Component System Environment aka “the client”

Why is designing systems hard? êEmergent properties êCan’t predict all component interactions êMillennium bridge êSynchronized stepping leads to swaying êSwaying leads to more forceful synchronized stepping êLeads to more swaying … êPropagation of effects êIncommensurate scaling êTrade-offs

Why is designing systems hard? êEmergent properties êPropagation of effects êWant a better ride so increase the tire size êNeed a larger trunk for the larger spare êNeed to move the back seat forward êNeed to make front seats thinner êLeads to worse driver comfort than before êIncommensurate scaling êTrade-offs

Why is designing systems hard? êEmergent properties êPropagation of effects êIncommensurate scaling êConsider the giant mouse êWeight ~ size 3 (volume) êBone strength ~ size 2 (cross section area) êAn elephant sized mouse is not sustainable êTrade-offs

Why is designing systems hard? êEmergent properties êPropagation of effects êIncommensurate scaling êTrade-offs ê“Waterbed effect” êPush on one end, and the other goes up êSpam filters and smoke detectors êFalse positives vs false negatives

Why is designing systems hard? êEmergent properties êPropagation of effects êIncommensurate scaling êTrade-offs êIn the immortal words of HT Kung ê“Systems hard. Must work harder. ”

Lamport’s hints for design êBehold, the “summary of slogans”

Or, put another way … êThree design goals (the why axis) êMaking it work (functionality) êMaking it fast enough (speed) êMaking sure that it keeps working (fault tolerance) êThree design constraints (the where axis) êCompleteness êProper interconnections/interfaces êBuilding an implementation

“Separate the normal, worst case” êHard for math/theory people to accept êMore natural for engineers êFull disclosure: I was a math major êMake common case fast, corner case correct êCorollary êOften not worth optimizing the corner case êDepends on just how painful the corner case is êExample: disconnected operation in Coda

“End-to-end” êDon’t try to be all things to all people êFunctionality imposes trade-offs on others êYou’ll get it right for a few, wrong for most êKeep systems lean, simple, and efficient êAllow clients to weigh their own trade-offs êThey know their needs better than you êExample: Internet and IP êSimple protocol allowed others to build on top

“Caching answers” êStore expensive computations’ results êMust maintain consistency of cache êAre stored answers correct? êMust manage cache residency êWhich answers deserve to be in the cache? êExample: buffer cache êGoing to disk takes ~ 10 milliseconds êGoing to memory takes ~ microseconds

“Use hints” êHints are like cached answers êTwo differences êHints are only mostly right (may be wrong) êCan be checked against the truth êNot always reached by associative lookup êExample: file directories êFiles in the same directory are likely related êCollocating them on-disk can improve access time

“Compute in background” êIn systems, procrastination is encouraged êDefer work as long as possible êYou might end up not having to do it êVariation of “closest-deadline-first” êEspecially true for performance êKeep the critical path as short as possible êExample: writing files back to a server êMost files are short-lived êWait to see if they’re deleted before shipping

“Log updates” êWriting to a log is very efficient êOnly need to maintain start, end addresses êSimply append to the end êLogging preserves write order êLog cannot be corrupted by failures êCan always get back to a consistent state êVery useful for performance, fault tolerance êExample: databases

“Static analysis” êBetter to fail during design than runtime êEspecially useful for avoiding bugs êExamples êType-safe languages, BAN logic êCaveat êThis is usually really hard êState spaces grow extremely fast

Outline êHints for Computer System Design êButler Lampson êAn Evaluation of the Ninth SOSP Submissions êRoy Levin and David Redell êCourse mechanics

Motivating your system êWhat problem are you solving? êWhy is it important? êWhat is state-of-the-art (SOA)? êWhy is SOA inadequate? êWhat is new about your approach? êHow does it differ from SOA? êBottom line: êWhy should I care about this? êWhy is this different from what I’ve already seen?

Describing your system êWhat are the architectural/design goals? êWhat assumptions are you making? êWhy are those assumptions reasonable? êWhat were the alternative approaches? êWhy didn’t you take those approaches? êBottom line:

Evaluating your idea êDid you implement the architecture? êWhich parts? êDoes it achieve the design goals? êDid it change your original design? êDoes it expose architectural limitations? êBottom line: êDoes the system solve the original problem? êDoes the system introduce any new problems?

Outline êHints for Computer System Design êButler Lampson êAn Evaluation of the Ninth SOSP Submissions êRoy Levin and David Redell êCourse mechanics