Energy-aware Scheduling and Input Buffer Overflow Prevention for Energy-harvesting Systems

A batteryless sensor that runs on scavenged energy captures data at a steady rate but processes it at a rate that swings with the weather and how busy the scene is, so when processing falls behind, new inputs pile into a tiny buffer and, once it fills, the device throws away fresh data and misses the very events it was deployed to catch; this paper (CMU — Harsh Desai, Xinye Wang, Brandon Lucia) builds Quetzal, which schedules the job with the shortest end-to-end time including recharging, uses queueing theory to predict an imminent buffer overflow, and reacts by degrading just enough (say, a cheaper neural network) to keep up, cutting missed events by up to 4.2 times.

The argument in one glance

Problem

A sensor captures at a steady rate but processes at a rate that keeps changing

A batteryless sensor scavenges energy from sunlight or radio waves into a small supercapacitor and does compute on-device — running, say, a neural network to decide whether an image is worth transmitting — so it only spends precious energy sending the interesting data. It captures inputs at a fixed rate, one image every so often, but the rate at which it can process those inputs swings with the environment: when input power is low it must pause to recharge, and when the scene is busy more inputs need the expensive processing. When capture outpaces processing, the unprocessed inputs pile up in a small on-device input buffer of only hundreds of kilobytes. Once that buffer fills, the device has nowhere to put a new input and drops it. And the newest inputs are exactly the ones most likely to be the interesting event the device was deployed to catch.
What people did

Pick a fixed configuration, or degrade on a fixed trigger

The simplest responses are static rules. You could cap the capture rate so processing can always keep up, or you could always run a cheaper, degraded version of the processing to stay fast, or degrade only when a fixed trigger fires — when the buffer is already full, or when input power drops below a set threshold. Each is a single rule chosen ahead of deployment to keep the device from falling behind.
Why it fell short

No static rule survives the dynamic processing rate

The processing rate is not a fixed quantity to be provisioned against; it varies continuously with input power and event activity, so any static choice is wrong much of the time. Always degrading throws away quality and discards interesting inputs even when there was headroom to process them fully. Degrading only when the buffer is full reacts too late — the overflow is already happening. Degrading on a fixed power threshold degrades unnecessarily when the buffer was actually fine, and still misses events when it was not. Prior schedulers guarantee periodic tasks run but never tackle the buffer overflow itself, so events keep getting lost.
This paper's idea

Schedule by true end-to-end time, predict overflow, and degrade just enough

Quetzal is a hardware-software system that avoids input buffer overflows dynamically. Its scheduler extends Shortest Job First to include energy-recharging time, so it picks the job with the genuinely lowest end-to-end latency under the current input power and event activity — which, surprisingly, can be running an ML inference rather than sending a radio packet when power is low. Its runtime then uses queueing theory (Little's Law) to predict, before running, whether that shortest job will still let the buffer overflow during its execution. If an overflow is imminent, Quetzal degrades the job's degradable task — swapping in a cheaper, faster model, for instance — but only as much as needed, choosing the highest-quality option that still avoids the overflow. A tiny custom power-measuring circuit lets an ultra-low-power microcontroller do this without expensive division. Quetzal cuts missed events by up to 4.2 times.

Why this problem is worth solving

The overflow is not a rare corner case; it is the direct enemy of the device’s purpose.

An energy-harvesting sensor captures data — images, say — at a fixed cadence set by the application, but the energy to process each input arrives erratically from the environment, so processing runs at a variable rate. When capture outpaces processing, the backlog is held in a small on-device input buffer, typically only hundreds of kilobytes because memory costs energy and area the device does not have. Once that buffer is full, a newly captured input has nowhere to go and is discarded: an input buffer overflow. The cruel part is what gets dropped. The device exists to catch interesting events, and a burst of interesting activity is precisely what both fills the buffer (more inputs survive the cheap first-pass filter and need full processing) and produces the newest inputs that overflow discards. So an overflow does not lose random data; it preferentially loses the events the device was deployed to observe, at the moment they are happening. Preventing overflows is therefore not a performance nicety but the core reliability requirement of the whole system, which is why it deserves a dedicated mechanism rather than a best-effort heuristic.

What makes it genuinely hard is that the thing you would provision against never holds still.

On a conventional device you might avoid a queue overflow by sizing the buffer or the service rate for the worst case, but an energy-harvesting device denies you a stable worst case to design for, for two coupled reasons. First, input power varies: on-device compute draws from the supercapacitor, and if it discharges below a threshold the device must stop and wait to recharge before continuing, so energy-recharging time sits directly on the critical path of end-to-end processing. When power is low, that recharge wait dominates, and a task’s real duration is mostly idle waiting for energy. Second, event activity varies: when interesting events are frequent, more captured inputs pass the cheap filter and demand the expensive processing, slowing the effective rate; when events are rare, most inputs are discarded cheaply and processing races ahead. These two factors interact — low power and high activity together are the danger zone — and neither is known at design time. The consequence is that the end-to-end time of the very same job changes from moment to moment, so there is no fixed capture rate, no fixed degradation level, and no fixed threshold that is right across conditions. Only a runtime that measures the current environment and reacts can keep the buffer from overflowing, which is the design point Quetzal targets.

What people did before, and where it broke

Cap the capture rate. Slow down how fast the device captures inputs so processing can always keep up. Where it broke. A capture rate low enough for the worst case wastes the device’s ability to catch events most of the time, and still cannot adapt when conditions shift, so it either misses events or throttles needlessly.
Always degrade the processing. Run a cheaper, faster version of the task (a smaller neural network) all the time to stay ahead. Where it broke. It sacrifices quality unconditionally, discarding interesting inputs through misclassification even when there was ample energy and time to process them fully.
Degrade when the buffer is full (CatNap-style). Switch to the degraded task only once the input buffer has filled up. Where it broke. A fixed full-buffer trigger reacts too late: by the time the buffer is full the overflow is already under way, so events are already being lost.
Degrade when input power is low (Zygarde/Protean-style). Trigger degradation whenever input power falls below a set threshold. Where it broke. A fixed power threshold ignores the actual buffer state, so it degrades unnecessarily when the buffer had room and still overflows when power was fine but event activity was high.
The gap. No system chose which job to run by its true end-to-end time under current conditions and then predicted, before running it, whether it would overflow the buffer, degrading only the minimum needed — which is what dynamically varying processing rate demands.

How Quetzal works

Turning a fixed rule into a measure-predict-degrade loop against buffer overflow

↓ →
new
↓ →
new
↓ →
new
↓ →
new
↓ →
new

The idea

Measure the shortest job by what actually costs time here: energy, not just compute. The first insight is that on an energy-harvesting device, the classic notion of a job’s length is misleading, because the dominant cost is often not computation but waiting to recharge. Quetzal extends Shortest Job First so that “shortest” means shortest end-to-end latency including energy-recharging time, computed for the current input power and the current probability that each task in the job will actually run. This inverts intuition: when input power is low, sending a radio packet — energy-hungry — is slow because the device must recharge before it can transmit, so running a cheaper ML inference first can genuinely be the faster job; when power is high, compute dominates and the ordering flips. By tracking power and per-task execution probability at runtime, the scheduler ranks jobs by their real cost under the conditions that hold right now. Choosing what to run by adapting the decision to live runtime conditions, rather than a static estimate fixed at design time, is the same principle the dynamic scheduler for real-time ML workloads covered elsewhere on this site is built on, selecting among jobs based on their actual, moment-to-moment execution behavior rather than a one-time profile.

Predict the overflow with queueing theory before it happens, not after. Picking the shortest job is necessary but not sufficient, because even the shortest job can be long enough — under low power or high activity — that captures pile up past the buffer’s capacity while it runs. The second insight is to turn this into a prediction problem with a classic tool: Little’s Law, which relates how many items sit in a queue to the rate they arrive and how long they stay. Quetzal uses it to estimate, from the fixed capture rate and the job’s predicted execution time, how many new inputs will accumulate during the run, and compares that to the buffer’s free space to flag an imminent overflow before the job starts. This is fundamentally different from the fixed-trigger baselines: instead of reacting once the buffer is full (too late) or whenever power dips (often needlessly), it forecasts the specific overflow this job would cause under these conditions. Using a lightweight statistical model of the workload to anticipate a resource crunch and act ahead of it, rather than waiting for the crunch to manifest, is the same anticipatory stance the uncertainty-aware resource-management work covered elsewhere on this site takes, predicting demand under uncertainty so the system can provision before quality is lost rather than scrambling afterward.

Degrade the minimum, and only where the program said it is safe. The final insight is that degradation is a scalpel, not a switch. When an overflow is predicted, Quetzal does not blindly drop to the cheapest mode; it evaluates the available degradation options for the job’s degradable task and picks the highest-quality one that still brings the predicted input accumulation under the buffer limit. Degradation is a program-level notion the developer exposes by annotating which task is degradable and providing its options — for instance, a smaller, faster neural network that trades some accuracy for speed. So quality is spent only as a last resort and only in the amount the buffer actually demands, preserving as much fidelity as conditions allow while still avoiding the overflow. Trading a controlled amount of result quality for the ability to fit a hard resource budget, exposed as tunable options the system dials to the tightest setting that still fits, is the same accuracy-for-efficiency lever the work on enabling deep learning on microcontrollers covered elsewhere on this site relies on, shrinking a model to fit a device’s limits while giving up as little capability as possible.

Following a busy moment through Quetzal

Keeping the buffer from overflowing during a burst of activity under low power

A trace, drawn from the paper's design, of how Quetzal handles a job when both power is low and events are frequent.

Step 1 of 5

Conditions turn adverse: low power, busy scene

Clouds cut the solar input while a flurry of interesting events means more captured images survive the cheap first-pass filter and need full processing. Both effects slow the processing rate just as the buffer is filling, the danger zone where an overflow becomes likely.

Low power lengthens recharge waits and high activity raises how many inputs need the expensive task, so end-to-end job time is at its longest.

Why it works

Counting recharge time finds the truly shortest job. Ranking jobs by compute alone is wrong when energy waits dominate → but including energy-recharging time on the critical path reveals that an ML inference can beat a radio send under low power → so the scheduler picks the job that actually finishes soonest given current energy.
Prediction acts before the overflow, not after. Fixed triggers fire once the buffer is full, when the loss has begun → but Little’s Law estimates the accumulation during a job’s run in advance → so Quetzal prevents the specific imminent overflow instead of reacting to one already in progress.
Minimal degradation preserves quality that headroom allows. Always degrading or degrading on a coarse trigger throws away accuracy needlessly → but choosing the highest-quality option that still fits the buffer spends only the quality required → so fidelity is retained whenever conditions permit.
Adapting to both power and activity covers the real danger zone. Reacting to power alone misses activity-driven overflows and vice versa → but scheduling and prediction both use live power and per-task execution probability → so the combined low-power, high-activity case that fixed rules mishandle is caught.
Hardware power measurement makes the math affordable. The scheduling and prediction need many divisions, hundreds of cycles each on a tiny microcontroller → but a simple two-diode-plus-ADC circuit measures power in a form that eliminates those divisions → so the adaptive loop is cheap enough to run on the device it protects.

What it costs (trade-offs and scope)

It needs custom hardware and program annotations. Quetzal is a hardware-software solution: it requires its power-measurement circuit (two diodes, a multiplexer, an 8-bit ADC) and asks the developer to annotate tasks and jobs and to designate a degradable task with its degradation options. It is not a drop-in library for an unmodified application on stock hardware.
Quality degradation is a real cost, just a controlled one. Avoiding an overflow by running a smaller model means some inputs are processed less accurately; Quetzal minimizes how often and how much this happens, but under sustained low power and high activity it must trade fidelity to keep up, so the guarantee is fewer missed events, not zero quality loss.
The predictions rest on model assumptions. Little’s Law and the end-to-end time estimates depend on the measured power, the assumed capture rate, and per-task execution probabilities being reasonably accurate; rapidly changing conditions or workloads that violate the modeling assumptions could make a prediction wrong, causing an unavoided overflow or an unnecessary degradation.
Each job needs a degradable task to give Quetzal a lever. The reaction mechanism only works if the job contains something degradable with meaningful options; a job whose tasks cannot be cheapened offers no way to shorten it, so Quetzal can schedule it well but cannot prevent an overflow it would cause.
Evidence is a specific class of device and workload. Results come from periodic energy-harvesting sensor scenarios with ML-inference and radio tasks (for example, image classification with degradable networks like a smaller model in place of a larger one) on ultra-low-power microcontroller-class hardware; the up-to-4.2-times reduction is against particular baselines in these settings, and behavior on very different applications or energy sources is inferred rather than exhaustively shown.

The evaluation

Avoiding input buffer overflows on an energy-harvesting sensor

Property	Degrade on fixed trigger	Always degrade	Quetzal
Chooses job by end-to-end time
Predicts overflow before running
Degrades only as much as needed
Adapts to power and activity
Reported outcome

A comparison drawn from the paper. Quetzal is evaluated against baselines including always-degrade, full-buffer-triggered degradation (CatNap-style), and power-threshold degradation (Zygarde/Protean-style), on periodic energy-harvesting sensor workloads with degradable ML and radio tasks; the up-to-4.2-times figure is the paper's reported reduction in events missed due to input buffer overflows.Underlined values explain themselves when clicked.

Where this stops working

What to keep in mind

The full paper text was available (the authors’ own copy from the first author’s site), so this account of the mechanism — the input-buffer-overflow problem, the Energy-aware Shortest Job First scheduler that includes energy-recharging time, the Little’s-Law-based overflow prediction, the minimal task degradation using developer-annotated degradable tasks, and the custom power-measurement circuit (two diodes, a multiplexer, and an 8-bit ADC) that avoids expensive integer divisions — follows the paper’s own description. The headline number is the paper’s reported result: up to 4.2 times fewer events missed due to input buffer overflows versus several baselines (always-degrade, full-buffer-triggered degradation, and power-threshold degradation). That figure is for periodic energy-harvesting sensor workloads with ML-inference and radio tasks on ultra-low-power microcontroller-class hardware; results depend on the workload, energy source, and baselines used. Exact per-experiment numbers, the scheduling and prediction formulas, and the circuit details should be read from the paper itself.

Background

Why on-device compute created this problem in the first place

It is worth seeing that the overflow problem is a side effect of a good idea. Early energy-harvesting sensors were sense-and-transmit: they indiscriminately radioed every captured reading to a base station. Radio is one of the most energy-expensive things such a device does, so transmitting everything wastes scarce harvested energy on data no one cares about. The advance in recent systems was to add on-device compute — a small neural network, say — that filters the data locally and transmits only what is interesting, dramatically improving energy availability and what the device can accomplish per joule. But that filtering is itself computation that must be powered and scheduled, and it is exactly this processing whose rate now lags behind capture and fills the buffer. So the input buffer overflow is the price of moving intelligence onto the device: the smarter first-pass filter is what makes the processing rate variable and energy-dependent in the first place. That pull toward doing capable computation, like neural-network inference, directly on a tiny resource-starved device is the same ambition the microcontroller deep-learning work covered elsewhere on this site pursues, fitting real inference into hardware with almost no memory or energy to spare. Quetzal’s job is to make that on-device intelligence keep pace with the world it is watching.

If you remember only three things

1. Batteryless energy-harvesting sensors do on-device compute (like ML inference) to discard uninteresting data and save energy, capturing inputs at a fixed rate but processing them at a rate that varies with input power (recharge waits) and event activity (how many inputs need full processing); when capture outpaces processing, inputs queue in a tiny buffer (hundreds of kilobytes) and, once it fills, the device drops the newest inputs — an input buffer overflow that preferentially loses the interesting events it exists to catch. Because the processing rate is irreducibly dynamic, no static rule prevents this.
2. Quetzal avoids overflows with a measure-predict-degrade loop: an Energy-aware Shortest Job First scheduler picks the job with the lowest end-to-end latency including energy-recharging time (so under low power an ML inference can beat a radio send); a runtime applies Little's Law to predict, before running, whether that job will still overflow the buffer during its execution; and if so it degrades the job's developer-annotated degradable task (a smaller, faster model) only as much as needed, choosing the highest-quality option that fits. A tiny two-diode-plus-8-bit-ADC circuit measures power so the microcontroller avoids expensive integer divisions.
3. By running the truly shortest job and degrading minimally and only when the buffer actually requires it — adapting to both power and activity rather than a single fixed trigger — Quetzal reduces events missed due to input buffer overflows by up to 4.2 times against baselines that always degrade, degrade when the buffer is full, or degrade on a power threshold. It requires custom power-measurement hardware and program annotations, must trade some accuracy under sustained adverse conditions, and is demonstrated on periodic sensor workloads with degradable ML and radio tasks.

Check yourself

Check your understanding

1. What is an input buffer overflow on an energy-harvesting device, and why is it especially harmful?
2. Why is the "shortest job" on an energy-harvesting device not simply the one with the least computation?
3. How does Quetzal decide whether to degrade a job, and how much?
4. What are Quetzal's main results and requirements?

Sources

The paper is “Energy-aware Scheduling and Input Buffer Overflow Prevention for Energy-harvesting Systems” by Harsh Desai, Xinye Wang, and Brandon Lucia (Carnegie Mellon University), published at ASPLOS 2025 (Volume 2), DOI 10.1145/3676641.3715995. It is licensed CC BY. The system is named Quetzal.

This explainer is based on the paper’s full text, obtained from the first author’s copy (desaiharsh.github.io). The account of the mechanism — the input buffer overflow problem on periodic energy-harvesting sensors; the dynamic processing rate driven by input power (recharge on the critical path) and event activity; the notions of tasks, jobs, and degradable tasks that developers annotate; the Energy-aware Shortest Job First scheduler that includes energy-recharging time to find the lowest end-to-end latency job; the runtime’s use of Little’s Law to predict imminent overflows from the capture rate and predicted job execution time; the minimal degradation that selects the highest-quality option avoiding the overflow; and the custom hardware circuit (two diodes, a multiplexer, and a low-power 8-bit analog-to-digital converter) that measures input and execution power while eliminating expensive integer divisions on ultra-low-power microcontrollers such as the MSP430 — follows the paper’s own description. The reported result cited here is the paper’s own: up to 4.2 times fewer events missed due to input buffer overflows compared against several baselines, including always-degrade, full-buffer-triggered degradation (CatNap-style), and power-threshold degradation (Zygarde/Protean-style), on periodic energy-harvesting sensor workloads with degradable ML-inference and radio tasks. Exact per-experiment numbers, the scheduling and Little’s-Law formulas, and the circuit details should be read from the paper itself.