1 / 14

Lightweight Tracing For Wireless Sensor Networks Debugging

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.

kineta
Download Presentation

Lightweight Tracing For Wireless Sensor Networks Debugging

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. 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

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

  3. 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 poorreliability • Developing reliable WSN applications is very challenging

  4. 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

  5. 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

  6. 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)

  7. 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

  8. 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

  9. Trace Example: Surge Application • 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, [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 21, 112, 5, 176, 160, 5, 133, 256, 5, 240, 224, 5, 208, 5, 192, 5 => 200 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

  10. Pretty-Printed Trace Repeating Patterns in Surge Start up Trace in Surge <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 <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]

  11. 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)

  12. Evaluation : Results

  13. 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 [Osterlind 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]

  14. 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

More Related