View
213
Download
0
Tags:
Embed Size (px)
Citation preview
Clusters
Massive Cluster
Gigabit Ethernet
System Design for Vastly Diverse
Devices
David Culler
U.C. Berkeley
HP Visit
3/9/2000
1/20/2000 River Project 2
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
1/20/2000 River Project 3
Q2: How do we enabled distributed innovation on Scalable, Available Services?
Servers
Clients
ClientsClients
ClientsClients
Clients
Servers
Servers
=> Push services into an Active infrastructure
Infrastructure Services
Open
1/20/2000 River Project 4
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
1/20/2000 River Project 5
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
1/20/2000 River Project 6
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
1/20/2000 River Project 7
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
1/20/2000 River Project 8
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
1/20/2000 River Project 9
Device Access Architecture
• infra proxy provides name, state, queuing, etc.
• extend toward AP as optimization
PhysicalDevice
low powerlocal devicelink
AP
AP
AP
Scalable, AvailableNinja Base
Clients
Services
persistentnamedrepresentativeDev MC
1/20/2000 River Project 10
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
1/20/2000 River Project 11
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 ofSensors and actuators
Network link: - EIDE, SCSI - FCAL, SSA - USB, 1394 - ???
1/20/2000 River Project 12
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
1/20/2000 River Project 13
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
pkt dbgSensor app
1/20/2000 River Project 14
Key building blocks
• Low power controller with stream devices
– X = sensor + actuator for devices
– X = host interface for AP and Embedded serverRF tcvrX
Tiny Kernel
Tiny flow drivers
Application
host
s
a
s a
svr
sa
1/20/2000 River Project 15
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!”