💻 computer science

Request Is Not Readback: Auditing a Runtime Controller’s Self-Reported Telemetry on a Jetson Nano

This paper presents a claim-admission audit framework that exposes critical self-reporting telemetry discrepancies in an evolutionary runtime controller on a Jetson Nano—specifically regarding CPU frequency, latency composition, and thermal GPU preferences—and validates the efficacy of targeted corrections by demonstrating that while policy readbacks can be fixed, inherent architectural limitations and clock drifts may still result in persistent reporting inaccuracies.

Original authors: Antonio Souto Rodriguez, José Reginaldo Hughes Carvalho

Published 2026-11-10

📖 6 min read🧠 Deep dive

CC BY 4.0

Original authors: Antonio Souto Rodriguez, José Reginaldo Hughes Carvalho

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 constantly making split-second decisions to keep themselves running efficiently. Imagine a device that must balance its speed, its heat, and its power usage while it is working. To do this, it relies on a built-in manager, a piece of software that acts like a traffic controller. This manager looks at the current situation, predicts what will happen if it changes the speed of the processor or turns on a graphics chip, and then issues a command. But for this system to work, the manager must also be able to look back and see if its commands actually worked. It needs to trust the signals it receives from the hardware, signals that tell it what the current temperature is, how fast the processor is actually spinning, and whether a graphics chip was truly allowed to run. If these signals are wrong, the manager is making decisions based on a lie, and the evidence used to judge its performance is equally flawed. This is the core problem of trusting a machine's own report card.

A team of researchers at the Federal University of Amazonas set out to test this trust on a specific, widely used computer chip called the Jetson Nano. They did not just assume the chip was telling the truth; they built a rigorous audit to check every claim the chip made about itself. They treated the chip's self-reported data not as facts, but as statements that needed to be verified against independent observations. The researchers ran the chip through a series of demanding tasks involving image processing, asking it to manage its own speed and heat while they watched closely. They wanted to see if the number the chip said it was aiming for matched the number it actually achieved, and if the time it took to finish a task was measured correctly.

The investigation began by checking the chip's speed. The manager would request a specific maximum speed, a limit it wanted the processor to stay under. The researchers then checked what the processor reported back as its current speed. In the initial tests, a strange pattern emerged. No matter what speed limit the manager requested, the processor always reported that it was running at exactly 1479 megahertz. It was as if the manager was shouting "slow down" or "speed up," and the processor was ignoring the command and just saying "I am at 1479." The researchers dug deeper and found the cause: the software was trying to write these speed limits to a part of the system that required special permission, which it did not have. Because the software did not check if the command actually went through, it kept thinking it had succeeded. Once the researchers fixed the permission issue, the chip finally started reporting its speed correctly, matching the limits it was asked to follow. However, they also found that in a small number of cases, the chip still reported a speed slightly higher than the limit, not because it was running too fast, but because the system was translating the request into a value that didn't exist in the chip's official list of speeds, causing it to round up to the next available option.

Next, the team looked at how the chip measured time. The manager claimed to know the total time it took for a task to go from the moment a camera captured an image to the moment the result was displayed. This is a "composed" time, meaning it is the sum of several smaller steps. The researchers found that the numbers reported by the chip were mathematically impossible; the total time was sometimes shorter than the time it took just to process the image. The problem was that the different steps were being timed by two different internal clocks that were drifting apart, ticking at slightly different rates. It was like trying to add up the duration of a movie by using a watch that started at noon and a stopwatch that started at 12:01. Once the researchers corrected the timing so that all steps used the same clock, the math worked. However, they discovered that the measurement they were looking at was not actually the time from the camera to the screen. Because the system had to fall back to a different way of recording time when the first method failed, the final number represented the time from when the task was picked up by the processor to when it finished, missing the initial wait time entirely. The researchers concluded that this specific measurement could not be used to judge the true speed of the system from start to finish.

Finally, the team examined the chip's relationship with its graphics processor. The manager would often ask to use the graphics chip to help with calculations, but a separate safety supervisor would sometimes say no if the device was getting too hot. In the early tests, the manager's reports were misleading because the thermal supervisor denied the GPU preference in 94–99% of the cases where the manager requested it. The manager was counting its wishes as if they were actions, failing to reflect that the supervisor had actually blocked the request in nearly all of those cases. In the final, corrected tests, the researchers saw the truth: under strict heat limits, the supervisor denied the graphics chip's use in over 80 percent of the requests. The manager's report was accurate only when it clearly separated what it asked for from what was actually allowed. The researchers found that the supervisor was working exactly as designed, blocking the chip only when the temperature crossed a specific threshold, but the manager's initial reports had hidden this reality.

The study concludes that relying on a system's own self-reporting without independent verification is dangerous. The researchers found that the chip's telemetry, the data it sends about itself, contained three major errors: it failed to report the actual speed limits it was given, it used mismatched clocks to measure time, and it confused its requests with its actual permissions. By auditing these signals, they were able to locate the exact causes of the errors and fix them. The final result was a system that reported its actions truthfully, allowing for a clear and accurate understanding of how it performed. The researchers recommend that any evaluation of such a system must include this kind of audit, checking the request, the permission, and the result as separate, verified facts rather than taking the system's word for it.

Technical Summary: "Request Is Not Readback: Auditing a Runtime Controller's Self-Reported Telemetry on a Jetson Nano"

Problem Statement
Embedded runtime controllers on heterogeneous Systems-on-Chip (SoCs) rely on self-reported telemetry to make decisions (e.g., selecting CPU frequency caps, GPU enablement) and to evaluate their own performance. The paper identifies a critical vulnerability: the assumption that reported signals (such as a "requested cap," "enabled state," or "end-to-end latency") accurately reflect physical reality or the controller's actual intent. Treating these fields as the physical quantities they are named after propagates errors into both decision-making logic and the evidence used to judge the controller's efficacy. The authors argue that without independent verification, a controller may be optimizing for or reporting on signals that are decoupled from the actual hardware state.

Methodology
The authors propose a "claim-admission audit" framework applied to an evolutionary runtime controller deployed on a Jetson Nano (L4T 32.7.5). The methodology involves:

Channel Specification: Defining each telemetry channel by its requested signal, observed signal, a consistency predicate with explicit tolerance, and an exclusion rule.
Audit Checks: Four specific checks were applied to the controller's logs:
- C1 (Request vs. Readback): Verifying that the written CPU frequency cap equals the value read back from the kernel (scaling_max_freq) and that the reported current frequency (scaling_cur_freq) does not exceed the written cap.
- C2 (Timing Composition): Checking if composed end-to-end latency ( $L_{comp}$ ) satisfies the definition $L_{comp} \ge L_{proc} + L_{disp}$ and ensuring the residual term does not exhibit unbounded drift (slope within $\pm 2 \mu s/s$ ).
- C3 (Request vs. Enabled State): Counting instances where a GPU preference was requested but denied by the thermal supervisor, ensuring preference shares are not conflated with utilization.
- C4 (Plausibility & Attribution): Ensuring measurements entering scoring have validity flags and that derived quantities (like power) are not attributed to specific outputs if the temporal correspondence cannot be established.
Experimental Design: The study utilized two sets of missions:
- Diagnostic Set: Three missions recorded before corrections to identify failures.
- Final Set: Three missions (one per thermal profile: inactive, moderate, aggressive) recorded after implementing write/readback and clock-basis corrections on a single binary (80,834 control periods total).

Key Findings and Results
The audit refuted the ordinary interpretation of three self-reported channels in the diagnostic phase:

C1 Failure (Frequency): In the diagnostic missions, the reported CPU frequency remained fixed at 1479 MHz regardless of the requested cap. The root cause was identified as unprivileged, unchecked writes to root-owned sysfs nodes, which the scheduler ignored.
- Correction: The scheduler was updated to refuse startup without write access and to log readbacks.
- Result: In the final missions, the written cap equaled the readback in 100% of periods. However, a 3.8% mismatch remained where the reported current frequency exceeded the written cap; this was traced to off-table frequency values (generated by scheduler transforms) being rounded up by the driver to the next valid OPP table entry.
C2 Failure (Latency): The composed latency channel violated its definition due to capture and processing timestamps being generated on different clocks (CLOCK_MONOTONIC vs. CLOCK_MONOTONIC_RAW), drifting at ~30 $\mu s/s$ $μ s / s$ .
- Correction: The capture stamp was aligned to the controller's clock.
- Result: While composition failures were eliminated, the audit revealed that 99.9% of records were stamped at dequeue rather than capture. Consequently, the channel measures "dequeue-to-completion" latency, not "sensor-to-output" latency, rendering the latter unmeasured and excluded from downstream claims.
C3 Failure (GPU Preference): Under restrictive thermal profiles, the thermal supervisor denied GPU requests in 94.2% and 98.7% of cases where the search requested them.
- Result: The audit confirmed that the supervisor acted exactly according to its predicate (temperature thresholds). The study concludes that "preference" and "enabled state" must be reported separately; reporting preference as utilization would falsely imply execution that did not occur.

Key Contributions

Claim-Admission Audit Framework: The paper contributes a formal audit structure that specifies channels via consistency predicates and exclusion rules. It demonstrates that passing these checks removes contradictions but does not inherently prove correctness; rather, it defines the boundaries of what claims are admissible.
Empirical Evidence of Telemetry Decoupling: The study provides concrete evidence that standard telemetry fields (frequency caps, latency, enablement) can be physically or logically decoupled from their intended meanings due to OS permissions, clock drift, and supervisory logic.
Exclusion Rules (E1–E4): The authors derive specific rules for evaluating controllers:
- E1: Performance models keyed on requests are invalid without verified readbacks.
- E2: Composed latency is only a valid metric if stamps share a single clock basis and are named by their measured boundaries.
- E3: Preference, enabled state, and utilization must be reported separately.
- E4: Scoring must use validity-flagged values, excluding stale held values where temporal correspondence is lost.

Significance and Claims
The paper modestly claims that the audit itself is the primary contribution, not the specific controller or the Jetson Nano platform. The authors state that while readback, timing consistency, and enabled-state checks are familiar in isolation, this work is the first to state them as a unified "admission contract" and demonstrate what such a contract refutes on a deployed SoC controller.

The significance lies in the demonstration that without this audit, evaluations of runtime controllers are built on potentially flawed evidence. The authors recommend that any evaluation built on a controller's own telemetry must begin with this audit and that controllers should log request, enabled state, readback, and measured outcome as separate fields on a single clock per period. The work does not propose new control algorithms but rather a rigorous validation methodology to ensure the data used to judge them is trustworthy.

Technical Summary: "Request Is Not Readback: Auditing a Runtime Controller's Self-Reported Telemetry on a Jetson Nano"

More like this