Check out the new USENIX Web site. next up previous
Next: Performance of Model-Driven Push Up: Experimental Evaluation Previous: Experimental Evaluation

Microbenchmarks

Our first experiment involves a series of microbenchmarks of the energy consumption of communication, processing and storage to evaluate individual components of the PRESTO proxy and sensors. These microbenchmarks are based on measurements of two sensor platforms -- a Telos mote, and a Mica2 mote augmented with a NAND flash storage board fabricated at UMass. The board is attached to the Mica2 mote through the standard 51-pin connector, and provides a considerably more energy-efficient storage option than the AT45DB041B NOR flash that is loaded by default on the Mica2 mote [15]. The NAND flash board enables the PRESTO sensor to archive a large amount of historical data at extremely low energy cost.


Table 1: Energy micro-benchmarks for sensor nodes.
Module Component Operation Energy
NAND flash-enabled Mica2 NAND Flash Read + Write + Erase 1 sample 21nJ
ATmega128L Processor 1 Prediction 240nJ

CC1000 Radio Transmit 1 sample + Receive 1 ACK 20.3$ \mu$J
Telos Mote ST M25P80 Flash Read + Write + Erase 1 sample 2.14$ \mu$J

MSP430 Processor 1 Prediction 27nJ

CC2420 Radio Transmit 1 sample + Receive 1 ACK 3.3$ \mu$J



Table 2: Round trip latencies using B-MAC
Round Trip Latency(ms)
Routing Hops 1% 7.53% 35.5%
1-hop 2252 350 119
2-hop 4501 695 235
3-hop 6750 1040 347
4-hop 8999 1388 465
5-hop 11249 1733 580


Energy Consumption: We measure the energy consumption of three components--computation per sample at the sensor, communication for a push or pull, and storage for reads, writes and erases. Table 1 shows that the results depend significantly on the choice of platform. On the Mica2 mote with external NAND flash, storage of a sample in flash is an order of magnitude more efficient than the ARIMA prediction computation, and three orders of magnitude more efficient than communicating a sample over the CC1000 radio. The Telos mote uses a more energy-efficient radio (CC2420) and processor (TI MSP 430), but a less efficient flash than the modified Mica2 mote. On the Telos mote, the prediction computation is the most energy-efficient operation, and is 80 times more efficient than storage, and 122 times more efficient than communication. The high cost of storage on the Telos mote makes it a bad fit for a storage-centric architecture such as PRESTO.

In order to fully exploit state-of-art in computation, communication and storage, a new platform is required that combines the best features of the two platforms that we have measured. This platform would use the TI MSP 430 microcontroller and CC2420 radio on the Telos mote together with NAND flash storage. Assuming that the component-level microbenchmarks in Table 1 hold for the new platform, storage and computation would be roughly equal cost, whereas communication would be two to three orders of magnitude more expensive than both storage and communication. We note that the energy requirements for communication in all the above benchmarks would be even greater if one were to include the overhead due to duty-cycling, packet headers and multi-hop routing. These comparisons validate our key premise that in future platforms, storage will offer a more energy-efficient option than communication and should be exploited to achieve energy-efficiency.


Table 3: Asymmetry: Model estimation vs Model checking
Component Operation Latency Energy
Stargate (PXA255) Model Estimation 21.75ms 11mJ
Telos Mote (MSP430) Predict One Sample 18$ \mu s$ 27nJ


Figure 3: Comparison of PRESTO SARIMA models with model-driven pull and value-driven push.
Image algcomp_dt Image algerr_dt
(a) Communication Cost (b) Mean Square Error
Figure 4: Scalability of PRESTO: Impact of network size.
Image latency_nm
 

Communication Latency: Our second microbenchmark evaluates the latency of directly querying a sensor node. Sensor nodes are often highly duty-cycled to save energy, i.e. their radios are turned off to reduce energy use. However, as shown in Table 2, better duty-cycling corresponds to increased duration between successive wakeups and worse latency for the CC1000 radio on the Mica2 node. For typical sensor network duty-cycles of 1% or less, the latency is of the order of many seconds even under ideal 100% packet delivery conditions. Under greater packet-loss rates that are typical of wireless sensor networks [25], this latency would increase even further. We are unable to provide numbers for the CC2420 radio on the Telos mote since there is no available TinyOS implementation of an energy-efficient MAC layer with duty-cycling support for this radio.

Our measurements validate our claim that directly querying a sensor network incurs high latency, and this approach may be unsuitable for interactive querying. To reduce querying latency, the proxy should handle as many of the queries as possible.

Asymmetric Resource Usage: Table 3 demonstrates how PRESTO exploits computational resources at the proxy and the sensor. Determining the parameters of the ARIMA model at the proxy is feasible for a Stargate-class device, and requires only 21.75 ms per sensor. This operation would be very expensive, if not infeasible, on a Telos Mote due to resource limitations. In contrast, checking if the model is correct at the Mote consumes considerably less energy since it consists of only three floating point multiplications (approximated using fixed point arithmetic) and five additions/subtractions corresponding to Equation 3. This validates the design choice in PRESTO to separate model-building from model-checking and to exploit proxy resources for the former and resources at the sensor for the latter.

Summary: Our microbenchmarks validate three design choices made by PRESTO--the need for a storage-centric architecture that exploits energy-efficient NAND flash storage, the need for proxy-centric querying to deal with high latency of duty-cycled radios, and exploiting proxy resources to construct models while performing only simple model-checking at the sensors.

Figure 5: Scalability of PRESTO: Impact of query rates.
Image latency_qr Image droprate_qr Image pullrate_qr
(a) Query Latency (b) Query Drop Rate (c) Query Miss Rate


next up previous
Next: Performance of Model-Driven Push Up: Experimental Evaluation Previous: Experimental Evaluation
root 2006-03-29