Why run a sustained compute benchmark on a new cluster before handover?
Why B is the answer
To find faults that only appear under full load and heat
Marginal hardware, cooling and fabric issues often only show up under sustained load.
In detail
- Some faults appear only under full load and heat.
- Short tests miss marginal hardware.
Use case
An illustrative scenario, not a real incident.
A rack passes short tests, then a sustained benchmark overheats one node after an hour.
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 --> [*]
stateDiagram-v2 state "Short tests pass" as s0 state "Sustained load" as s1 state "Fault appears" as s2 [*] --> s0 s0 --> s1 s1 --> s2: heat builds s2 --> [*]
Key point: Sustained load exposes hidden faults.
Why the other options are wrong
- A. To confirm that the operating system image installed correctly
- An OS check needs no benchmark.
- C. To populate DNS records for each of the new nodes
- DNS has nothing to do with benchmarks.
- D. To create a baseline of user accounts and job quotas
- A baseline alone is not the main reason.