BurstProbe: debugging time-critical data delivery in wireless sensor networks
EWSN'11 Proceedings of the 8th European conference on Wireless sensor networks
Dependence-based multi-level tracing and replay for wireless sensor networks debugging
Proceedings of the 2011 SIGPLAN/SIGBED conference on Languages, compilers and tools for embedded systems
Detailed diagnosis of performance anomalies in sensornets
Proceedings of the 6th Workshop on Hot Topics in Embedded Networked Sensors
| Hi-index | 0.00 |
When an application on a wireless sensor network (WSN) exhibits poor post-deployment performance, users (programmers and administrators) usually do not know which nodes in the network, nor which pieces of debugging information are relevant to the determination of causes of the performance problem. Blind logging and collection of information on all nodes and/or links for the purpose of debugging, however, are energy expensive and sometimes ineffective. To address this problem, we need algorithms and tools that help users pinpoint the causes of application performance problems, and then provide useful hints for fixing them or further examination. To meet this need, we propose a data-centric approach called post-deployment performance debugging (PD2). PD2 focuses on the data flows that an application generates, and relates poor application performance to significant data losses or latencies of some data flows (problematic data flows) as they go through the software modules on individual nodes and through the network. PD2 derives a few inference rules based on the data dependencies between different software modules, as well as between different nodes, and use them to trace back in each problematic flow. Then, PD2 turns on the performance monitoring of, and collects debugging information from, only those modules and nodes that the problematic flows go through. Finally, PD2 provides the debugging information to help users isolate the causes of poor performance. We have implemented PD2 on TinyOS and evaluated it on a real WSN testbed. Our experimental results show that PD2 helps users quickly locate the possible sources of problems, such as code bugs, weak links, and radio interference. Depending on the hop-count between the source of the problem and the data sink, PD2’s energy consumption (communication overhead) is shown to be only 5–10% of that of collecting debugging information from all nodes.