Year: 2004
Type: article
Abstract: Sympathy: A Debugging System for Sensor Networks Nithya Ramanathan, Eddie Kohler, Lewis Girod, and Deborah Estrin UCLA Center for Embedded Network Sensing nithya, kohler, girod, destrin @cs.ucla.edu I. I NTRODUCTION Sensor networks—networks of small, resource-constrained wireless devices embedded in a dynamic physical environment—have led to new algorithm, protocol, and operating system designs [1], [2]. Interactions between sensor hardware, protocols, and environmental characteristics are impossible to predict, so sensor network application design is an iterative process between debugging and deployment [3]. Current debugging techniques fall short for systems which contain bugs characteristic of both distributed and embedded systems. Such bugs can be difficult to track because they are often multicausal, non-repeatible, timing-sensitive and have ephemeral triggers such as race conditions, decisions based on asynchronous changes in distributed state, or interactions with the physical environment. Furthermore, it is a challenge to extract debugging information from a running system without introducing the probing effect (alteration of normal behavior due to instrumentation) or draining excessive energy. This paper presents a preliminary design and evaluation of Sympathy, a debugging tool for pre-deployment sensor networks and motivated by Ruan and Pai’s DeBox system [4]. Sympathy consists of mechanisms for collecting system per- formance metrics with minimal memory overhead; mecha- nisms for recognizing events based on these metrics; and a system for collecting events and their spatio-temporal context. Sympathy introduces the idea of correlating seemingly un- related events, and providing context for these events, in order to track down bugs and find their root causes. Using Sympathy we have begun to distill out the important metrics, events and generic correlators that help find bugs quickly, and to transmit this data in ways that minimize energy consumption and probing effects. This process is ongoing. Our current con- tribution, then, is a tool that can be used for pre-deployment debugging, and for analysis on the role of a debugging tool in the entire design process. Eventually, Sympathy will be part of a system that can aid in debugging sensor networks both pre- and post-deployment. Below we present a useful case study that demonstrates our current contributions by showing how Sympathy was used to debug a failure in tiny diffusion. In related work, [5] and [6] address the data collection aspects of post-deployment debugging, but focus on the mech- anism to gather statistics instead of their content. Our work is complementary, since Sympathy is so far mostly concerned with content: discovering the most useful metrics to collect. Simulations and visualization tools are also helpful, but do not capture historical context or aid in determining the cause of a failure. While log files can provide context to a failure, they often contain excessive data which can obfuscate impor- tant events. Sympathy distinguishes itself from passive data logging approaches by proactively collecting and highlighting potentially relevant events and their context in order to aid in isolating their causes. II. A RCHITECTURE Sympathy´ general architecture is as follows: Sympathy s collects metrics from all nodes and watches the metrics for indications of events, which are metric changes that often indicate important changes in application state. On inferring an event, Sympathy: 1) Stores all metrics it has collected from the past 200 time units for the node causing the trigger, providing temporal context. 2) Stores all metrics it has collected from the past 200 time units for the nodes neighboring the node where the event was detected, providing spatial context. 3) Prints event and context information to a log file, which can aid in correlating events. 4) Calls applications interested in the event. The version of Sympathy described here collects four metrics: neighbor lists, link quality, nodes’ top two choices for next hop, and associated next-hop path loss. It watches for two types of events based on these metrics, namely missing or isolated nodes and changes in route selection, neighbor lists, or link quality. III. E VALUATION To demonstrate Sympathy’s potential as a debugging tool, we ran it with a nesC implementation of tiny diffusion [7], a routing algorithm based on directed diffusion [8]. In tiny diffusion, nodes periodically flood neighbor beacons (to cal- culate link quality), neighbor lists and associated link qualities (to identify assymetric links), and gradients which carry a node’s next hop and projected path loss (to determine a node’s next hop). We debugged this system pre-deployment, using simulations on a 14-node network that ran for two hours. Our goal was to determine why tiny diffusion had been experiencing loss rates an order of magnitude higher than expected in data delivery to the sink. After the first run, using the events triggered in Sympathy, we saw nodes change their next-hop selection approximately every 170 seconds. Sympathy aided over traditional debugging techniques by highlighting the frequent changes in next-hop selection and providing spatial correlation, which revealed that
Language: English
Subfield: Software
Field: Computer Science
Domain: Physical Sciences
Open Access status: green
OpenAlex ID: W1487613753