2007Sp61C-L28-dap-ROC.pptVIP

Recovery Oriented Computing (ROC) Dave Patterson and a cast of 1000s: Aaron Brown, Pete Broadwell, George Candea?, Mike Chen, James Cutler?, Prof. Armando Fox?, Emre K?c?man?, David Oppenheimer, and Jonathan Traupman U.C. Berkeley, ?Stanford University April 2003 Outline The past: where we have been The present: new realities and challenges A future: Recovery-Oriented Computing (ROC) ROC techniques and principles The past: research goals andassumptions of last 20 years Goal #1: Improve performance Goal #2: Improve performance Goal #3: Improve cost-performance Simplifying Assumptions Humans are perfect (they don’t make mistakes during installation, wiring, upgrade, maintenance or repair) Software will eventually be bug free (Hire better programmers!) Hardware MTBF is already very large (~100 years between failures), and will continue to increase Maintenance costs irrelevant vs. Purchase price (maintenance a function of price, so cheaper helps) Learning from other fields: disasters Common threads in accidents ~3 Mile Island 1.More multiple failures than you believe possible, because latent errors accumulate 2. Operators cannot fully understand system because errors in implementation, measurement system, warning systems. Also complex, hard to predict interactions 3.Tendency to blame operators afterwards (60-80%), but they must operate with missing, wrong information 4.The systems are never all working fully properly: bad warning lights, sensors out, things in repair 5.Emergency Systems are often flawed. At 3 Mile Island, 2 valves in wrong position; parts of a redundant system used only in an emergency. Facility running under normal operation masks errors in error handling Learning from other fields: human error Two kinds of human error 1) slips/lapses: errors in execution 2) mistakes: errors in planning errors can be active (operator error) orlatent (design error, management error) Human errors are inevitable “humans are furious pattern-matchers” som