Alpaca: intermittent execution without checkpoints

Abstract

The emergence of energy harvesting devices creates the potential for batteryless sensing and computing devices. Such devices operate only intermittently, as energy is available, presenting a number of challenges for software developers. Programmers face a complex design space requiring reasoning about energy, memory consistency, and forward progress. This paper introduces Alpaca, a low-overhead programming model for intermittent computing on energy-harvesting devices. Alpaca programs are composed of a sequence of userdefined tasks. The Alpaca runtime preserves execution progress at the granularity of a task. The key insight in Alpaca is the privatization of data shared between tasks. Updates of shared values in a task are privatized and only committed to main memory on successful execution of the task, ensuring that data remain consistent despite power failures. Alpaca provides a familiar programming interface and a highly efficient runtime model. We also present an alternate version of Alpaca, Alpaca-undo, that uses undo-logging and rollback instead of privatization and commit. We implemented a prototype of both versions of Alpaca as an extension to C with an LLVM compiler pass. We evaluated Alpaca, and directly compared to three systems from prior work. Alpaca consistently improves performance compared to the previous systems, by up to 23.8x, while also improving memory footprint in many cases, by up to 17.6x. C1:A program must preserve progress despite losing volatile state on power failures. C2: A program must have a consistent view of its state across volatile and non-volatile memory. C3: A program must respect atomicity constraints (e.g., sampling related sensors together).G1: Applications should place as few restrictions on the hardware as possible.G2: Applications should be tunable at design time to use the energy storage capacity efficiently. G3: Applications should minimize runtime overhead and memory footprint. Recent work made progress toward several of these goals, but necessarily compromised on others. This paper develops Alpaca 1 , a programming and execution model that allows software to execute intermittently. Like state-of-the-art systems, Alpaca preserves progress despite power failures (C1) and ensures memory consistency (C2). Alpaca uses a static task model that can adhere to programmer-provided atomicity constraints and energy availability (G2, C3). Memory updates made by an Alpaca task only commits atomically when the task completes. By discarding memory updates on power failure, Alpaca can restart a task with negligible cost, without checkpointing the volatile state as in prior work [Lucia and Ransford 2015;; Van Der Woude and Hicks 2016] (G3). Unlike prior work that requires the entire memory to be non-volatile [Van Der Woude and Hicks 2016], Alpaca can leverage both volatile and non-volatile memory (G1). We present two different versions of Alpaca with different design choices. Alpaca's design differences, relative to state-of-the-art systems, translate into performance gains of 4-5.2x o...

Scaling configuration of energy harvesting sensors with reinforcement learning

“…Hence, these sensors nodes need to be carefully configured to increase their quality of service and compete with existing battery-based solutions. Several works are tackling intermittent operations of battery-less energy harvesting systems [21,22,35,36].…”

Sensing, Computing, and Communications for Energy Harvesting IoTs: A Survey

“…We survey these works in this section. [105] Task-based checkpointing-versioning, × × manual idempotency analysis Ratchet [106] Task-based checkpointing, × × automatic idempotency analysis Chain [107] Idempotency task programming, × channel-based data exchange HarvOS [108] CFG-based checkpoint placement, × × × advanced ADC interrupt Clank [109] Dynamic idempotency task decomposition, × checkpointing and versioning Alpaca [110] Idempotency task programming, × privatization data exchange Mayfly [111] Idempotency task programming, remanence timekeeping A. Checkpointing Optimizations 1) Checkpoint placement and activation: refers to the scheme of inserting potential checkpoints to the program at compile-time and activate checkpointing processes at run-time. Inserting checkpoints at different locations of the program leads to distinct checkpointing overhead (including energy and memory) as the number of variables to be saved varies.…”

“…Second, the execution just follows a task flow and no checkpointing is needed between tasks, such as Chain [107] and Alpaca [110]. Instead of decomposing a long program that is written line-by-line (or instruction-by-instruction), Chain and Alpaca designed a new programming model where a program is written at the granularity of a task, i.e., groups of instructions, and these tasks are connected through a control flow graph.…”

Low Overhead Online Checkpoint for Intermittently Powered Non-volatile FPGAs

“…As the computation complexity varies from application to application, the energy needed for each application are di erent. erefore, preserving the current states are widely adopted in designs [17][18][19][19][20][21][22][23][24]. Moreover, the energy from capacitors is limited as the size of capacitors in small scale energy harvesting system can be as small as µF and under 5 [19].…”