# GPU ECC: volatile and aggregate error counters Read GPU ECC counters with their type, location and reset history. A practical evidence table separates new increments, historical totals and unavailable fields. Author: Retrivium team Updated: 2026-11-01 Canonical URL: https://retrivium.ai/journal/gpu-ecc-volatile-aggregate/ Language: en ## Start with the counter's identity An ECC number is incomplete without its scope. A useful observation names the GPU, error type, memory location, reporting interval and whether the field is supported. Two dashboards can show different totals while both are reading the device correctly, because they selected different counter families. Record the GPU UUID rather than relying only on its current enumeration index. The [NVML query reference](https://docs.nvidia.com/deploy/nvml-api/latest/api/group__nvmlDeviceQueries.html) distinguishes volatile and aggregate ECC counters. Availability depends on the device and operating configuration. An unsupported query must remain unknown in the record; substituting zero would turn a missing observation into a claim that no errors occurred. ## Compare like with like Keep corrected errors separate from uncorrected errors. Preserve the reported memory location instead of combining every location under a single unexplained total. A label such as GPU errors is too broad to support a maintenance decision. The collection configuration belongs beside the value so that a later change of exporter does not silently change its meaning. The [nvidia-smi documentation](https://docs.nvidia.com/deploy/nvidia-smi/index.html) describes the reported ECC fields and their limitations. Consult the installed tool's supported queries before building a collector. A field shown on a data-center GPU is not automatically available on every workstation card or partitioned configuration. ## Treat a reset as a boundary Suppose an illustrative record shows a volatile total of 12 before a maintenance event and 0 afterward, while an aggregate field still reads 18. This does not mean that twelve faults were repaired or that eighteen new faults appeared. The values describe different histories. Their comparison first requires the reset or driver-lifecycle context. Store raw readings before calculating differences. Start a new measurement epoch when the counter moves backward or the device identity changes. Do not report a negative error rate or add the absolute value of that negative difference to an incident total. Preserve a gap if the collector did not observe the transition. ## Build a small evidence table Use one row per observation: UTC timestamp, host boot identity, GPU UUID, driver version, error class, location, counter family, value and query status. Add a maintenance reference when known. Keep the raw vendor output so that an interpretation can be revised without rerunning a disruptive test. For a repeated-workload investigation, compare changes within a single epoch and note the workload interval. A rise during that interval supports a temporal association. It does not, by itself, identify the application as the physical cause or establish a warranty outcome. ## Decide what needs investigation A stable historical total, a new increment and an unavailable field are three different findings. Route each through the relevant hardware support guidance and correlate it with application failures and device events. A clean ECC sample is useful evidence within its observed scope; it is not a certificate of overall GPU health. ## Related reading - [Used GPUs: which checks are needed before a pilot?](/journal/used-gpu-health-check/) - [Build a GPU Inventory CSV with nvidia-smi](/journal/gpu-inventory-csv-from-nvidia-smi/)