1. Clusters Massive Cluster Gigabit Ethernet System Design for Vastly Diverse Devices David Culler U.C. Berkeley HP Visit 3/9/2000

2. 1/20/2000River Project2 Q1: How do we get arbitrarily powerful, personalized services on arbitrarily small devices anywhere? Harness the intelligence in the infrastructure –adapt (distill) content to specific device and context –increasingly diverse population Connectivity! Laptops, Desktops Devices

3. 1/20/2000River Project3 Q2: How do we enabled distributed innovation on Scalable, Available Services? Servers Clients Servers => Push services into an Active infrastructure Infrastructure Services Open

4. 1/20/2000River Project4 Q3: how do we integrate zillions of tiny, semi-autonomous devices into the computational world? Find them Organize them Orchestrate them Build services upon them –using information/data they provide –influencing the world through them Make them reliable, easy to use (program) Cope with tremendous heterogeneity

5. 1/20/2000River Project5 Structured Approach Active Proxies –connected to the infrastructure –soft-state –receptive exec. env. Ubiquitous Devices –billions –sensors / actuators –PDAs / smartphones / PCs –heterogeneous Service Path Scalable Infrastructure –highly available –persistent state (safe) –databases, agents –service programming environment

6. 1/20/2000River Project6 Project Components Platform for Open, Scalable, Available Infrastructure Services - ninja.cs –service composition (lookup, msg, negotiation) –scalability, availability built into the platform High-level Communications / Services Architecture Simple / robust Tiny OS –microthreading for concurrency intensive environment Tiny MAC (that isn’t braindead) Sample devices –embedded servers –sensors, actuators, personal devices

7. 1/20/2000River Project7 Zillions of Little Devices Connected device as client is well-established –distiller in the infrastructure spoonfeeds client »powerful services in power-limited devices! –How to get the illusion of continuous connectivity? What about sensors-based devices? –they should behave as servers »eg: camera server –How to scale tiny server to need? –How to get illusion of continuous connectivity? »use the infrastructure

8. 1/20/2000River Project8 Architecture Assumptions Computation and storage in the infrastructure is plentiful Wired bandwidth is pervasive and essentially free => every device has a representative proxy in the infrastructure

9. 1/20/2000River Project9 Device Access Architecture infra proxy provides name, state, queuing, etc. extend toward AP as optimization Physical Device low power local device link AP Scalable, Available Ninja Base Clients Services persistent named representative Dev MC

10. 1/20/2000River Project10 Towards Principles for Simple OS Communication is fundamental –treated as part of the hardware. No comm is like no power –you don’t bring up the device then “configure comm.” Concurrency intensive –schedule data movement and events, not arbitrary threads of computation hands off: a direct “user interface” is the exception not the norm need extreme reliability and ease of development for distinct, specialized devices => Micro threads operating against storage “chunks” => constant self-checking and telemetry –rely on the infrastructure for hard stuff

11. 1/20/2000River Project11 Escape the “486” OS trap Operating systems that are not called “operating systems” eg: modern disk controller –event scheduler handling stream of commands from network link, controlling complex array of sensors and actuators, performing sophisticated calculations to determine what and when (scheduling and caching) as well as transforming data on the fly –automatic connection, enumeration, configuration –but several simplifying assumptions must be removed Complex array of Sensors and actuators Network link: - EIDE, SCSI - FCAL, SSA - USB, 1394 - ???

12. 1/20/2000River Project12 OS as little more than FSM Primary focus is scheduling discrete chunks of data movement –not general thread scheduling and unlimited memory management –there may be a bounded amount of work to xform or check data Commands are an event stream merged with sensor/actuator events General thread must be compiled to sequence of bounded atomic transactions –spagetti part of an application is configuring the flows –steady-state is straight-forward event processing + signaling unusual events Simplify network-based debug and mgmt

13. 1/20/2000River Project13 Tiny OS microthreading Focus on concurrency and modularity TOS Component: –command handlers: API –event handlers: ADI –bounded state –state-transitions threads Base Component per device Integration components compose flows into application ex: atmel/RFM mote: –8 kB inst, 512 B data MicroThreads Event Handlers CMD Handlers RFMtempphot serial scheduling pktdbg Sensor app

14. 1/20/2000River Project14 Key building blocks Low power controller with stream devices –X = sensor + actuator for devices –X = host interface for AP and Embedded server RF tcvr X Tiny Kernel Tiny flow drivers Application host s a s a svr sasa

15. 1/20/2000River Project15 Convergence at the Extremes Powerful Services on “Small” Devices –massive computing and storage in the infrastructure –active adaptation of form and content “along the way” Illusion of Tiny Servers via infra. proxies Extremes more alike that either is to the middle –More specialized in function –Communication centric design »wide range of networking options –Federated System of Many Many Systems –Hands-off operation, mgmt, development –High Reliability, Availability –Scalability –Power and space limited –simplicity They have to “work or die!”