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

2. 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

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

4. 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

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

6. 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

7. 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

8. 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

9. 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

10. 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.”

11. Lamport’s hints for design  Behold, the “summary of slogans”

12. 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

13. “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

14. “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

15. “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

16. “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

17. “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

18. “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

19. “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

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

21. 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?

22. 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?

23. 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?

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