Transcript Massive Cluster Clusters Gigabit Ethernet System Design for Vastly Diverse Devices David Culler U.C. Berkeley HP Visit 3/9/2000 Q1: How do we get arbitrarily powerful, personalized services on arbitrarily small devices.

Massive Cluster
Clusters
Gigabit Ethernet
System Design for
Vastly Diverse
Devices
David Culler
U.C. Berkeley
HP Visit
3/9/2000
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!
Devices
1/20/2000
River Project
Laptops, Desktops2
Q2: How do we enabled distributed
innovation on Scalable, Available
Services?
Clients
Open
Infrastructure
Services
Clients
Clients
Clients
Clients
Servers
Clients
Servers
Servers
=> Push services into an Active infrastructure
1/20/2000
River Project
3
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
4
Structured Approach
• Scalable Infrastructure
–
–
–
–
highly available
persistent state (safe)
databases, agents
service programming environment
Service
Path
• Active Proxies
– connected to the infrastructure
– soft-state
– receptive exec. env.
• Ubiquitous Devices
– billions
– sensors / actuators
– PDAs / smartphones / PCs
– heterogeneous
1/20/2000
River Project
5
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
6
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
7
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
8
Device Access Architecture
low power
local device
link
Physical
Device
Scalable, Available
Ninja Base
AP
Dev MC
persistent
named
representative
Clients
Services
AP
AP
• infra proxy provides name, state, queuing, etc.
• extend toward AP as optimization
1/20/2000
River Project
9
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
River Project
1/20/2000
10
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
Complex array
of
Sensors and
actuators
Network link:
- EIDE, SCSI
- FCAL, SSA
- USB, 1394
- ???
– but several simplifying assumptions must be removed
1/20/2000
River Project
11
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
12
Tiny OS microthreading
• Focus on concurrency and
modularity
• TOS Component:
–
–
–
–
CMD Handlers
MicroThreads
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:
Event Handlers
Sensor app
pkt
dbg
scheduling
phot
temp
RFM serial
– 8 kB inst, 512 B data
1/20/2000
River Project
13
Key building blocks
• Low power controller
with stream devices
Application
Tiny Kernel
Tiny flow drivers
RF tcvr
X
– X = sensor + actuator for
devices
– X = host interface for AP and
Embedded server
host
a
s
s
a
svr
sa
1/20/2000
River Project
14
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
Project
• They have to “work River
or die!”
1/20/2000
15