Runtime telemetry from evolutionary and static resource policies on a Jetson Nano
This paper presents a comprehensive dataset of 108 hours of runtime telemetry from an NVIDIA Jetson Nano, comparing a surrogate-assisted evolutionary controller against static resource policies across eighteen six-hour missions to provide validated, traceable records of system performance, power consumption, and control decisions.
Original paper licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer
In the world of modern electronics, tiny computers are increasingly asked to do heavy lifting. These devices, often found in robots, drones, or smart cameras, must process complex tasks like recognizing objects in a video stream while running on limited battery power. The challenge is that these tasks generate heat, and if a device gets too hot, it must slow down or shut off parts of itself to cool down, which hurts performance. To solve this, engineers use software managers that constantly decide which part of the computer should do the work: the central processor, the graphics processor, or a mix of both. These managers try to balance speed, energy use, and temperature, but they operate in a chaotic environment where the workload changes every second. The big question is whether these smart managers can actually make the right choices in real time, and if the numbers they report about their own decisions are trustworthy.
A team of researchers at the Federal University of Amazonas set out to answer these questions by recording a massive, detailed log of a small computer running for days. They used an NVIDIA Jetson Nano, a compact board with two gigabytes of memory, and made it run a continuous series of image-processing tasks for one hundred and eight hours. The experiment was designed like a long-haul flight with scheduled stops. The computer cycled through four different types of image analysis—equalizing brightness, finding edges, blurring images, and filtering noise—each lasting thirty minutes. This cycle repeated twelve times in a single six-hour mission, and the team ran eighteen of these missions in total. Some missions were run with a fixed, unchanging rule for how to use the computer's parts, while others were run with a smart, evolving controller that tried to learn and adapt its strategy every eight hundred milliseconds.
The smart controller was the star of the show. It acted like a pilot constantly adjusting the plane's engines based on the weather. Every few seconds, it looked at the current temperature and the type of image task at hand, then proposed a new plan. This plan included which processor to use, how fast to run it, and how much power to allow. To make these decisions, it used a simplified model, or a "surrogate," that predicted how a choice would affect speed and heat. Crucially, the researchers did not just record what the controller thought it did; they recorded what it actually commanded, what the computer's software reported back, and what the physical sensors actually measured. This triple-check system was necessary because previous checks had revealed that the controller often claimed to have set a speed limit that the computer never actually applied.
The results of this marathon run provided a rare, high-definition look at how these systems behave under pressure. The researchers found that the smart controller successfully maintained its internal state and continued learning even as the tasks changed from one type of image processing to another. It kept a running count of its decisions and observations without resetting, showing a form of continuity that is essential for long-term adaptation. However, the data also highlighted the gap between intention and reality. While the controller successfully requested specific speed limits, the computer's internal reporting sometimes showed values slightly different from what was asked, a quirk of how the hardware rounds numbers to fit its available settings. More importantly, the data confirmed that the controller's thermal supervisor worked exactly as designed: whenever the temperature rose above a specific warning line, the system automatically disabled the graphics processor to cool down, regardless of what the smart controller wanted.
This dataset is not just a record of a single experiment; it is a public resource for anyone studying how to manage power and heat in small computers. The researchers released over eight million individual records of camera frames, along with logs of every decision the controller made and every temperature reading taken. They included the raw data from an external power meter, which measured the electricity flowing into the board, separate from the computer's own internal estimates. This separation allows other scientists to verify exactly how much energy was used versus how much the computer thought it used. The data also revealed that under the most aggressive heat settings, the device spent nearly all of its time above the safe temperature threshold for the graphics processor, forcing the system to rely almost entirely on the central processor for long stretches.
The study also clarified what can and cannot be learned from such logs. The researchers were careful to note that while they recorded the time it took to process each frame, they did not verify that the different processors produced identical results for every task. In some cases, the central processor and the graphics processor were running slightly different versions of the same mathematical function. Therefore, the data shows how fast different implementations run, but it does not prove that they are mathematically equivalent. Furthermore, the researchers emphasized that the data represents a specific path taken by the controller; it shows what happened when the system made a series of choices, but it does not prove that those choices were the only possible ones or that they were the absolute best ones.
By separating the request, the software confirmation, and the physical measurement, this work provides a clear map of where trust breaks down in automated systems. It shows that while smart controllers can adapt to changing workloads and manage heat effectively, they are still bound by the quirks of the hardware they control. The researchers made their entire dataset, including the scripts used to analyze it, available to the public. This transparency allows other scientists to test their own theories against the same real-world conditions, ensuring that future improvements in how we manage tiny computers are built on a foundation of verified facts rather than assumptions. The work stands as a detailed, unvarnished record of a machine trying to think for itself while staying cool in a hot world.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.