Five-Hour RK3576 Thermal and Stability Stress Test

What we wanted to prove

Peak benchmark numbers are useful, but an edge computer also needs to hold useful performance without overheating, silently throttling, corrupting results, or resetting after hours of sustained work.

We therefore ran a five-hour combined stress test on a Seeed Studio reComputer RK3576 Dev Kit. CPU, memory, GPU, and NPU workloads ran at the same time while a separate collector recorded temperatures, clocks, fan speed, load, memory pressure, process health, and kernel events every two seconds. The test used the system's default dynamic voltage and frequency scaling (DVFS): no overclock, no forced clocks, and no governor changes.

The result was a pass. All four checksum-verified workloads completed normally, the hottest internal sensor reached 56.4°C, throughput showed no sustained loss, and the whole system drew about 8.03 W at its DC input over the captured meter interval.

Hardware and software

• Device under test: Seeed Studio reComputer RK3576 Dev Kit.
• SoC: Rockchip RK3576 with four Cortex-A72 cores up to 2.208 GHz and four Cortex-A53 cores up to 2.016 GHz.
• Memory and storage: 8 GB physical RAM, 4 GB zram swap configured, and a nominal 32 GB SD card with an ext4 root filesystem.
• GPU: Mali-G52 MC3 with a 900 MHz maximum devfreq operating point.
• NPU: RKNN using a dual-core mask and a 950 MHz maximum clock.
• Cooling: Product heatsink and active fan.
• Software: Armbian-unofficial 26.05.0-trunk bookworm with Linux 6.1.115-vendor-seeed-rk3576 on aarch64.
• Instruments: Inline DC input power meter and a Fluke Ti100 thermal imager.

The four concurrent workloads

• CPU: stress-ng --cpu 8 --cpu-method all --verify, with stress-ng verification enabled.
• Memory: Two 1 GiB VM workers using --vm-keep --verify.
• GPU: A persistent OpenCL context running copy and FMA loops, with checksum validation after every pass.
• NPU: Continuous YOLOv8s RKNN inference using a 640×640 input and dual-core mask, with output validation every 100 inferences.

The persistent OpenCL context is important. Repeatedly destroying and recreating a GPU context would primarily test driver context switching and could introduce artificial timeout behavior. Here, one context remained alive for the full run and validation happened periodically inside that session.

Test architecture

The workload runner was installed as a `systemd` service, so disconnecting SSH could not stop the experiment. The sequence was:

1. Capture hardware, kernel, clock table, governor, thermal-zone, and script-hash metadata.

2. Start the two-second telemetry collector.

3. Start CPU, memory, GPU, and NPU workloads together for 18, 000 seconds.

4. Check process health, validation progress, Boot ID, non-fan cooling-device state, and kernel alerts throughout the run.

5. Compute ten 30-minute throughput windows.

6. Stop the workloads normally and retain telemetry for a ten-minute cooldown.

7. Collect logs and generate JSON/CSV summaries.

Results at a glance

Thermal behavior

The raw collector continued for ten minutes after the workloads stopped. For the summary below, cooldown samples were excluded; only rows where all four workloads were alive were used.

The curves rose quickly after load began and then stayed in a narrow band for the remainder of the five hours. The 56.38°C peak was 28.6°C below our conservative 85°C test-abort threshold. That threshold was an engineering safety rule for this experiment, not a claim about the official silicon limit.

The active fan averaged 6, 835 RPM during the combined-load samples. When the four workloads stopped, the hottest CPU sensor fell from roughly 54–55°C to about 38°C by the end of the ten-minute cooldown.

The thermogram used in the cover was captured during a separate stabilized full-load session, with the fan side exposed. Its crosshair reads 38.3°C and the frame's automatic scale reports a 46.1°C scene maximum. These are surface temperatures and must not be compared directly with on-die thermal-zone readings. The thermal camera clock was not synchronized, so its printed date was not used in the analysis. We intentionally use only this one thermal frame because the available idle image was taken from a different angle and enclosure state; presenting it as a strict before/after comparison would be misleading.

Did the system throttle?

Under the concurrent workload, both CPU clusters reported their configured maximum current frequencies in every two-second sample. GPU devfreq was at its 900 MHz operating point in 99.99% of load samples, the NPU's underlying clock was at 950 MHz in 99.96%, and DDR was at 2736 MHz in 99.70%.

The GPU exposes two useful clock views: devfreq reports a 900 MHz operating point, while the lower-level `clk_gpu` debug clock reports approximately 786.432 MHz at that point. Both were recorded so that the article does not present the devfreq number as a directly measured core clock.

The orchestration loop also checked non-fan Linux cooling devices. None entered a non-zero mitigation state, and no thermal-throttling abort was triggered. Together with stable throughput and low temperatures, this is strong evidence that the product's active cooling solution maintained the required operating points in this test.

Throughput stability

We divided the run into ten 30-minute windows. The first window was treated as warm-up and the 30–60 minute window as the baseline.

GPU throughput was exceptionally flat: stable windows ranged from 3, 311 to 3, 320 passes, versus 3, 314 in the baseline. NPU windows ranged from 22, 100 to 23, 300 inferences. The largest baseline-relative NPU reduction was 4%, and it was not sustained beyond the 5% criterion. Crucially, the changes did not coincide with temperature escalation or clock loss.

Whole-system input power

The DC meter did not have a computer interface, so each reading was photographed and then transcribed. Average power is derived from changes in the cumulative Wh counter divided by the meter's actual elapsed time. This is more reliable than averaging a handful of instantaneous screen readings.

The figure shows the two important trends: energy-derived interval power remained close to 8 W, and accumulated energy increased almost linearly throughout the captured span. The dashed gray series is the instantaneous screen reading; the blue series is the more representative interval average calculated from Wh deltas. All 12 transcribed readings are included in Appendix A for independent checking.

Between the first and last valid photographs, the counter increased by 39.594 Wh over 17, 756 seconds, giving an average input power of 8.028 W. Energy-derived interval averages stayed between 7.952 and 8.292 W, even though the instantaneous display ranged from 7.27 to 9.06 W.

This is whole-system DC input power. It includes SoC, memory, SD storage, Ethernet, fan, onboard conversion losses, and any attached hardware. It is not SoC-only or NPU-only power. A separate idle snapshot was taken while an HDMI display was connected, but it was not a timed Wh-delta baseline collected with the same complete evidence chain. We therefore do not compare that instantaneous idle snapshot with the energy-derived load average or claim an idle-to-load power delta or TOPS/W figure.

What this says about the product

For this sample and configuration, the reComputer RK3576's active thermal design sustained a simultaneous CPU, memory, GPU, and NPU workload for five hours while:

• keeping every internal sensor at or below 56.4°C;
• holding the configured top operating points for at least 99.7% of combined-load samples;
• avoiding sustained GPU or NPU throughput degradation;
• completing all compute-integrity checks successfully;
• remaining responsive, without a reboot or fatal compute/kernel event; and
• averaging about 8.03 W at the whole-system DC input over the photographed meter span.

That combination matters more than a single peak benchmark. It shows that the cooling assembly can move sustained heat away from the RK3576 while the software stack continues doing verified work.

Limitations

• One device was tested; sample-to-sample variation was not measured.
• The test used active cooling and does not represent fanless operation.
• Ambient temperature was not independently logged with a calibrated probe.
• The thermal frame was a separate full-load capture, not a synchronized frame from the five-hour run.
• Power readings were manually transcribed from photographs; the last valid image was taken 171 seconds before nominal T+300.
• The separate idle power snapshot included an attached HDMI display and was excluded from the quantitative load comparison.
• The operating system booted from an SD card, so power may differ with eMMC, NVMe, or other peripherals.
• Five hours demonstrates sustained behavior under this workload, not product lifetime or every deployment condition.

Conclusion

The reComputer RK3576 completed a demanding, checksum-verified five-hour combined workload with a 56.4°C internal peak, stable clocks and throughput, no fatal compute event, and roughly 8 W whole-system DC input. Within the clearly stated test conditions, the data supports two practical conclusions: the active cooling solution has substantial thermal headroom, and the platform can sustain heterogeneous edge-AI workloads without measurable performance fade.