Vetting a Game Server Host: 7 On-Node Tests That Expose Weak Hardware

A provider can pass a sales call and still deliver a node that throttles within ten minutes of a packed world load. The gap between advertised and delivered performance is measurable, and every test below runs on a trial instance in under two hours with free tools. This is the sequence used before trusting a host with a 24/7 population of 100 or more players.

Test 1: Sustained Clock Under Single-Thread Load

Run a single-threaded stress loop for 15 minutes and sample effective clock with turbostat. A node rated at 4.5 GHz that settles at 3.1 GHz has a cooling or power-delivery problem. Game simulation threads live and die on this number, and a throttle here invalidates every other spec on the sheet.

• Pass: sustained clock above 90% of rated boost.
• Marginal: 80–90%; acceptable only if the world is small.
• Fail: below 80%, or clock oscillating by more than 400 MHz.
• Run on the same core the game will use — check whether the provider pins instances to specific CCDs.

Test 2: 4K Random Write at Queue Depth 32

This mirrors concurrent world saves and log flushes across several instances. Expect 200,000+ IOPS on genuine enterprise NVMe with DRAM cache and power-loss protection. Under 80,000 points to consumer drives, a saturated backplane, or neighbours sharing the controller.

Test	Tool	Pass threshold	What failure indicates
Sustained clock	turbostat + stress-ng	> 90% of rated boost	Cooling or power cap issue
4K random write	fio, iodepth 32	> 200k IOPS, PLP present	Consumer drive or shared controller
QD1 write latency	fio, iodepth 1	p99.9 < 250 µs	No DRAM cache or no PLP
Path quality	mtr to 5 player regions	0% loss, < 5 ms jitter	Congested transit
Burst bandwidth	iperf3, 60 s	Commit rate documented	Undocumented burst bucket
OOB access	provider panel	IPMI/KVM available	Unmanaged bare metal claim is false
Reinstall time	panel action	Under 20 minutes	Manual provisioning behind a portal

Test 3: Network Path to the Player Base

Run mtr from the node to at least five player locations for 200 packets each. Watch for loss at any hop and jitter in the final three. A clean port behind a congested transit provider still produces 30 ms of jitter, which surfaces as rubber-banding no matter how good the hardware is. For a European player base, expect under 30 ms to Frankfurt and Amsterdam, 35–45 ms to London, and 55–70 ms to Stockholm.

Test 4: Burst Bandwidth Reality

Pull a large file for 60 seconds and watch the throughput curve. If it climbs to 1 Gbps and collapses to the commit rate after 30 seconds, you have measured the burst bucket. That is acceptable for game hosting if the committed rate exceeds 3 Mbps per player; it is fatal for a mod download host on patch day, where 200 players pulling a 4 GB pack will saturate a 200 Mbps commit for hours.

Test 5: DDoS Mitigation Behaviour Under a Real Flood

Ask the provider how mitigation is triggered and what the false-positive policy is. The measurement that matters is added latency when mitigation is active, not peak cleaning capacity. A well-configured inline scrubbing path adds 1–4 ms to legitimate game traffic; a routed-through-a-cleaning-centre model adds 20–40 ms, which is game-breaking for shooters.

• Acceptable: always-on inline filtering, under 5 ms added RTT.
• Acceptable with caveats: on-demand scrubbing with under 60-second trigger.
• Reject: null-routing the IP as the default response to volumetric floods.
• Ask for the trigger threshold in Gbps and pps — a 2 Gbps trigger is useless against a 400 Gbps reflection attack.

Test 6: Out-of-Band Access and Reinstall Time

If the plan is sold as bare metal, IPMI or KVM access should exist. Test it before the trial ends: enter the BIOS, check that the CPU model matches the invoice, and confirm the memory runs at the advertised speed rather than at a safe JEDEC fallback. A node whose RAM runs at 2133 MT/s instead of 3200 loses 12–18% of memory bandwidth and a measurable share of tick stability.

Reinstall speed is a proxy for how much of the provisioning is automated. Under 20 minutes means an API-driven pipeline; over an hour usually means a human with a USB stick, which also means a human is the bottleneck at 3 a.m. when a node fails.

Test 7: Neighbour Noise and Steal Time

Even dedicated hardware can share a network uplink or a storage backplane. Sample steal time and network throughput to a second node on the same rack over 30 minutes. More than 1% steal on a supposedly dedicated core, or throughput varying by more than 8% between runs, indicates contention that will surface as tick spikes under load.

Collect all seven results into a single table before comparing quotes. A provider that fails two or more tests is not worth an annual commitment regardless of price, and a provider that passes all seven at a higher monthly rate usually costs less over a year than one that needs a migration in month five. Shortlists built from measured data are easier to assemble when the quoted hardware and network details are already normalised — that is what the provider comparison on the main site is organised to support.

For operators running 100 or more concurrent slots, repeat tests 1 and 7 quarterly. Firmware updates, CPU substitutions and rack changes all happen without notice, and the only defence is a documented baseline you can re-run. Teams that prefer to control the power, cooling and drive selection outright can apply the same checklist to bare metal and colocation arrangements, where the acceptance test is the contract rather than a marketing page.