Acceptance Testing a New Game Node in 30 Minutes: Seven Checks That Produce a Go/No-Go

A newly provisioned node can pass every check in the control panel and still ship a 2.1 GHz engineering sample, a QLC drive with a 40 GB cache, and an uplink that collapses to 12 Mbit/s under a 200 Mbit/s commit. All three are detectable in under half an hour, but only if you test in a fixed order against fixed thresholds, before you install game software or migrate a world onto the box.

The sequence below runs on a 32-core machine, needs nothing beyond standard Linux tooling, and yields one of two answers: keep the node, or open a ticket and ask for a rebuild while the cancellation window is still open. Every threshold assumes real hardware, not a VM — if lscpu reports a hypervisor flag, stop, because all the numbers below will be wrong.

Check 1: Silicon Identity and Sustained Clocks (4 minutes)

Start with what the OS actually sees. Compare model name, base frequency, and cache sizes against the order page line by line. A ‘3.7 GHz’ part that reports a 2.1 GHz base is not a typo — it is a different SKU.

lscpu | egrep 'Model name|Thread|Core|MHz|L3' | sort -u
for i in $(seq 1 $(nproc)); do yes > /dev/null & done
sleep 120; grep MHz /proc/cpuinfo | sort -u; kill %1 2>/dev/null

Run the load for a full two minutes, not ten seconds. Turbo gives every part two minutes of burst before thermal and power limits bind. If the all-core frequency under sustained load is more than 25% below the advertised boost, the cooling or the power delivery is wrong for a dedicated node.

Check 2: Single-Thread Ceiling and Memory Bandwidth (7 minutes)

Game servers live and die on one core. Measure single-thread throughput with a pinned run rather than a multi-threaded score, and record it as a baseline so future comparisons are meaningful.

Memory matters in two ways: capacity reported by the OS, and the number of channels actually populated. A 64 GB kit running single-channel reports 64 GB and performs 40% slower on the replication pass. dmidecode -t memory shows installed modules and configured speed; the CPU spec sheet shows how many channels the platform supports.

Metric	Method	Pass threshold
All-core clock under load	2 min busy loop	within 10% of sustained spec
Single-thread index	pinned ST benchmark	beats a mid-range laptop by 4x
RAM channels	dmidecode	fully populated
ECC enabled	dmesg	EDAC reports no disabled bank

ECC is not optional for a box holding a persistent world. Silent bit flips in entity tables surface as impossible damage numbers and corrupted saves months later, long after the node was accepted.

Check 3: Storage Identity and Queue-Depth-1 Latency (6 minutes)

Identify the drive before benchmarking it. nvme list gives the model string, and that string reveals whether you received an enterprise TLC part or a consumer QLC drive dressed up as one. Then measure random 4K write latency at QD1, which is what a synchronous save actually experiences.

nvme list
fio --name=qd1 --filename=/tmp/test.bin --size=4G --rw=randwrite \
  --bs=4k --iodepth=1 --ioengine=libaio --direct=1 --runtime=60
rm -f /tmp/test.bin

A dedicated node should land in the 15–30 µs range for 4K QD1 random writes. Anything above 100 µs is a SATA-class device or a virtualized disk, either of which will produce multi-hundred-millisecond stalls on every autosave. The same NVMe endurance and cache behaviour that matters for world saves explains why cache sizes, not peak throughput figures, decide this.

Check 4: The SLC Cache Cliff (5 minutes)

Sustained-write behaviour separates honest drives from cheap ones. Write a file larger than the advertised dynamic cache — 100 GB is a safe test on a 1 TB drive — and watch latency every ten seconds. A TLC or enterprise drive holds steady. A QLC drive spikes by 10–20× once the cache is exhausted and can take minutes to recover.

This is the most commonly skipped test and the one with the clearest operational consequence. A modded server generating 30–60 GB of logs and backups per day will live in the post-cliff regime permanently.

Check 5: Uplink Honesty and Port Commitment (5 minutes)

Test throughput in both directions against a well-peered endpoint, and test it at a time of day when the network is busy. A 1 Gbit/s port that delivers 300 Mbit/s at 20:00 is a 300 Mbit/s node no matter what the invoice says. Also confirm whether the commit is dedicated or shared, because the failure mode is contention, not a hard cap.

Link	Failure symptom	Test
1 Gbit/s dedicated	none expected	iperf3 -P 8, both directions
1 Gbit/s shared	evening collapse	repeat at peak hour
Uplink with scrubber	loss under attack	sustained UDP at 80% line rate

Check 6: Packet Path Jitter and Loss (3 minutes)

Run a 60-second ping sweep at 20 packets per second to a handful of well-connected targets and look at the distribution, not the mean. Mean latency is almost always fine. What ruins a tick is p99.9 spiking to 200 ms once every 30 seconds, which the game renders as a lag spike for everyone at once.

Record packet loss separately. Loss above 0.1% on a wired path means a bad optic, a saturated switch port, or an oversubscribed uplink — reasons to reject the node before migration, not after. It also tells you whether the node sits on a clean path or behind a congested one, which is the difference between a healthy tick rate and a contract you will regret.

Check 7: Platform Integrity and Firmware (3 minutes)

Finish with the boring checks: BIOS/UEFI version, microcode revision, NIC firmware, and whether the host has out-of-band management you can actually reach. A node without IPMI or a vendor console means every future failure requires a support ticket and a wait.

Confirm the kernel sees all installed memory, that no MCE or EDAC errors are logged at boot, and that the machine is not running inside a container with CPU quotas. Then write the whole baseline down — clocks, latencies, throughput — because in six months those numbers are the only reference you will have when the world starts lagging and you need to know whether the hardware changed or the workload did. Providers who publish full hardware specifications on the order page make this audit trivial; for the rest, this sequence is how you find out.