Mate: A Tiny Virtual Machine for Sensor Networks
Phil Levis and David Culler
Presented by Andrew ChienCSE 291 ChienApril 22, 2003
(slides courtesy, Phil Levis)
CSE 291 Sensor Networks – 4/22/2003
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
• TinyOS 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
0 1 2 3
Subroutines
Clo
ck
Sen
d
Receive
Events
gets/sets
Co
de
OperandStack
ReturnStack
Maté
PC MateContext
CSE 291 Sensor Networks – 4/22/2003
Maté Instructions
0 1 2 3
Subroutines
Clo
ck
Sen
d
Receive
Events
gets/sets
Co
de
OperandStack
ReturnStack
Maté
PC MateContext
CSE 291 Sensor Networks – 4/22/2003
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 00iiiiii i = instruction
s-type 01iiixxx x = argument
x-type 1ixxxxxx
CSE 291 Sensor Networks – 4/22/2003
Code Snippet: cnt_to_leds
gets # Push heap variable on stackpushc 1 # Push 1 on stackadd # Pop twice, add, push resultcopy # Copy top of stacksets # Pop, set heappushc 7 # Push 0x0007 onto stackand # Take bottom 3 bits of valueputled # Pop, set LEDs to bit patternhalt #
CSE 291 Sensor Networks – 4/22/2003
cnt_to_leds, Binary
gets # 0x1bpushc 1 # 0xc1add # 0x06copy # 0x0bsets # 0x1apushc 7 # 0xc7and # 0x02putled # 0x08halt # 0x00
CSE 291 Sensor Networks – 4/22/2003
Sending a Message
pushc 1 # Light is sensor 1sense # Push light reading on stackpushm # Push message buffer on stackclear # Clear message bufferadd # Append reading to buffersend # Send message using built-inhalt # ad-hoc routing system
CSE 291 Sensor Networks – 4/22/2003
Maté Capsules
0 1 2 3
Subroutines
Clo
ck
Sen
d
Receive
Events
gets/sets
Co
de
OperandStack
ReturnStack
Maté
PC MateContext
CSE 291 Sensor Networks – 4/22/2003
Maté Capsules
• Hold up to 24 instructions• Fit in a single TinyOS 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
0 1 2 3
Subroutines
Clo
ck
Sen
d
Receive
Events
gets/sets
Co
de
OperandStack
ReturnStack
Maté
PC MateContext
CSE 291 Sensor Networks – 4/22/2003
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 TinyOS 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)
» forw» forwo
CSE 291 Sensor Networks – 4/22/2003
Forwarding: cnt_to_ledsgets # Push heap variable on stackpushc 1 # Push 1 on stackadd # Pop twice, add, push resultcopy # Copy top of stacksets # Pop, set heappushc 7 # Push 0x0007 onto stackand # Take bottom 3 bits of valueputled # Pop, set LEDs to bit patternforw # Forward capsulehalt #
CSE 291 Sensor Networks – 4/22/2003
Evaluation
• Code Propagation• Execution Rate• 42 motes: 3x14 grid• 3 hop network
» largest cell 30 motes» smallest cell 15 motes
CSE 291 Sensor Networks – 4/22/2003
Code Propagation
Network Programming Rate
0%
20%
40%
60%
80%
100%
0 20 40 60 80 100 120 140 160 180 200 220 240
Time (seconds)
Per
cen
t P
rog
ram
med
CSE 291 Sensor Networks – 4/22/2003
Code Propagation, Continued
(seconds)
Network: 1/8 Network: 1/4
New Mean Std. Dev. Mean Std. Dev
1/8 23 8 28 15
1/4 10 4 10 4
1/2 7 3 7 2
1/1 8 2 12 5
Network: 1/2 Network: 1/1
New Mean Std. Dev. 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, 8K 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?