﻿# GPU power bursts and sparse sampling

Sparse GPU-power snapshots cannot reconstruct every short workload burst. Polling frequency and a sensor's internal window are different properties.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/gpu-power-sampling-aliasing/
Language: en

Sparse GPU-power snapshots cannot reconstruct every short workload burst. Polling frequency and a sensor's internal window are different properties. Preserve timestamps, reading semantics, and coverage of the test interval. A smooth chart may reflect averaging or missed activity rather than absent peaks. Establish these limits before comparing inference modes or claiming maximum power from observations that happened to fall between active phases.

## Establish reading semantics

The [NVML API](https://docs.nvidia.com/deploy/nvml-api/latest/api/group__nvmlDeviceQueries.html) documents power queries and device-support conditions. Check whether the selected API and architecture expose instantaneous or averaged information. Do not call the polling interval the sensor's integration window. Rapid repeated reads can share an internal averaging period, so additional CSV rows do not necessarily provide independent temporal information. Preserve driver version and exact field before deciding which workload features the available observation method can resolve. Sampling more often cannot automatically remove a sensor's internal limitations.

## Identify the clock domain

Choose clocks deliberately for local durations. The [Linux clock_gettime manual](https://man7.org/linux/man-pages/man2/clock_gettime.2.html) explains realtime and monotonic differences. Record clock source and whether a timestamp marks query initiation or returned data. A query taking appreciable time is not a perfect point observation. Do not align processes or hosts without checking clock relationships. Retaining query duration also reveals whether the collector maintained its intended period or produced an irregular sequence. Nominal polling configuration should not be mistaken for demonstrated interval coverage.

## Illustrate a missed burst

Imagine a short active phase between two sparse samples. This is a timing example, not a GPU measurement. If both reads occur during idle periods, their maximum cannot describe the entire phase's peak. Draw workload boundaries and actual sample points, adding the sensor averaging window where known. The diagram exposes missing evidence without inventing the unseen burst's amplitude. High model activity does not permit exact reconstruction of an unobserved power value. Preserve uncertainty rather than filling the gap with an attractive estimated peak.

## Separate energy from peaks

Integrated energy over a matched interval and a short maximum transient answer different questions. An adequately covered average can be useful without establishing the power-delivery peak. If a cumulative energy counter is available, verify its scope and lifecycle separately. Do not combine it with sparse instantaneous readings into an apparently more precise estimate without describing the interpolation model. State treatment of boundaries, missing values, and unequal reading intervals so that another operator can reproduce the calculation from raw observations.

## Report temporal resolution

Keep nominal polling period, actual intervals, sensor semantics, workload markers, and missing samples. Label the maximum as the largest observed reading rather than a proven physical limit. Use a more suitable recording method when the question requires short-event visibility. Increasing polling indefinitely cannot promise to overcome the sensor's internal window. The conclusion should state what the telemetry resolves and what remains unknown. A smooth dashboard cannot establish sufficient PSU, UPS, or circuit headroom for short phases absent from the observations, nor prove that the workload produced no bursts.

## Related reading

[Energy per LLM request: measuring without false precision](/journal/measuring-energy-per-inference/); [GPU monitoring without excess charts: five observation levels](/journal/gpu-monitoring-scorecard/).
