Why run a burn-in after short tests pass?
Why C is the answer
To expose faults that appear only under sustained load
Thermal and intermittent problems take time to appear.
In detail
- Thermal and intermittent faults take time to appear.
- Time reveals intermittent faults.
Use case
An illustrative scenario, not a real incident.
A node passes short tests, then fails after six hours of burn-in.
See it in different ways
flowchart TD A["Single-node stress"] --> B["Single-node NCCL"] B --> C["Single-node HPL"] C --> D["Multi-node NCCL"] D --> E["Multi-node HPL and burn-in"]
stateDiagram-v2 [*] --> SingleNodeStress SingleNodeStress --> SingleNodeNccl SingleNodeNccl --> SingleNodeHpl SingleNodeHpl --> MultiNodeNccl MultiNodeNccl --> MultiNodeHpl MultiNodeHpl --> BurnIn BurnIn --> [*]
flowchart LR S0["Short tests"] --> S1["Burn-in"] --> S2["Accept"]
Key point: Burn-in exposes intermittent faults.
Why the other options are wrong
- A. To replace the cabling map with a new version
- That is unrelated.
- B. To shorten the cluster's acceptance schedule
- It adds time, on purpose.
- D. To update the BMC firmware on each server
- It is not a firmware step.