Mate A Tiny Virtual Machine for Sensor Networks

Mate: A Tiny Virtual Machine for Sensor Networks Phil Levis and David Culler Presented by Andrew Chien CSE 291 Chien April 22, 2003 (slides courtesy, Phil Levis)

Maté • • • Motivation Overview Architecture, Instructions Viral code Evaluation Conclusion CSE 291 Sensor Networks – 4/22/2003

Motivation • Programming complexity » Low level » Error Prone • Application flexibility (? ) • Binary reprogramming takes ~2 minutes » significant energy cost » can lose motes • Idea: use a virtual machine – load the programs as structures pointing to lower level libraries CSE 291 Sensor Networks – 4/22/2003

Sensor Network Programming Requirements • Small (fit on Motes) • Expressive (lots of applications) • Concise (programs short for memory and network bandwidth) • Resilient (don’t crash the system) • Efficient (in sensing and communication) • Tailorable – for application-specific operations • Simple – in-situ, fast, “autonomous” programming CSE 291 Sensor Networks – 4/22/2003

Maté Overview • • Tiny. OS component 7286 bytes code, 603 bytes RAM Three concurrent execution contexts Stack-based bytecode interpreter Code broken into 24 instruction capsules Self-forwarding code Rapid reprogramming Message receive and send contexts CSE 291 Sensor Networks – 4/22/2003

Maté Overview, Continued • Three execution contexts » Clock, Receive, Send • Seven code capsules » Clock, Receive, Send, Subroutines 0 -3 • One word heap » gets/sets instructions • Two-stack architecture » Operand stack, return address stack CSE 291 Sensor Networks – 4/22/2003

Maté Architecture Subroutines 3 Receive 2 Send 1 Clock 0 Events Maté gets/sets Code PC CSE 291 Sensor Networks – 4/22/2003 Operand Stack Return Stack Mate Context

Maté Instructions Subroutines 3 Receive 2 Send 1 Clock 0 Events Maté gets/sets Code PC CSE 291 Sensor Networks – 4/22/2003 Operand Stack Return Stack Mate Context

Maté Instructions • Two-stack architecture • One byte per instruction • Three classes: basic, s-type, x-type » basic: data, arithmetic, communication, sensing » s-type: used in send/receive contexts » x-type: embedded operands basic 00 iiiiii i = instruction s-type 01 iiixxx x = argument x-type 1 ixxxxxx CSE 291 Sensor Networks – 4/22/2003

Code Snippet: cnt_to_leds gets pushc 1 add copy sets pushc 7 and putled halt # # # # # Push heap variable on stack Push 1 on stack Pop twice, add, push result Copy top of stack Pop, set heap Push 0 x 0007 onto stack Take bottom 3 bits of value Pop, set LEDs to bit pattern CSE 291 Sensor Networks – 4/22/2003

cnt_to_leds, Binary gets pushc 1 add copy sets pushc 7 and putled halt CSE 291 Sensor Networks – 4/22/2003 # # # # # 0 x 1 b 0 xc 1 0 x 06 0 x 0 b 0 x 1 a 0 xc 7 0 x 02 0 x 08 0 x 00

Sending a Message pushc 1 sense pushm clear add send halt # # # # Light is sensor 1 Push light reading on stack Push message buffer on stack Clear message buffer Append reading to buffer Send message using built-in ad-hoc routing system CSE 291 Sensor Networks – 4/22/2003

Maté Capsules Subroutines 3 Receive 2 Send 1 Clock 0 Events Maté gets/sets Code PC CSE 291 Sensor Networks – 4/22/2003 Operand Stack Return Stack Mate Context

Maté Capsules • Hold up to 24 instructions • Fit in a single Tiny. OS AM packet » Installation is atomic • • Four types: send, receive, clock, subroutine Context-specific: send, receive, clock Called: subroutines 0 -3 Version information CSE 291 Sensor Networks – 4/22/2003

Maté Contexts Subroutines 3 Receive 2 Send 1 Clock 0 Events Maté gets/sets Code PC CSE 291 Sensor Networks – 4/22/2003 Operand Stack Return Stack Mate Context

Contexts • Each context associated with a capsule • Executed in response to event » external: clock, receive » internal: send (in response to sendr) • Execution model » preemptive: clock » non-preemptive: send, receive • Every instruction executed as Tiny. OS task CSE 291 Sensor Networks – 4/22/2003

Viral Code • Every capsule has version information • Maté installs newer capsules it hears on network • Motes can forward their capsules (local broadcast) » forwo CSE 291 Sensor Networks – 4/22/2003

Forwarding: cnt_to_leds gets pushc 1 add copy sets pushc 7 and putled forw halt # # # # # Push heap variable on stack Push 1 on stack Pop twice, add, push result Copy top of stack Pop, set heap Push 0 x 0007 onto stack Take bottom 3 bits of value Pop, set LEDs to bit pattern Forward capsule CSE 291 Sensor Networks – 4/22/2003

Evaluation • • Code Propagation Execution Rate 42 motes: 3 x 14 grid 3 hop network » largest cell 30 motes » smallest cell 15 motes CSE 291 Sensor Networks – 4/22/2003

Code Propagation CSE 291 Sensor Networks – 4/22/2003

Code Propagation, Continued (seconds) New Network: 1/8 Network: 1/4 Mean Std. Dev 1/8 23 8 28 15 1/4 10 4 1/2 7 3 7 2 1/1 8 2 12 5 New Network: 1/2 Network: 1/1 Mean Std. Dev 1/8 45 24 361 252 1/4 19 10 425 280 1/2 21 10 226 199 1 14 4 400 339 CSE 291 Sensor Networks – 4/22/2003

Maté Instruction Issue Rate • ~10, 000 instructions per second • Task operations are 1/3 of Maté overhead CSE 291 Sensor Networks – 4/22/2003

Energy Consumption • • Compare with binary reprogramming Maté imposes a CPU overhead Maté provides a reprogramming time savings Energy tradeoff CSE 291 Sensor Networks – 4/22/2003

Case Study: GDI • • • Great Duck Island application Simple sense and send loop Runs every 8 seconds – low duty cycle 19 Maté instructions, 8 K binary code Energy tradeoff: if you run GDI application for less than 6 days, Maté saves energy CSE 291 Sensor Networks – 4/22/2003

Summary / Discussion • Spectrum of reprogramming » Native code; Bytecode interpreter » How important is flexibility? » Is a viral model reasonable? Security? • VM’s provide opportunities, but also overhead » Interpretive overhead is *high* » If operations are large enough (e. g. send), overhead is negligible (3000% to 3%) » What is a realistic mix? » Opportunity for managing heterogeneity and evolution? CSE 291 Sensor Networks – 4/22/2003

Right requirements? • Small (fit on Motes) • Expressive (lots of applications) • Concise (programs short for memory and network bandwidth) • Resilient (don’t crash the system) • Efficient (in sensing and communication) • Tailorable – for application-specific operations • Simple – in-situ, fast, “autonomous” programming • => and does it meet them? CSE 291 Sensor Networks – 4/22/2003