HarvOS

Abstract

We present code instrumentation strategies to allow transiently-powered embedded sensing devices efficiently checkpoint the system's state before energy is exhausted. Our solution, called HarvOS, operates at compile-time with limited developer intervention based on the control-flow graph of a program, while adapting to varying levels of remaining energy and possible program executions at run-time. In addition, the underlying design rationale allows the system to spare the energy-intensive probing of the energy buffer whenever possible. Compared to existing approaches, our evaluation indicates that HarvOS allows transiently-powered devices to complete a given workload with 68% fewer checkpoints, on average. Moreover, our performance in the number of required checkpoints rests only 19% far from that of an "oracle" that represents an ideal solution, yet unfeasible in practice, that knows exactly the last point in time when to checkpoint. CCS CONCEPTS•Computer systems organization →Embedded systems; Sensor networks;

On intermittence bugs in the battery-less internet of things (WIP paper)

“…We conduct an early assessment of the techniques that also evaluate the effects of intermittence bugs. We select a set of common benchmarks in intermittent computing [1][2][3]21]: CRC computation, FFT for signal analysis, and AES for encryption. The benchmarks are taken from MiBench2 [18], that is, MiBench [8] ported to IoT devices [25].…”

Enabling intermittent computing on high-performance out-of-order processors

“…Reliable and efficient state retention through power cycles is the main priority in IC. Conflicting design goals such as having minimal hardware dependency [7,16,20], minimizing the number of snapshots written during a power cycle [3,4,7], reducing the size of snapshots [6,7,11,14] and maintaining compatibility with existing codebases [3,4] has driven research into fundamentally diverging approaches. In order to determine the most suitable approach for high-performance systems, we introduce a taxonomy based on the following three classes of IC strategies.…”

“…The circles show the latest snapshot before power is lost; any computation after the latest snapshot is a waste of resources. Note that some task-based or static approaches may avoid wasted computation after a checkpoint by measuring stored energy and comparing it to predictions [7] or observations [12] of the energy required to reach the next task-boundary or checkpoint.…”

“…Static IC approaches are based on instrumenting application code with checkpoints by the user during application development, or automatically at compile time [7,20]. Because the checkpoints are inserted a priori, offline analysis of program execution and control flow graphs can be applied.…”

“…Because the checkpoints are inserted a priori, offline analysis of program execution and control flow graphs can be applied. The main two advantages of static IC are: 1) information about program execution flow can be exploited to yield smaller snapshots [7,14,18,22], and 2) snapshots are saved regardless of the environment. The former also leads to eliminating the need for energy buffering, as explained in subsection 2. buffering for performance reasons).…”