You get roughly one chance to test a dedicated server before a 12–36 month commitment, and it usually comes as a short trial, an SSH shell, or a provider’s demo box. This is a time-boxed verification pass: what to read on the order form, what to run on the machine, and the numeric thresholds that separate real hardware from a virtualised reseller. Everything below fits in about twenty minutes and needs no tooling beyond the standard Linux utilities plus ipmitool.
Step 1 — Order-form fields to capture in writing
Ask for these in the pre-sales ticket, not on a phone call. A provider that will not put the numbers in writing usually cannot deliver them.
| Field | What to look for | Red flag |
|---|---|---|
| Exact CPU model | Xeon Gold 5412U / EPYC 9354P / Ryzen 9 7950X3D | “Intel Xeon” or “modern CPU” |
| Port speed | 10 Gbps guaranteed on gaming SKUs | “up to 1 Gbps” shared |
| Bandwidth commitment | Unmetered 10 Gbps or 100+ TB | 10 TB then charge per GB |
| DDoS mitigation | Always-on, Gbps figure quoted | On-demand filtering only |
| OOB access | IPMI / iDRAC / iLO included by default | Paid add-on or ticket-only rescue |
| Hardware replacement SLA | 4-hour guaranteed swap | “best effort, 24–48 h” |
| Power feeds | Dual A+B, redundant PSU | Single PSU, single feed |
| IP allocation | /29 usable plus private VLAN | Single IP with per-IP fee |
Step 2 — Confirm it is real bare metal
sudo systemd-detect-virt # expect: none
lscpu | egrep 'Model name|Socket|Core\(s\)|MHz|Hypervisor|Flags'
nproc --all
sudo dmidecode -t memory | egrep 'Size|Speed|Type|Locator|Rank'
sudo dmidecode -s system-product-name # real chassis model, e.g. PowerEdge R7615
lspci | egrep -i 'nvme|ethernet|raid'
systemd-detect-virt returning anything other than none means you are buying a VM with a dedicated label. dmidecode telling you the memory is single-rank DDR4-2666 when the SKU promised DDR5-4800 is the other common substitution, and it directly caps your game server’s memory bandwidth.
Step 3 — Storage tier and real throughput
lsblk -d -o NAME,ROTA,SIZE,MODEL # ROTA=0 and NVMe in MODEL
sudo nvme list # expect /dev/nvme0n1, Gen4 or better
sudo hdparm -tT /dev/nvme0n1 # sequential read
sudo dd if=/dev/zero of=/root/verify.bin bs=1M count=4096 oflag=direct conv=fdatasync
sudo smartctl -a /dev/nvme0n1 | egrep 'Percentage Used|Power_On_Hours|Media_Wearout'
cat /sys/block/nvme0n1/queue/scheduler
| Check | Acceptable 2026 value | Why it matters |
|---|---|---|
| Device type | NVMe SSD, ROTA=0 | SATA SSD halves ARK and Palworld world-save speed |
| Sequential read | >3,000 MB/s (Gen4 >6,000) | Directly sets map-load time |
| Sequential write | >1,000 MB/s | Determines autosave stall length |
| Power_On_Hours | <20,000 h | A 40,000 h drive is near end of life |
| Percentage Used | <20% | Worn drives cause write latency spikes |
| I/O scheduler | none (NVMe) | mq-deadline adds overhead on NVMe |
Step 4 — Network quality, not just speed
ethtool eth0 | grep -E 'Speed|Duplex' # expect 10000Mb/s, Full
mtr -rwzbc500 1.1.1.1 # loss and jitter over 500 packets
ping -A -c 2000 -i 0.2 <peer-ip> | tail -n 3
iperf3 -c <provider-speedtest> -P 4 -t 20
vmstat 1 5 | awk '{print $16}' # steal time column
cat /proc/net/softnet_stat | awk '{print $2}'
Loss above 0.2% over 500 packets or jitter above 3 ms will be visible in-game on a 64-tick server. Steal time above 1% means another tenant is consuming your CPU, which is the single clearest sign of an oversubscribed host. ethtool reporting 1000Mb/s when the order form said 10 Gbps is a billing-grade discrepancy worth escalating immediately.
Step 5 — Out-of-band and power control
ipmitool -I lanplus -H <bmc-ip> -U admin -P '<pass>' chassis power status
ipmitool -I lanplus -H <bmc-ip> -U admin -P '<pass>' mc info
ipmitool -I lanplus -H <bmc-ip> -U admin -P '<pass>' sel list | tail -n 20
ipmitool -I lanplus -H <bmc-ip> -U admin -P '<pass>' sol activate
Test the reboot path deliberately: run chassis power cycle and time how long the box takes to come back to a responsive SSH prompt. Anything past 5 minutes on a dedicated machine points to a slow POST or a shared storage mount. If the provider has no OOB at all, ask for their rescue-mode response time in writing — when a kernel panics during a 200-player Rust wipe, a 30-minute support ticket is a lost population.
Step 6 — The five-minute load reality check
- Run your real workload, not a synthetic benchmark: start the actual game server, fill it to 70% of the intended slot count with bots, and watch tick and CPU.
- Add a 100 MB write every 60 seconds to the data directory to emulate autosaves and confirm the game process never stalls past 300 ms.
- Generate 500 Mbps of outbound UDP and verify throughput and a stable RTT with
mtrrunning alongside. - Check thermals via
ipmitool sdr type temperatureafter 20 minutes of load; throttling above 85°C on a leased box usually means failed fans the provider has not noticed.
Red flags that justify walking away
- The trial box and the production box have different CPUs — always re-run Step 2 after provisioning.
- Bare-metal claim proven false by
systemd-detect-virt. - No written SLA on hardware replacement or a “best effort” clause.
- DDoS mitigation measured in Mbps rather than Gbps for a public game server.
- Autosave stalls visible in the trial, with no NVMe upgrade path offered.
Use this pass on any candidate, then cross-check the numbers against our dedicated server comparison before you commit. If you want the shortlist-first approach instead, start by reading how to compare dedicated server providers on price-per-spec, then come back and verify the winner with the commands above. Fifteen minutes of dmidecode and mtr output is worth more than any spec sheet.

Leave a Reply
You must be logged in to post a comment.