Sustainable Edge Vision via Empirically Calibrated DVFS: Eliminating Thermal Throttling on Passively Cooled Hardware

Aayush Marasini; Zhaoxian Zhou

Source-linked AI summary

Sustainable Edge Vision via Empirically Calibrated DVFS: Eliminating Thermal Throttling on Passively Cooled Hardware

Aayush Marasini, Zhaoxian Zhou

arXiv:2609.04705v1Sep 4, 2026cs.ARcs.CVcs.LG

TL;DR

Sustained inference on passively cooled edge hardware can trigger thermal throttling, motivating a lightweight controller that regulates performance without fan power. The paper introduces empirically calibrated, state-aware DVFS scheduling and evaluates it on a passively cooled Raspberry Pi 5 running YOLOv8n. The scheduler eliminates observed throttling, improves throughput and energy per frame over reactive control, and remains bounded by platform and ambient-temperature limitations.

Problem
Sustained YOLOv8n inference on a fanless Raspberry Pi 5 reaches thermal throttling, while passive cooling is attractive because fans consume power and can fail mechanically.
Method
An empirically calibrated, state-aware DVFS scheduler derives thresholds from sensor-noise and thermal-response measurements and uses temperature, derivative, confirmation, and dwell guards.
Results
The scheduler eliminated observed throttling and achieved 6.8% higher throughput with 1.9% lower energy per frame than the reactive baseline.
Takeaways & Limitations
Within the evaluated platform and mapped envelope, calibrated passive scheduling can outperform active cooling on energy per frame while trading away peak raw throughput.
Takeaways & Limitations
The study covers one Pi 5 platform, one YOLOv8n workload, and exploratory boundary probes; passive control fails at ambient temperatures ≥27 °C because of nonlinear leakage.

Abstract

from arXiv · show

Passive cooling eliminates the energy overhead and mechanical failure modes of fans, making it attractive for edge deployment, yet sustained Deep Neural Network (DNN) inference on passively cooled edge Systems-on-Chip (SoCs) is bottlenecked by thermal throttling. To address this, we propose an empirically calibrated, state-aware Dynamic Voltage and Frequency Scaling (DVFS) scheduler. Unlike heuristic-driven controllers, our methodology utilizes time-domain guards and absolute temperature bounds, with derivative triggers acting as safeguards against sharp thermal spikes. Evaluated on a passively cooled Raspberry Pi 5 running YOLOv8n, our scheduler eliminates all observed thermal throttling events during sustained 30-minute workloads. It outperforms a temperature-only reactive baseline by achieving a 6.8% higher frame rate (Cohen's d = 8.73) while consuming 1.9% less energy per frame. Furthermore, our optimized passive scheduling surpasses an actively cooled reference system in energy efficiency (Joules/frame), though active cooling remains superior for raw throughput. Through isolated ablations, we show that the dwell guard is necessary for run-to-run reproducibility. Finally, exploratory boundary probes indicate that the passive operating envelope closes at ambient temperatures ($\ge 27^\circ$C) where nonlinear leakage defeats DVFS-based control. These results indicate that, within the mapped envelope, correct scheduling can make mechanical cooling unnecessary for sustained edge inference on this platform.

I. INTRODUCTION

The paper addresses thermal infeasibility in sustained passive edge inference by proposing calibrated regulation that avoids heuristic tuning and accounts for deployment-specific software effects.

I. INTRODUCTION: Passive cooling removes fan power, dust, and mechanical-failure costs but leaves sustained inference thermally constrained.The paper frames passive cooling as attractive for reliable, low-cost edge deployment while highlighting its thermal trade-off.
I. INTRODUCTION: 1823 throttling events occurred during 30 minutes of full-speed YOLOv8n inference on a fanless Raspberry Pi 5.This motivates lightweight regulation for passively cooled boards.
I. INTRODUCTION: The proposed scheduler derives DVFS thresholds from measured sensor noise and thermal response rather than manual tuning.State transitions use absolute temperature bounds and dwell constraints, while derivative logic safeguards against thermal spikes.
I. INTRODUCTION: The study compares calibrated passive scheduling with a dwell-guard ablation and a temperature-threshold-only reactive baseline.These comparisons are designed to isolate the value of the time-domain guard stack and the dwell guard.
I. INTRODUCTION: INT8 deployment performance depends on the runtime and hardware combination, so precision gains are not uniformly transferable across edge platforms.The paper reports that software-stack maturity and hardware extensions constrain practical low-bit inference benefits.

A. The Thermal Problem

Sustained full-speed inference on the passively cooled Pi 5 reaches the hardware-throttling boundary, motivating lower-frequency states calibrated to thermal behavior.

A. The Thermal Problem: 84.8 °C and 1823 throttle events characterize 30-minute full-speed S0 inference on the passively cooled Pi 5.The plateau approaches the Pi 5’s 85 °C hardware throttle limit.
A. The Thermal Problem: The paper uses 82 °C as a conservative thermal-margin reference below the 85 °C hardware throttle limit.Figure 1 plots all seven configurations against this reference during sustained inference.
A. The Thermal Problem: DVFS provides three states: S0 at 2400 MHz, S1 at 1800 MHz, and S2 at 1500 MHz.A 25% S0-to-S1 frequency reduction costs approximately 15% FPS while reducing board power by approximately 26%.
A. The Thermal Problem: S1 and S2 avoided throttling during 30-minute runs, and their measured plateaus set the scheduler’s escalation and recovery thresholds.S1 and S2 therefore supply the empirical thermal operating points used by the policy.

IV. METHODOLOGY

The evaluation uses a fixed Raspberry Pi 5 setup, a trained YOLOv8n model, and synchronized telemetry and workload logging under controlled cooldown conditions.

IV. METHODOLOGY: All experiments use a Raspberry Pi 5 Model B with passive heatsink runs and a separate official Active Cooler reference.The platform includes a BCM2712 quad-core Cortex-A76, 8 GB LPDDR4X memory, Raspberry Pi OS Lite, and inline power measurement.
IV. METHODOLOGY: Each run begins only after the SoC returns to its idle-temperature band, with cooldown between runs.This controls the thermal starting condition across experiments.
IV. METHODOLOGY: YOLOv8n is trained on the USA subset of RDD2022 and deployed through an OpenVINO FP32 intermediate representation.The dataset split is 70/10/20, and the deployed Raspberry Pi mAP50 is 0.538.
IV. METHODOLOGY: Telemetry samples temperature, frequency, utilization, and memory at 2 Hz, while voltage and throttle bits are decimated to 0.4 Hz.A single sampling process feeds separate logging and scheduler consumers so logging does not block inference.
IV. METHODOLOGY: The telemetry-overhead evaluation is organized as Table I.The supplied passage identifies the table but does not report its numerical contents.

D. Energy Measurement

The methodology measures energy from filtered inline board power and combines it with logged throughput, while scheduler parameters are calibrated from sensor noise and thermal response.

D. Energy Measurement: Energy is computed from inline ChargerLAB POWER-Z measurements after retaining samples with instantaneous board power P(t) = VBUS × IBUS > 4.0 W.The threshold separates approximately 2.5 W idle operation from sustained inference above approximately 5.3 W.
D. Energy Measurement: Throughput is calculated as FPS = Nframes(t ≥ 10 s)/(tlast − tfirst), and energy per frame as J/frame = P̄/FPS.Predicted scheduler power matched observations within 1.5% for proactive and 3.2% for reactive operation.
D. Energy Measurement: Sensor calibration measured temperature noise of 0.5835 °C and post-EMA derivative noise of 0.0759 °C/s.These measurements set a hysteresis floor of at least 1.75 °C and a proactive derivative threshold of 0.5 °C/s.
D. Energy Measurement: The scheduler selects among three DVFS states at the 2 Hz telemetry rate and evaluates recovery, proactive escalation, reactive escalation, then hold.Transitions require confirmed samples and elapsed dwell, with absolute temperature and derivative conditions determining escalation.
D. Energy Measurement: Scheduler decision parameters are documented in Table II and derived from calibration-phase profiling plateaus.The table notes that these plateaus differ slightly from final 30-minute validation plateaus.

G. Statistical Methodology

The study uses repeated 30-minute runs with paired bootstrap inference and effect-size reporting to address the small number of replications.

Three replications were performed for each main experimental condition.Each replication comprised a 30-minute run followed by cooldown.
95% percentile-bootstrap confidence intervals used 10,000 resamples with seed 42.
Paired Cohen’s d was calculated by matching runs using replication index.The analysis reports effect sizes rather than p-values because the sample is small and paired effects are large.

H. Reproducibility

Reproducibility is supported by frozen experimental artifacts, deterministic settings, and detailed per-run metadata, while static states expose the throughput–thermal trade-off.

Reproducibility: All model weights, dataset partitions, and benchmark video were locked with SHA256 hashes, using random seed 42 and deterministic training settings.Hardware, software, and ambient-temperature metadata were recorded for each run.
Static Baselines: S0 delivered 12.31 FPS but reached 84.8 °C and throttled 1823 times.
Static Baselines: S2 reduced temperature to 73.4 °C at 10.76 FPS, while S1 reached 80.3 °C with only 1.7 °C below the 82 °C reference.

B. Proactive vs Reactive

The proactive scheduler improves throughput and energy efficiency over the reactive baseline without observed throttling, while the dwell guard chiefly stabilizes run-to-run behavior.

Proactive vs Reactive: Proactive improved throughput by +6.8% over Reactive (Cohen’s d = 8.73) while using 1.9% less energy per frame, with zero throttle events.Uncontrolled S0 recorded 1823 events.
Proactive vs Reactive: Proactive held S1 for 54.2% of the run, whereas Reactive spent 0% there because it remained between S0 and S2.
Proactive vs Reactive: All nominal escalations followed the absolute-temperature rule; the derivative trigger did not fire at the tested ambient.
Dwell-Guard Ablation: Removing the dwell guard changed mean throughput by only −0.9% but increased FPS standard deviation from 0.070 to 0.426.The ablation therefore affected consistency more than average throughput.
Pareto Efficiency: Proactive occupied the efficient frontier among passive dynamic policies, while the active-cooling reference was fastest but had the highest J/frame among non-throttling configurations.

E. Sustainability Metrics

Proactive scheduling achieved the best energy efficiency among dynamic policies and used less energy per frame than active cooling, while retaining lower throughput. Its safeguards also explain the throughput advantage over the reactive baseline.

Energy efficiency: 81.4% of active-reference throughput was delivered by passive Proactive scheduling while using less energy per frame.The scheduler also maintained an 8.3 °C safety margin with ≤1.0 °C overshoot above its escalation target.
Energy efficiency: Proactive achieved the best energy per correct detection among dynamic policies.
Mechanism: The throughput advantage over Reactive derives from dwell and N confirm safeguards combined with identical absolute thresholds.These safeguards prevent the rapid S1 →S2 cascade observed under Reactive; the derivative trigger did not fire during nominal 30-minute runs.

B. INT8 software-stack finding

On this Raspberry Pi software stack, INT8 deployment performed worse than FP32 because quantized execution exposed conversion overhead and limited INT8 use. The finding is specific to the tested runtime and hardware combination.

Observed performance: −43% FPS and +69.4% J/frame were observed for INT8 on the tested stack.The platform supports NEON DotProd but lacks the newer I8MM extension.
Graph analysis: The INT8 model exposed 64 INT8-typed ports against 842 FP32 ports, indicating extensive mixed-precision execution.The graph contained 2.22× more FP32 ports than the unquantized FP32 model.
Mechanism: NNCF inserted Convert operations at every quantized-layer boundary to bridge INT8 convolutions and FP32 activations.This conversion pattern largely bypassed the DotProd path.
Scope: The INT8 result is specific to this runtime and model combination, so alternative runtimes may produce different outcomes.The paper concludes that precision optimization depends on software-stack maturity and runtime-specific tuning.

C. Ambient-locked oracle

Static S1 appeared efficient at the tested ambient but had little thermal margin, whereas Proactive maintained a larger margin and lower plateau. Reactive remained locked in S2 because its recovery threshold was never reached.

Thermal margin: 8.3 °C was Proactive’s thermal margin versus 1.7 °C for Static S1.Proactive plateaued at 73.7 °C, while S1 plateaued at 80.3 °C against the 82 °C reference.
Ambient dependence: Static S1’s zero-throttle property vanished at 31 °C, making its apparent optimality ambient-bound.The passage attributes the narrow margin to the specific hardware and cooling conditions.
Efficiency trade-off: 23.3% lower power outweighed an 18.6% throughput reduction for passive scheduling on J/frame.Active cooling retained maximum raw performance, but its fan increased power draw.
Reactive behavior: Reactive stayed locked in S2 because its temperature remained above Trec(S2 →S1) = 71 °C throughout every run.With identical thresholds, only the guarded policy retained access to S1.

VII. LIMITATIONS

The study’s limitations center on restricted evaluation scope, exploratory boundary testing, and a thermal-model breakdown at elevated ambient temperatures. These constraints limit generalization beyond the mapped Raspberry Pi 5 operating envelope.

Evaluation scope: Evaluation uses a single Pi 5 platform, one workload, and one YOLOv8n model family, limiting generalizability to other passive SoCs and workloads.The authors identify broader DVFS-capable platforms and workloads as future work.
Boundary characterization: Boundary probes were conducted only once and require rigorous multi-run validation before the passive operating boundary can be considered established.The probes were exploratory rather than a fully replicated characterization.
Thermal operating envelope: At ambient temperatures ≥27 °C, nonlinear leakage causes the linear thermal model to break down and drives even the lowest DVFS state above the throttle threshold.A representative deviation is a predicted S2 plateau of 81 °C versus an observed 88–89 °C at 31 °C.
Scope of conclusion: The conclusion that mechanical cooling can be unnecessary applies strictly within the mapped ambient operating envelope.The paper frames this as a platform-specific result rather than a general result for passive edge SoCs.