The Proving Ground

Every VPS review on the internet repeats the provider’s spec sheet. This page does something narrower and, we think, more useful: it rents a plan, puts a small collector on it, and publishes what the machine actually did — how much of its CPU the hypervisor took away, how close it came to running out of memory, how long its disk took to write, and whether it stayed up. Each number is dated to the sample it came from, and every number the box could not read is listed by name rather than printed as a zero.

A collector runs on each box every thirty minutes. It reads the kernel’s own counters twice, about ten seconds apart, and records the difference: CPU time split eight ways (including steal, the time the hypervisor gave this VM’s processor to somebody else), Linux pressure-stall figures for CPU, memory and I/O, memory available as the kernel reports it, the reads and writes the disk completed and how long they took, uptime, and the boot id. One sample is one JSON file.

Three things about that are worth knowing before reading a table. A ten-second window every half hour is a sparse sample: it sees what the box was doing at that moment, not everything it did in between. The disk figures are the box’s own reads and writes — the numbers a node would actually experience — and not a benchmark; a synthetic test beside a syncing node measures its own contention with that node, so it is off unless deliberately requested and would be reported under a separate heading if it ever ran. And the CPU split is checked on every sample so that guest time, which the kernel counts inside user time, is never added twice — the mistake that would understate steal.

Every snapshot is validated against a fixed contract before the box is allowed to write it, again before it is pushed, and again by this site’s build. A snapshot that reports a number it could not read fails all three. What you see here is built from the files that passed.

The same boxes run this site’s guide-verification harness once a week: containers that install a node stack from the internet and execute a guide’s commands. That is real CPU, disk and network on exactly the machine being measured, so a sample taken while it runs would be a measurement of the harness, not of the provider.

Two rules, both applied at build time, both derived from the box’s own configuration and this repository’s own records:

• Any sample inside the weekly harness window — Sunday 03:00–05:30 UTC (the timer fires at 03:00 with up to 30 minutes of jitter, and a run has a two-hour budget) — is excluded.
• Any sample that overlaps a harness run that left an artifact, on any day, is excluded. Hand-started runs count.

Both windows are extended by 5 minutes after they end, because the pressure figures are five-minute trailing averages and a sample taken two minutes after a run still carries it. Excluded samples are not deleted: they are listed under their box with the reason, so the count of what was left out is as visible as what was kept. As of the latest snapshot, 11 samples have been excluded.

One cost of that rule, stated plainly: a harness artifact records the kernel it ran under and nothing that identifies the machine, so a run window is applied to every box rather than only to the box that ran it. That is the conservative direction — an excluded clean sample is lost data, an included contaminated one is a false number — and it is why a box can have merged snapshots and no included samples at all.

Each box’s section lists, by field name, every metric the collector recorded as unavailable, with the collector’s own reason. Two are true of every box until it runs a node:

• Chain state — sync progress, block height and peer count. The collector has a hook for it and no node is attached to it yet, so nothing here says how fast a chain synced. That is the number this page is working towards, and it will be dated like everything else when it arrives.
• The active disk probe — a bounded fsync test. Off by default, for the reason given above. When it runs it will be reported separately and never merged with the passive figures.

Two more limits apply to every number on the page. The samples are sparse, as described above, so a burst of steal between two windows is invisible. And whether a box is a dedicated VM is a declaration made by whoever installed the collector, not a measurement — nothing on a Linux guest can tell a dedicated VM from a quiet shared one. Each box prints that declaration as a declaration, beside the process and container counts a reader can use to check it.

Each box says who pays for it, beside its numbers, and the first row of the comparison table says it too. A server this site rents says so; a server or credit a provider supplied carries a separate disclosure naming the provider and what was supplied, because that is a different thing to know about us than a referral link is. In either case the arrangement is the same: no provider sees a draft, has editorial input, or can ask for a number to be withheld. An unflattering figure is published as measured, and the day a provider objects to one is the day it stops being measured, not the day the figure changes.

Prices are the one thing this page will not print. They belong to the provider and they change, and a stale price here would be a false claim about a named company. The comparison table names who pays for each box instead, and each box’s section links the provider’s own live price on both billing terms.

1. The box’s timer runs the collector. It takes the sample, validates it against the contract, and refuses to write one it cannot validate.
2. The box commits the file to a dated branch of this site’s repository. Its credential can push and do nothing else; it cannot open or merge a pull request.
3. A person opens the pull request and merges it. The build re-validates every file under the snapshot directory and fails on anything it does not recognise.
4. At build time this page reads every merged snapshot, applies the exclusion rules above, and computes each row from what is left: a mean is a mean over the included samples, a worst sample is the single sample that produced it, and both carry the instant they came from. No number is stored anywhere but in the snapshots themselves.

The page never contacts a box. If every box went offline tomorrow, this page would show the same numbers with the same dates until a new snapshot was merged — which is the point: a published measurement should not be able to change without a reviewable diff.