Acceptance Testing a New Game Node in 30 Minutes: Seven Checks That Prove It

Check 6: Thermal and clock stability under sustained load

Short benchmarks hide throttling. Run a sustained all-core load for several minutes and sample clock frequency and package temperature throughout. A node that boosts to its advertised clock for thirty seconds and then settles ten percent lower is a node with inadequate cooling or an aggressive power cap.

Log the steady-state clock and treat that, not the burst clock, as the number you plan capacity around. If the steady state is materially below spec, that is a support ticket before launch.

Check 7: Reboot behaviour and service recovery

Finally, reboot the machine and time how long until the game service is accepting connections again, with world data intact. This validates your unit files, dependency ordering, and mount readiness in one shot. Most operators only test this accidentally, during an outage, at the worst possible moment.

Repeat it twice. A node that recovers correctly once and fails on the second boot has a race in its startup ordering, and you want to find it now.

Record it, or you did not do it

The deliverable of acceptance testing is a short document: node identity, date, the seven measured results, and a pass or fail against each pre-agreed gate. Keep it with the node’s provisioning notes. When a node later misbehaves, that document is the difference between a support conversation grounded in evidence and a month of speculation.

A new game node arriving in your rack is not a game node until you have measured it. Hardware arrives pre-imaged, providers hand over credentials, and the first instinct is to load the game and invite people in. That order is how communities discover a broken CPU steal profile, a misaligned NVMe, or a saturated uplink at 40 concurrent players instead of at 8 p.m. the night before launch.

Acceptance testing is the practice of proving, with numbers you recorded yourself, that a node performs within an agreed envelope before it takes production traffic. The full routine below is designed to run in roughly half an hour on a freshly provisioned box. For context on how much headroom a given game actually needs, compare dedicated game server hardware on our spec and pricing comparison table before you start — knowing the target envelope is what makes the measurements meaningful.

Before the clock starts

Have three things ready: a second machine on a similar path to act as the client, a game binary or simulation harness you can drive with a known player count, and somewhere to store results. A plain text log with timestamps is enough. Fixed-price acceptance requires a fixed start state, so do not begin tuning or changing configs during the thirty minutes — the point is a baseline of the box as delivered.

Decide the pass criteria in advance. Typical gates look like: steal time below a small percentage under load, disk write latency below a chosen percentile during save bursts, and NIC retransmits near zero at the target player count. Writing these down first stops you from rationalising a bad result later.

Check 1: Identify what you were actually sold

Providers advertise cores, generation, and clock, and delivered silicon does not always match the invoice. Record the CPU model, socket count, thread count, and cache sizes, then compare against the provider’s claims. Do the same for memory modules and disks: confirm device count, interface type, and usable capacity.

This check takes two minutes and eliminates a whole class of arguments later. If the node is a socket too shallow or a generation behind, you want that in writing on day one, not in month four when a support ticket gets answered with “as per spec”.

Check 2: Steal time and scheduler fairness

On bare metal, steal time should be effectively zero. Sample the CPU counters over a minute at idle and again under your expected load, and look at steal alongside system time. Persistent non-zero steal on a dedicated box usually means the host is virtualising more than it disclosed or that a management layer is competing for cycles.

Then test scheduling fairness. Pin a fixed workload to a subset of cores and check that throughput scales roughly linearly with the number of cores you give it. A flat curve where ten cores perform like four is a red flag for shared physical resources behind the scenes.

Check 3: Memory bandwidth and NUMA topology

Dual-socket boxes split memory into per-socket nodes, and a process that wanders across sockets pays a latency penalty on every remote access. Record the node layout, then run a simple bandwidth and latency pattern against local versus remote memory and compare. On a healthy two-socket node the local result should be clearly better than remote, and the ratio tells you how much pinning discipline your game server will need.

Do not skip this on game workloads. Tick loops are latency sensitive and a few microseconds of extra memory latency compounds across thousands of entities per tick.

Check 4: Disk behaviour with a realistic save pattern

Synthetic sequential throughput is the least useful disk number for a game server. What matters is what happens when the server writes a world save — a burst of mixed writes, then a flush, then normal operation. Replay that pattern: write a file roughly the size of your largest world, force it to disk, and record completion time and tail latency.

Then run the pattern repeatedly and watch for degradation. NVMe drives with poor overprovisioning fall off a cliff once their write buffer fills, and a node that looks fast on the first save can take four times as long by the twentieth. Record the twentieth, not the first. Our dedicated server plan comparison lists the storage configuration each tier ships with, which gives you the expected baseline to test against.

Check 5: Network under load, not at idle

Ping the node from your client machine across several minutes to establish baseline latency and jitter, then drive the game simulation at your target player count and repeat. Interest is in the delta: how much latency and jitter grow once packets are actually flowing.

Watch retransmits and interface errors on the host side too. A clean link at idle that starts dropping frames at 60% utilisation is telling you the uplink is the ceiling, not the CPU. Note the throughput at which the first degradation appears — that is your practical headroom number, and it belongs in the node’s documentation.

Check 6: Thermal and clock stability under sustained load

Short benchmarks hide throttling. Run a sustained all-core load for several minutes and sample clock frequency and package temperature throughout. A node that boosts to its advertised clock for thirty seconds and then settles ten percent lower is a node with inadequate cooling or an aggressive power cap.

Log the steady-state clock and treat that, not the burst clock, as the number you plan capacity around. If the steady state is materially below spec, that is a support ticket before launch.

Check 7: Reboot behaviour and service recovery

Finally, reboot the machine and time how long until the game service is accepting connections again, with world data intact. This validates your unit files, dependency ordering, and mount readiness in one shot. Most operators only test this accidentally, during an outage, at the worst possible moment.

Repeat it twice. A node that recovers correctly once and fails on the second boot has a race in its startup ordering, and you want to find it now.

Record it, or you did not do it

The deliverable of acceptance testing is a short document: node identity, date, the seven measured results, and a pass or fail against each pre-agreed gate. Keep it with the node’s provisioning notes. When a node later misbehaves, that document is the difference between a support conversation grounded in evidence and a month of speculation.