1

Principles of Computer System

2012 (Fall)

2

Instructor

• Yubin Xia (夏虞斌 )• Email: xiayubin@gmail.com • Web site: http://ipads.se.sjtu.edu.cn/

yubin_xia

3

Textbook

• Principles of Computer System Design: An Introduction– Jerome H. Saltzer & M. Frans Kaashoek– June 2009.

• Papers and articles online

4

Grading

• 50%: Lab• 40%: Exam– Only one final-term exam– All exams are open-books / open-notes

• 10%: Performance– Paper reading– QA site asking/answering/voting– Attendance

5

Topics

• Systems– A bunch of computer systems– E.g., hardware, software, or combined ones

• Problems– From benign ones to vital ones

• Principles– E.g., end-to-end argument

6

SYSTEM’S PERSPECTIVE

7

You’ve Already Learnt:

• Programming / Data Structure– LOC: From hundreds to millions

• Operating System / Architecture– Cores: from one to hundreds

• Network– Nodes: from two to millions

• Web Service– Clients: from tens to millions

8

The Problem: Complexity of System

9

An Example: Gas System

10

Complexity of Computer Systems

• Hard to define; symptoms:– Large number of components– Large number of connections– Irregular– No short description– Many people required to design/maintain

• Technology rarely the limit– Indeed tech opportunity is the problem– Limit is usually designers’ understanding

11

SYSTEM COMPLEXITY

12

Problem Types

• Emergent properties– Surprises

• Propagation of effects– Small change -> big effect

• Incommensurate scaling– Design for small model may not scale

• Trade-offs– Waterbed effect

13

1. Emergent Properties

• Features– No evident in the individual components of a

system– But show up when combining those components – Might also be called surprises– An unalterable fact of life: some things turn up

only when a system is built

14

1. Emergent Properties (Cont.)• The Millennium Bridge – For pedestrians over the River Thames in London – Pedestrians synchronize their footsteps when the bridge

sways, causing it to sway even more

– It had to be closed after only a few days

15

2. Propagation of Effects [Cole’69]

• WHO: tried control malaria in North Borneo – Sprayed villages with DDT– Wiped out mosquitoes, but ….– Roaches collected DDT in tissue– Lizards ate roaches and became slower– Easy target for cats– Cats didn’t deal with DDT well and died– Forest rats moved into villages– Rats carried the bacillus for the plague

• WHO replaced malaria with the plague

16

3. Incommensurate Scaling

• As a system increases in size or speed, not all parts of it follow the same scaling rules– so things stop working.

• The mathematical description – Different parts of the system exhibit different

orders of growth

17

3. Incommensurate Scaling (Cont.)

• Galileo in 1638– To illustrate briefly, I have sketched a bone whose natural

length has been increased three times and whose thickness has been multiplied until, for a correspondingly large animal, it would perform the same function which the small bone performs for its small animal. From the figures here shown you can see how out of proportion the enlarged bone appears.

18

3. Incommensurate Scaling (Cont.)

• Galileo in 1638– Clearly then if one wishes to maintain in a great giant the

same proportion of limb as that found in an ordinary man he must either find a harder and stronger material for making the bones, or he must admit a diminution of strength in comparison with men of medium stature; for if his height be increased inordinately he will fall and be crushed under his own weight.

19

3. Incommensurate Scaling (Cont.)

• Galileo in 1638– Whereas, if the size of a body be diminished, the strength

of that body is not diminished in the same proportion; indeed the smaller the body the greater its relative strength. Thus a small dog could probably carry on his back two or three dogs of his own size; but I believe that a horse could not carry even one of his own size.

20

3. Incommensurate Scaling (Cont.)

21

4. Trade-offs

• General Models– Limited amount of goodness– Maximize the goodness– Avoid wasting– Allocate where helps most

• Waterbed Effect– Pushing down on a problem at one point – Causes another problem to pop up somewhere

else

22

4. Trade-offs (Cont.)

• Binary Classification– We wish to classify a set of things into two

categories • based on presence or absence of some property

– but we lack a direct measure of that property– so we identify instead some indirect measure• known as a proxy

23

4. Trade-offs (Cont.)

• Binary Classification (Cont.)– Occasionally this scheme misclassifies something – By adjusting parameters of the proxy – The designer may be able to • reduce one class of mistakes• but only at the cost of increasing some other class of

mistakes

24

How to Handle?

• Ideally, the Constructive Theory– Allows the designer systematically to• Synthesize a system from its specifications• Make necessary trade-offs with precision

– In some fields• Communication systems• Linear control systems• Design of bridge and skyscrapers (to a certain extent)

25

How to Handle? (Cont.)

• In Computer Systems– We find that we were born too soon– The problems• We work almost entirely by analyzing ad hoc examples

rather than by synthesizing• So, in place of a well-organized theory, we use case

studies

26

Terminology• Systems, components, interfaces, environments

27

Different Views

as a flying object as a passenger-handling system

Components body, wings, control surface, engines

seats, flight attendants, air condition system, gallery

Environments atmosphere, the earth

the set of passengers

Interfaces gravity, engine thrust, air drag

the softness of the seats, the meals, the air flowing from the air conditioning

• Example: Different Views of an Aircraft

28

Different Views (Cont.)

• Different Purposes– As a passenger-handling system– e.g. consider engine as a source of noise– e.g. ignore the control surfaces on the wings

• Different Granularities– System and subsystem are relative– e.g. engine is a component of aircraft, while itself

is a system

29

Signs of Complexity• Webster’s Definition– “Difficult to understand”

• Signs of complexity (like diagnosis in medicine)– Large number of components– Large number of interconnections– Many irregularities– A long description– A team of designers, implementers, or maintainers

30

Signs of Complexity (Cont.)

• Example– Large University Library VS. Small Town Library• More catalogs: aids, guides, journal indexes, etc.• More cross-references• More exception: oversized books over newspaper rack,

microfilm or digital media, etc.• No methodical rules for locating a piece of information• More personnel and even specialists

31

Levels of Complexity

• All system are indefinitely– The deeper one digs, the more signs of complexity

turn up– A computer -> gates -> electrons -> quarks -> …

• Abstraction: limits the depth of digging

32

Sources of Complexity

• Many Goals / Requirements / Features– Interactions among Requirements

33

Sources of Complexity (Cont.)• More Goals, More Complexities

• Examples – 1975 Unix kernel: 10,500 lines of code– 2008 Linux 2.6.24 line counts:

• 85,000 processes• 430,000 sound drivers• 490,000 network protocols• 710,000 file systems• 1,000,000 different CPU architectures• 4,000,000 drivers• 7,800,000 Total

34

Sources of Complexity (Cont.)• More Interacting Features, More Complexities

– The point is not that these bad interactions can’t be fixed– The point is that there are so many interactions

• Example– Call Forwarding– Call Number Delivery Blocking– Call 900 (reverse billing)

– A blocks outgoing call to 900– A call B, B forwarding to 900– What happens?

35

Sources of Complexity (Cont.)

• Principles of escalating complexity– Adding a requirement increases complexity out of

proportion– The complexity barrier is soft: no warning– Requirements increasing leads exceptions

increasing

36

Sources of Complexity (Cont.)

• Principle: Avoid excessive generality– If it is good for everything, it is good for nothing

• Generality– Meeting many requirements with a single design– General enough to minimize the number of

exceptions– but not “too general”– E.g. design a vehicle that can drive on the highway,

fly, use as a boat

37

Maintain High Utilization

• Example: Single Rail– Performance -> complexity– Base design: alternate trains• Low throughput, high delay• Worse than two-track, cheaper than blasting

– Lower delay with a siding and two trains• Precise schedule• Risk of collision / signal lights• Siding limits train length (a global effect!)

– Point: performance cost super-linear

38

Maintain High Utilization

39

Principles

• The law of diminishing returns– The more one improves some measure of

goodness, the more effort the next improvement will require

40

COPING WITH COMPLEXITY

M.A.L.H

41

• Modularity– Split up system– Consider separately

• Abstraction– Interface/Hiding

• E.g., standard size windows– Avoid propagation of

effects

• Layering– Gradually build up

capabilities

• Hierarchy– Reduce connections– Divide-and-conquer

42

Modularity• Analyze or design the system as a collection of

interacting subsystems– Subsystems called modules– Divide-and-conquer technique

• The simplest, most important tool for reducing complexity– Be able to consider interactions among the components

within a module – Without simultaneously thinking about the components

that are inside other modules

43

Modularity (Cont.)

• Example– Debugging a program with N statements– Number of bugs is proportional to its size– Bugs are randomly distributed

Original With Modularity

44

Modularity (Cont.)

Bug

Bug

Bug

Bug

Original System System with Modularity

45

Modularity (Cont.)• The Unyielding Foundations Rule– It is easier to change a module than to change the

modularity– Changing the interface requires replacing at least two

modules• Once an interface has been used by another module

– If an interface is used by many modules• Changing it requires replacing all of those modules simultaneously

– It is particularly important to get the modularity right

46

Abstraction

• Abstraction– Treat a module based on external specifications,

no need for details inside• Principles to divide a module– Follow natural or effective boundaries– Fewer interactions among modules (Chap.4 & 5)– Less propagation of effects

47

Abstraction (Cont.)

• Examples– DVD players– Registers (circuits to remember states)– Procedure call– Applications with window interfaces– Games, Spreadsheet, Web browsers

48

Abstraction (Cont.)

• Minimizing interconnections among modules may be defeated – unintentional or accidental interconnections,

arising from implementation errors – well-meaning design attempts to sneak past

modular boundaries• Improve performance• Meet some other requirement

49

Abstraction (Cont.)

• Software is particularly subject to this problem– The modular boundaries provided by the

separately compiled subprograms are actually somewhat soft

– Is easily penetrated by errors in • using pointers• filling buffers• calculating array indices

50

Abstraction (Cont.)

• System designers prefer techniques – enforce modularity by • interposing impenetrable walls between modules

– assure that there can be no • unintentional or hidden interconnections

51

Abstraction (Cont.)

• Failure Containment– A module does not meet its abstract interface

specifications– Limiting the impact of faults• Well-designed and properly enforced modular

abstractions • Control propagation of effects

– Modules are the units of fault containment

52

Abstraction (Cont.)• The Robustness Principle– Be tolerant of inputs and strict on outputs

• Suppress noise or errors• Not propagate or amplify them

– A module should accept its input values• If it is still apparent how to sensibly interpret them

• Even if they are not within specified ranges

– A module should construct its outputs• Conservatively in accordance with its specification

• Making them even more accurate or more constrained than the

specification requires if possible

53

Abstraction (Cont.)

• The Robustness Principle: Examples– Role in mass production• Rifles in 1822, Model T automobile• In mass production there no fitters

– It plays a major role in computer systems • Human interfaces• Network protocols• Fault tolerance

– It forms the basis for digital logic

54

Abstraction (Cont.)

• The Safety Margin Principle– Keep track of the distance to the cliff, or you may

fall over the edge– Abnormal inputs indicate something is going

wrong– Track and report out-of-tolerance inputs– Shake-out mode & production mode

55

Layering• Goal– Reduce module interconnections even more

• How to do it– Build a set of mechanisms first(a lower layer)– Use them to create a different complete set of

mechanisms (an upper layer)• General rule: A module in one layer only

interacts with:– its peers in the same layer, and– modules in the next lower layer / next higher layer

56

Layering (Cont.)

Processor & memory layer

Memory cells & gates layer

OS layer

Application layer

• House:– Inner layer of studs, joist, rafter (shape & strength )– Layer of sheathing and drywall (wind out)– Layer of siding, flooring and roof tiles (watertight)– Cosmetic layer of paint (looks good)

• Algebra: – integer, complex number, polynomials, polynomials with polynomial

coefficients

57

Hierarchy• Hierarchy: another module organization– Start with a small group of modules– Assemble them into a stable, self-contained subsystem

with well defined interface– Assemble a group of subsystems to a larger subsystem

• Example– 1 manager leads N employees– 1 higher manager leads N

lower managers

58

Hierarchy (Cont.)• There are many striking examples of hierarchy – from microscopic biological systems – to the assembly of Alexander’s empire– Offers compelling arguments

• under evolution, hierarchical designs have a better chance of survival

• Constrains interactions– Permitting them only among the components of a

subsystem• Reduces the number of potential interactions

among modules from square-law to linear

59

Naming• How to connect modules?– One module names another that it intends to use

• Why naming– Postponing of decisions– Replaceability of modules– Sharing of modules

• Software uses names in an obvious way– E.g., memory addresses

• Hardware modules connected to a bus – Use bus addresses (a kind of name) for

interconnection

60

Naming (Cont.)

• Decouple Modules with Indirection– Indirection supports replacability– Any problem in a computer system can be solved

by adding a layer of indirection• A folk wisdom by David Wheeler (the University of

Cambridge)– A computer system can be made faster by

removing a layer of indirection• Plausible counterpart of the above folk wisdom

61

Naming (Cont.)

• When a module has a name– Several other modules can make use of it by name– and thereby sharing • the design effort• cost• information contained in the first module

• Names are a cornerstone element of modularity in digital systems

62

COMPUTER SYSTEMS ARE DIFFERENT

63

Computer Systems are Different

• Computer systems are the same as all other systems (plausible)– Certain common problems show up in all complex

systems– The techniques that have been devised for coping

with complexity are universal• Computer systems are different– The complexity is not limited by physical laws– The rate of change of technology is unprecedented

64

Unbounded Composition

• Two properties of computer systems – Mostly digital – Controlled by software

• Separately lead to relaxations of– Limits on complexity arising from physical laws in

other systems• Analog systems– Each component contributes noise

65

Analog Systems• Noise may come from

– The environment– Component’s physical behavior does not precisely follow any tractable

model of operation

• Compose analog components– The noise from individual ones accumulates– Noise may accumulate slowly, but still accumulates

• Noise will dominate the behavior of the system– As the number of components increases

• Noise provides a limit on the number– of analog components that a designer can usefully compose or – of stages that a designer can usefully cascade

66

Digital Systems

• Digital Systems are Noise-free– Complexity can grow without any constraint of a

bound arising from noise

• Use the Robustness Principle – the static discipline– the primary source of the magic – The range of analog values that a device accepts be

wider than the range of analog values that the device puts out • the digital value is 1 or 0

67

Digital Systems (Cont.)

• Using the Robustness Principle

68

Digital Systems (Cont.)

• Digital systems are constructed of analog components– The analog components chosen for this purpose

are non-linear• Non-linearity allows inputs to have a wide tolerance

– Components have gain between input and output• Gain assures that outputs stay within narrow

specifications

70

Digital Systems (Cont.)• A signal does not accumulate noise as it goes through

a string of devices– noise does not limit the number of devices one can string

together– noise does not constrain the maximum depth of

composition for digital systems • Digital systems can grow in complexity – until they exceed the ability of their designers to

understand them• Modern processor chips contain upwards of 40 million transistors• No airliner has nearly that many components

71

Digital Systems (Cont.)

• Controlled by Software– Turns out to be worse– Hardware is subject to some physical limits • the speed of light • the rate of settling of signals in real semiconductor

materials• unwanted electrical coupling between adjacent

components• the rate at which heat can be removed• the space that it occupies

72

Digital Systems (Cont.)

• Controlled by Software (Cont.)– Software has no physical limits • Whatever beyond the availability of memory to store it

and processors to execute it– Most abstractions don’t perfectly conceal the

underlying implementation in reality• Slightly “leaky”

– Leakiness accumulates as the number of software modules grows• In the form of complexity (a fundamental problem)

• Far beyond the ability of its designers to understand

73

Digital Systems (Cont.)• Misuse the tools of modularity, abstraction,

layering, and hierarchy – Too easy for an unwary designer to do it – To include still more complexity – This phenomenon is quite unknown in the design of

bridges and airliners.• Computer systems allow composition to a depth – First limit is the designer’s ability to understand – It tempts designers to build more complex systems

74

Digital Systems (Cont.)

• d(tech)/dt is Unprecedented

75

Digital Systems (Cont.)

• d(tech)/dt is Unprecedented– d(technology)/dt = K × technology– technology = eKT

– When a computer system is ready for delivery • The ground rules under which it was originally designed

have shifted • Since complex systems can take several years to build

– Less emphasis on • Detailed performance analysis and fine-tuning

76

The Incommensurate Scaling Rule

• Changing any system parameter by a factor of ten usually requires a new design – Less emphasis on detailed performance analysis

and fine-tuning• Too soon to adjust or redesign• Less benefit from studying the previous cases• Brute force solutions, e.g., wider canyon

– New technology is very quick to be adopted– Telescoping of the usual process• Frustrating difficulty or exciting challenge

77

COPING WITH COMPLEXITY - 2

Computer system: coping with complexity

• M.A.L.H are NOT enough– Hard to choose the right modularity– Hard to choose the right abstraction– Hard to choose the right layer– Hard to choose the right hierarchy

78

Iteration

• Iteration– Take small steps– Don’t rush– Plan for feedback– Study failures

• KISS: Keep It Simple, Stupid!– So you can see what you are doing

79

You won’t get it right the first time, so design it to

be easy to change.

Complex systems fail for complex reasons.

Rest of the class

• Three Recurring Themes– The pervasive importance of modularity• Goal & cornerstone

– Principle-based system design• Computer system design is not completely ad hoc

– Making system robust and resilient• Control propagation of effects

80

The big picture

81

Naming

ModularityAbstraction Layering

Network Atomicity

Consistency

C/SVirtualization Fault Tolerance

82

More of Course Info

• Course Site– http://ipads.se.sjtu.edu.cn/courses/cse-g/2012f

• QA Site– http://ipads.se.sjtu.edu.cn/courses/cse-qa