Introduction: How to read and write systems papers

Introduction: How to read and write systems papers CPS210 Spring 2006

Course basics • What is CPS210 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 Component Component 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 ~ size3 (volume) • Bone strength ~ size2 (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 run-time • Especially useful for avoiding bugs • Examples • Type-safe languages, BAN logic • Caveat • This is usually really hard • State spaces grow extremely fast

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: • Why should I believe that this will work?

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?

Introduction: How to read and write systems papers