{"id":"IL-0415","org":"NCSA","date":"2025-12-10","docs":["https://doi.org/10.5281/zenodo.15287639"],"title":{"en":"GSP, fallen-off-the-bus and NVLink errors left A100 GPUs on NCSA's Delta inoperable and failed the jobs running on them","ko":"Delta 의 A100 GPU 에서 GSP 오류, GPU Fallen Off the Bus 오류, NVLink 오류가 나 GPU 가 오류 상태에 빠지고 그 위의 작업이 실패했다"},"domain":["ai-infra"],"impact":{"scope":"A100 GPUs on Delta went into an error state and stayed unavailable until a GPU reset or node drain and reboot; jobs on them failed, 3,359 jobs failed on GPU errors overall and 5,700 node hours were lost to GPU downtime","users":"HPC and ML users from universities nationwide who run jobs on Delta","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Except for MMU and NVLink errors, the GPU errors studied are not handled by applications and fail the job nearly every time, so application-level recovery is largely ineffective and GPU hardware resilience has to improve. Error detection and recovery of the GSP, the PMU and their communication interfaces need duplication and error detection and correction so that they stop being single points of failure. In a simulation of a month-long job on all 608 H100 GPUs with a recovery time of 2.2 hours, the job would need 5% more GPUs to keep 99.9% job-level availability, and cutting recovery time from 2.2 hours to 5 minutes would bring that down to 2%.","ko":"논문은 A100 에서 단일 장애점이 된 GSP 와 PMU, 그리고 PMU SPI 같은 통신 인터페이스의 오류 감지와 복구를 이중화와 오류 감지·정정 장치로 보강해야 한다고 결론지었다. AWS 는 성능보다 안정성을 위해 GSP 를 끄라고 권한다. 애플리케이션 수준의 복구는 대체로 효과가 없어서 GPU 메모리와 하드웨어 수준에서 복원력을 높여야 한다. 체크포인트는 관리와 저장과 복원을 합쳐 최대 40% 의 오버헤드가 든다. 시뮬레이션에서는 복구 시간이 2.2시간일 때 H100 608개를 한 달 쓰는 학습 작업이 작업 수준 가용성 99.9% 를 지키려면 GPU 를 5%, 곧 31개 더 둬야 했다. 복구 시간을 2.2시간에서 5분으로 줄이면 필요한 여유분이 2% 로 줄어 2.5배 적어지므로, 크고 오래 도는 작업에서는 복구 시간을 줄이는 일이 중요하다."},"related":[],"sources":[{"url":"https://arxiv.org/abs/2503.11901","kind":"paper","archived":"https://web.archive.org/web/20261102020706/https://arxiv.org/abs/2503.11901"}],"summary":{"en":"Delta has 106 4-way and 8-way A100 40 GB nodes with 448 A100 GPUs and a second cluster of 152 4-way GH200 nodes with 608 H100 96 GB GPUs, sharing a Lustre storage cluster and scheduled with Slurm for HPC and ML users from universities nationwide. The paper analyses 2.5 years of operational data, 895 days from October 2022 to March 2025 for A100 and 146 days from October 2024 to March 2025 for H100, 11.7 million GPU hours in total. GPU errors were extracted from system logs with regular expressions for NVIDIA XID messages, identical errors from the same GPU within 5 seconds were coalesced into one, a job was counted as GPU-failed when a GPU error occurred within 20 seconds before it failed, and DCGM metrics at one-minute granularity gave GPU utilization. The A100 GPUs logged 14,821 critical errors in total, one every 1.4 hours system-wide and every 154 hours per node; 3,359 jobs failed on GPU errors out of 1,420,278 jobs submitted to the GPU nodes.\n\nThe paper groups GSP, fallen-off-the-bus, PMU SPI and MMU errors as GPU hardware errors and treats NVLink as the interconnect. On A100 the GSP was the most vulnerable hardware component because it lacks robust error detection and recovery, and the paper calls it a single point of failure, because the errors start spontaneously and have high downstream impact such as GPU hangs. Fallen-off-the-bus errors are integration errors, often from a loose connection between GPU and motherboard or a contact failure from thermal cycles. NVLink errors come from faulty GPU hardware, connectors or connectors installed improperly during system integration; NVLink retries packets after a CRC error, but the errors were still frequent, and when an NVLink error did not fail a job the paper suggests the link may not have been in use. Apart from MMU and NVLink errors, the GPU errors studied cannot be handled by the application, so the failed jobs had to start again from the beginning or from the nearest checkpoint. The paper also notes that AWS recommends disabling GSP for stability.\n\nTo recover a GPU node, operators drained it, waiting for the other jobs on it to finish without accepting new ones, rebooted it and let it pass a health check before scheduling jobs on it again; a node that failed the reset stayed marked failed until the GPU was tested and, if needed, replaced. The expected time to service a failed node was 0.88 hours for A100 nodes and 2.2 hours for H100 nodes, 5,700 node hours were lost to GPU downtime, and per-node availability was about 99.4% for A100 and 99.3% for H100, 9 to 10 minutes of downtime a day. Four A100 GPUs were replaced because they failed to boot. On the H100 GPUs only 3 GSP errors and no fallen-off-the-bus or NVLink errors were observed, which the paper attributes to the GH200 packaging of CPU and GPU in one module and to NVIDIA driver upgrades that Delta's engineers also saw improve GSP and NVLink stability.","ko":"NCSA 가 운영하는 HPC 시스템 Delta 는 A100 과 H100 GPU 1,056개로 이루어진다. A100 448개는 4-way 와 8-way 노드 106대에, H100 608개는 4-way GH200 노드 152대에 있다. 일리노이대를 중심으로 한 연구진은 A100 은 2022년 10월부터 2025년 3월까지 895일, H100 은 2024년 10월부터 2025년 3월까지 146일, 합쳐 1,170만 GPU 시간의 운영 데이터를 분석했다. 연구진은 시스템 로그에서 정규식으로 XID 오류와 복구 기록을 뽑았고, 같은 GPU 에서 5초 안에 되풀이된 같은 오류는 하나로 묶었다. 그다음 Slurm 스케줄러 데이터베이스의 작업 종료 기록과 대조했다. 작업이 실패하기 전 20초 안에 GPU 오류가 있으면 GPU 때문에 실패한 작업으로 셌다.\n\nA100 에서 가장 취약한 하드웨어는 GSP 였다. GSP 는 드라이버 작업을 CPU 에서 덜어 가는 GPU 보드 위의 보조 프로세서다. GSP 는 오류를 감지하고 복구하는 장치가 약해서, GSP 오류의 99% 이상이 GPU 를 오류 상태에 빠뜨리고 그 GPU 를 쓰던 작업을 실패시켰다. 복구에는 GPU 재설정이나 노드 재부팅이 필요했고, 논문은 GSP 가 A100 에서 단일 장애점이라고 판단했다. 한 사례에서는 A100 의 GSP 오류가 GPU 제어 기능을 멈춰 작업이 실패했고, 노드를 드레인하고 재부팅하는 데 오전 09:08 부터 다음 날 오전 08:21 까지 23 노드 시간이 걸렸다. GPU Fallen Off the Bus 오류는 GPU 와 메인보드의 연결이 헐겁거나 온도 변화가 되풀이되며 접촉이 나빠질 때 흔히 나는 하드웨어 연결 오류다. 이 오류는 거의 모두 GPU 를 오류 상태로 만들었다. NVLink 오류는 1,922건이었고, 두 사건에서는 GPU 재설정이 필요해 노드가 2시간 넘게 멈췄다.\n\nH100 에서는 GSP 오류가 3건뿐이었고 GPU Fallen Off the Bus, NVLink, PMU SPI 오류는 나오지 않았다. 논문은 그 이유를 CPU 와 GPU 를 한 모듈로 묶은 GH200 의 구조와 NVIDIA 드라이버 업그레이드에서 찾았다. 전체적으로 MMU 와 NVLink 를 뺀 GPU 오류는 작업 쪽에서 처리할 수 없어 거의 100% 작업 실패로 이어졌다. 895일 동안 GPU 때문에 실패한 작업은 3,359개였다. 실패한 노드를 되살리는 데 A100 은 평균 0.88시간, H100 은 2.2시간이 걸렸고, GPU 다운타임으로 잃은 노드 시간은 모두 5,700시간이었다. 노드당 가용성은 A100 이 99.4%, H100 이 99.3% 였다."},"trigger":{"en":"Delta's site reliability engineers observed that GSP errors were highly correlated with heavy ML benchmarks; the paper names GSP firmware bugs or demanding workloads as their causes.","ko":"Delta 의 SRE 는 GSP 오류가 무거운 ML 벤치마크 실행과 밀접하게 관련된다고 봤다. 논문은 GSP 오류의 원인으로 GSP 펌웨어 버그나 부하가 큰 워크로드를 들었다."},"severity":"unknown","symptoms":["gpu-unavailable","training-job-failed"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"published","detection":{"en":"The errors were found as NVIDIA XID messages in the node system logs; Delta's site reliability engineers monitor GSP errors closely, and job failures showed in the Slurm scheduler database and as drops in DCGM GPU utilization.","ko":"NVIDIA 드라이버가 GPU 오류를 시스템 로그에 XID 오류로 남겼고, Delta 는 모든 계산 노드의 로그를 실시간으로 중앙 저장소에 보냈다. Delta 의 SRE 는 제때 복구하려고 GSP 오류를 주의 깊게 지켜봤다. 작업이 실패하면 DCGM 이 1분 단위로 모으는 GPU 사용률이 곧바로 떨어졌다."},"components":["gpu-hardware","gpu-driver"],"root_cause":"hardware-failure","remediation":[{"text":{"en":"Drained the node with a GSP error and rebooted it fully to bring the GPU back","ko":"A100 에서 GSP 오류가 났을 때는 노드를 드레인하고 노드 전체를 재부팅해 복구했다. 그 노드에 대기하던 사용자 작업도 모두 빠졌고, 복구에 23 노드 시간이 걸렸다."}},{"text":{"en":"Reset GPUs to recover from critical NVLink errors","ko":"치명적인 NVLink 오류 두 건은 GPU 를 재설정해 복구했고, 그동안 노드가 2시간 넘게 멈췄다."}},{"text":{"en":"Returned a rebooted node to scheduling only after it passed a health check","ko":"노드를 재설정할 때는 운영자가 노드를 드레인해 새 작업을 받지 않고 돌던 작업이 끝나기를 기다린 뒤 재부팅했다. 재부팅 뒤 헬스 체크를 통과하면 그 노드에 다시 작업을 배치했다."}},{"text":{"en":"Kept nodes that failed the reset marked failed until the GPU was tested and replaced if required","ko":"재설정에 실패한 노드는 GPU 를 더 시험하고 필요하면 물리적으로 교체할 때까지 실패로 표시해 두었다."}},{"text":{"en":"Replaced four A100 GPUs that failed to boot","ko":"A100 측정 기간 895일 동안 부팅하지 못한 A100 GPU 네 개를 교체했다."}}],"action_items":[],"contributing":["single-point-of-failure"],"recurrence_of":null,"symptoms_text":{"en":"On Delta, the GPU system operated by NCSA at the University of Illinois Urbana-Champaign, A100 GPUs hit GPU System Processor (GSP) errors, GPU Fallen Off the Bus errors and NVLink errors that put the GPU into an error state, failed the user job scheduled on it and kept the GPU out of service until it was reset or its node was drained and rebooted. Over 895 days of A100 operation the system logs recorded 3,857 GSP errors (XID 119/120), 1,922 NVLink errors (XID 74) and 10 GPU Fallen Off the Bus errors (XID 79).\n\nThe errors appeared as NVIDIA XID messages in the node system logs. A GSP error is logged when the GSP, an onboard co-processor that takes driver work off the CPU, does not answer remote procedure calls from the GPU driver; in the job failure table it appears as \"GSP RPC timeout\". A GPU Fallen Off the Bus error is logged when the driver can no longer reach the GPU over the system bus. Across the A100 fleet a GSP error came on average every 6 hours (590 hours per node), an NVLink error every 11 hours (1,185 hours per node) and a fallen-off-the-bus error every 2,148 hours (227,668 hours per node).\n\nThe errors arrived without warning and then repeated. 99% of GSP errors appeared without any preceding error, and with a probability of 0.99 a GSP error was followed by the same error again or left the GPU inoperable; the remaining 15 cases led to PMU SPI communication errors and job failures. Over 99% of fallen-off-the-bus errors were followed by similar errors in close succession and ended with the GPU in an error state. NVLink errors also had no preceding errors: 42% (801) of them spread to two or more GPUs of the node, and 17% of those involved three or more GPUs; on the same GPU an NVLink error was followed by another NVLink error with a probability of 0.38 or left the GPU in an error state with a probability of 0.61.\n\nThe impact on jobs differed by error type. All 31 jobs that encountered a GSP RPC timeout failed (100.00%). Delta's site reliability engineers considered NVLink errors largely benign, but 43 of the 80 jobs that encountered one failed (53.75%), and in two incidents a critical NVLink error needed a GPU reset and interrupted the node for over 2 hours. In one example, a GSP error stalled the control functions of an A100 GPU, the job on it failed, its DCGM GPU utilization dropped quickly, and the node drain and full reboot took 23 node hours, from 09:08 AM to 08:21 AM the next day.","ko":"Delta 의 A100 GPU 노드에서 XID 119/120 GSP 오류, XID 79 GPU Fallen Off the Bus 오류, XID 74 NVLink 오류가 시스템 로그에 찍혔다. 그 뒤 GPU 가 오류 상태에 빠졌고, 그 GPU 에서 돌던 사용자 작업이 실패했다. GPU 는 재설정하거나 노드를 재부팅하기 전까지 쓸 수 없었다.\n\nGSP 오류는 GPU 드라이버가 보낸 원격 프로시저 호출에 GSP 가 응답하지 않을 때 난다. A100 에서 3,857건이 기록되었다. GSP 오류가 한 번 나면 0.99 의 확률로 같은 오류가 되풀이되거나 GPU 가 동작할 수 없는 상태가 되었다. GSP 오류의 99% 는 전조가 되는 다른 오류 없이 단독으로 나타났다. GSP RPC timeout 을 만난 작업 31개는 모두 실패했다. H100 에서는 측정 기간 동안 GSP 오류가 3건뿐이었다.\n\nGPU Fallen Off the Bus 오류는 GPU 드라이버가 시스템 버스로 GPU 에 닿지 못할 때 기록된다. A100 에서 10건이 있었고, 99% 이상은 같은 오류가 잇달아 이어진 끝에 GPU 가 오류 상태에 빠졌다.\n\nNVLink 오류는 A100 에서 1,922건으로 잦았다. 오류 사이의 평균 시간인 MTBE 는 시스템 전체로 11시간, 노드당 1,185시간이었다. 그 가운데 42% 인 801건은 연결된 다른 GPU 로 번져 GPU 두 개 이상에 영향을 줬고, 번진 오류의 17% 는 같은 노드의 GPU 세 개 이상에 걸쳤다. 같은 GPU 에서는 0.38 의 확률로 곧 또 다른 NVLink 오류가 났고, 0.61 의 확률로 GPU 가 오류 상태에 남았다.\n\nDelta 의 SRE 는 NVLink 오류가 대부분 해롭지 않고 늘 작업 실패로 이어지지는 않는다고 봤다. 그러나 작업 영향 분석에서는 NVLink 오류를 만난 작업 80개 가운데 43개, 53.75% 가 실패했다. GSP 오류와 NVLink 오류는 전조가 되는 하드웨어 오류가 없어서 메모리 오류보다 예측하기 어려웠다."},"updated_at":"2026-11-14T12:34:06.596816Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0415","org_slug":"ncsa"}