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!”