Slide 1/14 Midsens ’09 – December 1, 2009 Lightweight Tracing For Wireless Sensor Networks...

/14Midsens ’09 – December 1, 2009

Lightweight Tracing For Wireless Sensor Networks Debugging

Vinaitheerthan Sundaram*, Patrick Eugster, Xiangyu Zhang

School of Electrical and Computer Engineering*Department of Computer Science

Purdue University

Work supported by:National Science Foundation


Talk Outline

• Motivation and Problem Setup• Lightweight Tracing• Compression Techniques• Example Traces• Evaluation• Related Work• Summary and Future Work


Introduction to WSNs

• Wireless Sensor Networks (WSNs)– Consists of many tiny, battery powered, wireless motes

– Cooperatively monitors physical or environmental conditions such as temperatures, sound, vibration, pressure, etc.

• WSNs have many useful applications– Habitat monitoring, Military Surveillance, Volcano

Monitoring, Glacier Monitoring

• However, WSNs have not been widely deployed in large-scale yet mainly because of poor reliability

• Developing reliable WSN applications is very challenging


WSN Debugging Challenges• Challenges in debugging and maintaining WSN

applications are– inherent resource constraints– in-situ deployment in harsh environments– lack of run-time support tools

• Run-time debugging tools are especially required because – Unexpected interaction with the real-world environment lead to

complex run-time faults such as race-conditions

• Replay Debugging is a powerful debugging technique for distributed systems[Geels-Usenix06]

• To support replay, we need a light-weight tracing mechanism


Lightweight Tracing Framework

• Novel control flow tracing and encoding scheme – Enables replay debugging

– Identifies repetitive computation, thus enabling high compression

• Lightweight – We show it satisfies the stringent resource constraints

• Trace Storage– Supports storing the trace in non-volatile Flash memory

– Least recent trace is overwritten

• Trace Query– Support simple query mechanism that sends the trace data to

the base station upon request


Ball-Larus Algorithm With Example

• Label each control-flow path with an unique identifier

• Inserts increments only when there is a fork in control-flow graph (conditional or loops)


Lightweight Tracing

• Instrumentation – Annotate procedure P with BL path count

– Instrument procedure P to record • start of P

• end of P and pathCount atomically

• Tracer– Assign unique identifier for procedure P’s every invocation

• procLabel = procID + sessionID

– Record trace in local buffers

– When a buffer is full, compress and store it in flash

• Compression– Simple, Pattern Replacement and Loop Compression


Lightweight Tracing Compression

• Simple Compression– Combine start and end symbols of a procedure if the procedure

was not interrupted

• Pattern Replacement– WSN applications repeats same sequence of procedures

– Represent these sequences with special symbols

– Can significantly reduce the trace size

– Control-flow encoding helps us identify it

• Loop Compression– Since loops follow identical paths in many iterations, represent

these with path id and repetition count


Trace Example: Surge Application

64, 48, 5, 32, 5, 16, 5, 336, 5, 5, 0, 96, 80, 5, 5, 176, 160, 5, 133, 256, 5, 240, 224, 5, 208, 5, 192, 5, [21, 112, 5, 176, 160, 5, 133, 256, 5, 240, 224, 5, 208, 5, 192, 5], [21, 112, 5, 176, 160, 5, 133, 256, 5, 240, 224, 5, 208, 5, 192, 5], [21, 112, 5, 176, 160, 5, 133, 256, 5, 240, 224, 5, 208, 5, 192, 5], [21, 112, 5, 176, 160, 5, 133, 256, 5, 240, 224, 5, 208, 5, 192, 5], 21, 112, 5

• Surge Application– a typical data-collection application in TinyOS that samples light sensor

every 2 seconds and sends the sensed data to the base station using multihop routing layer

• First 20 seconds of trace

64, 48, 5, 32, 5, 16, 5, 336, 5, 5, 0, 96, 80, 5, 5, 176, 160, 5, 133, 256, 5, 240, 224, 5, 208, 5, 192, 5, [200], [200], [200], [200], 21, 112,5

21, 112, 5, 176, 160, 5, 133, 256, 5, 240, 224, 5, 208, 5, 192, 5 => 200


Pretty-Printed Trace

<SurgeM__StdControl__init> start <SurgeM__Leds__init> start <SurgeM__Leds__init> end 0 <SurgeM__Leds__yellowOff> start <SurgeM__Leds__yellowOff> end 0 <SurgeM__Leds__redOff> start <SurgeM__Leds__redOff> end 0 <SurgeM__initialize> start <SurgeM__initialize> end 0<SurgeM__StdControl__init> end 0<SurgeM__StdControl__start> start <SurgeM__Timer__start> start <SurgeM__Timer__start> end 0<SurgeM__StdControl__start> end 0

[Continued on the right side]

<SurgeM__Timer__fired> start <SurgeM__ADC__getData> start <SurgeM__ADC__getData> end 0<SurgeM__Timer__fired> end 8<SurgeM__ADC__dataReady> start<SurgeM__ADC__dataReady> end 0<SurgeM__SendData> start <SurgeM__Send__getBuffer> start <SurgeM__Send__getBuffer> end 0 <SurgeM__RouteControl__getParent> start <SurgeM__RouteControl__getParent> end 0 <SurgeM__Send__send> start <SurgeM__Send__send> end 0<SurgeM__SendData> end 1<SurgeM__Send__sendDone> start<SurgeM__Send__sendDone> end 0<SurgeM__Timer__fired> start <SurgeM__ADC__getData> start

Start up Trace in Surge Repeating Patterns in Surge


Evaluation • Case Study - CC1000 Radio Deadlock

• Runtime Overhead– Benchmark Programs:

• Blink – Simple application but highlights overhead

• Surge – Typical WSN application with period 2 seconds

• Oscilloscope – Timer fires every 125 ms and can generate a lot of trace

– Metrics: Trace Size, Program Memory, Data Memory

– Compression efficiency is measured using Space-Savings Ratio• Space saving ratio = (Uncompressed – Compressed) / Uncompressed

• Our results indicate– Traces can be highly compressed as much as 91.74%

– Trace size varies from 1KB/Hr to 50KB/Hr

– Low memory footprint about 300B

– Low program memory about (5KB)


Evaluation : Results


Related Work• Automating Debugging

– Tracing but no control-flow traces• NodeMD [Krunic et al., Mobisys ‘07], EnviroLog [Luo et al., Infocom ‘06], DustMiner [Khan et al.,

SenSys ‘08], Checkpointing [OOsterlind et al., EWSN ‘09]

– Focuses on node, link or network failures only• Sympathy [Ramanathan et al., SenSys ‘05], PAD [Liu et al., Sensys ‘08]

– Debugging interface or error detection but not diagnosis• Declarative TracePoints [Cao et al. SenSys ‘08], HSEND [Herbert et al., TAAS ‘06]

• Visibility– Remote access and control but very expensive

• Clairvoyant [Yang et al. SenSys ‘08], Marionette [Whitehouse et al., IPSN ‘06]

• Program Analysis– Testing or program comprehension but not tracing

• [Lai et al., FSE ‘08],

• [Kothari et al. IPSN ‘08]


Summary and Future Work

• We showed program tracing can be done efficiently and accurately in WSN through– Novel trace encoding and compression schemes

• We are exploring multiple aspects– Trace size reduction through

• Inter-procedural tracing

• Unrolling of loops

• LZW compression schemes

– Multi-node Tracing

– Query Support for portions of trace

Slide 1/14 Midsens ’09 – December 1, 2009 Lightweight Tracing For Wireless Sensor Networks...

Documents

Transcript of Slide 1/14 Midsens ’09 – December 1, 2009 Lightweight Tracing For Wireless Sensor Networks...