1 / 10

Packing for the Expedition

Packing for the Expedition. David Culler. Ongoing Endeavors. Millennium: building a large distributed experimental testbed Berkeley Cluster Software Distribution (v1.0 9/99) automated configuration & mgmt, rexec, SAN, ... Ninja: software platform for scalable, customizable services

dykesjohn
Télécharger la présentation

Packing for the Expedition

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Packing for the Expedition David Culler

  2. Ongoing Endeavors • Millennium: building a large distributed experimental testbed • Berkeley Cluster Software Distribution (v1.0 9/99) • automated configuration & mgmt, rexec, SAN, ... • Ninja: software platform for scalable, customizable services • fast, direct data transfers • PostPC departmental environment • wireless networking, small devices, embedded kiosks • networked services

  3. Tech. Prob: Architecture for Billions of Devices • option 1: operating systems design for diverse • option n: negotiation architecture • option n+1: vast data storage and transfer • simple devices => opportunity to design and build interesting simple operating systems! • communication centric • not mgmt of threads and address spaces • confluence in the very large and very small • simple and fast

  4. What I’m looking for in an Architecture for Billions of Devices Simplifiers

  5. Software Perspective • I want to write a “program” today that will deploy itself across a spectrum of devices that we haven’t yet imagined. • what happens where? • how does it adapt? to what? • Much easier to adapt within a framework than to organize from scratch

  6. Simplifying Concepts • Reservoirs • Flows • Self-Checking

  7. Key Extensions • active elements in the protocol hierarchy • intermittent connection • narrow interface with commitment • Pilot --- RMI Proxy --- Ninja Service Prototype • device OS = protocol engine Comm = Location independent Access to shared storage resv • Key Concepts from Parallel Architecture • hierarchical composition of cache-coherence protocols + consistency models • natural framework for adaptation (pull what you touch)

  8. Flows • View data transfers as continuous flows • plumbing as programming model • reservoirs provide slack • trade bandwidth for robustness • Natural form of adaptation • ex: faster consumer gets more data • flow equations provide goal, simple error bounds, and react • performance availability • Flow units become dominant scheduling entity for device = net + sensor/actuator • device OS = flow regulator • Several RIVER prototype for many disks

  9. Self-Checking • Not diagnostic self-test • Actions should have observable consequences • treat them as goals, check that they are met • Example • Printer/Scanner • Switch + Light + Photosensor • Configure relationships and derive operations

  10. Plan • Now to One Year • many small device distributed simulation tool • prototype cache data pad • prototype smart-rocks flow OS • Three Year • develop / obtain many small well-connected devices • integrate with large infrastructure • production quality SimpleOS • small set of building blocks • formal system for composition • demonstrate easy access to massive data • demonstrate high bandwidth flows through small devices

More Related