Benchmark data: what will be published and in what format

What file format is planned?

Each release would be one CSV file in UTF-8, with one row per run. Timestamps would be ISO 8601 in UTC. A run is one load profile, played on one plan in one region for a stated duration. Each row would point to its raw log file, so any figure in the table can be checked against the log it came from. Repeat runs on the same plan would appear as separate rows, not averages.

The licence for released data is not yet set, because no dataset has been released.

Which fields would each row hold?

These are field names and meanings only. No row exists.

A game that reports frame time instead of ticks, such as Palworld, would use the same tick-time fields with a note saying what the number is. Blank means not applicable or not available, and never zero.

How should a row be read?

A row describes one run on one plan on one day, so it can support a narrow claim and little else. Three rules would apply to anyone using the file:

• Compare like with like. Two rows are comparable only if game build, pack version, load profile, player count and plan RAM match. A different region changes round-trip time but says little about the host's hardware.
• Read repeats as a spread. Each repeat run is its own row, so the distance between the best and worst run on a plan is part of the result. Three runs that disagree widely are a finding about consistency.
• Treat the 95th percentile and maximum as the player's view. A healthy median can sit beside a run that players would call unplayable. The MSPT and TPS guide explains why.

A file like this couldn't answer several things buyers care about. It wouldn't show how a plan behaves in another region, after the host changes hardware, or over months, and it wouldn't say anything about support quality. Those need their own evidence, and only Palworld and All the Mods 10 are planned for a 30-day run.

What would be left out of a release?

Raw logs can contain more than performance data, so each would be reviewed before release. Player names, IP addresses, chat, and connection or API secrets would be removed, and the file would note that this was done. Support replies wouldn't be published without the host's permission, because at least one host's terms treat communications as confidential.

How would releases be versioned and corrected?

Each release would be a new dated file, and earlier files would stay available. A correction would produce a new version with a change note, never a silent edit. A rerun would get a new run id even if everything else matched. Column names and units would stay stable between releases, and any change would be listed in the log below. A host's right of reply would apply to released data as it does to pages.

Nothing would be added until each of these was true: the run followed a load profile fixed in advance, the host's terms had been read and any needed permission recorded, the raw log existed, and the row could be regenerated from that log.

How does this connect to the rest of the method?

The rig, regions and profilers are described in the test rig plan. The way load is applied is in the load profiles, and the capacity measure the price tools would use is in the stable player definition. A run would only be added after the host's terms had been read; see independence and host terms, which records that no host read so far grants a right to benchmark.

To measure your own server now, use the benchmarking guide. The reports page lists planned recurring outputs, and the benchmarks hub shows which games have any evidence.

Commitment log

Later entries would record each run batch, each release and each correction to released data.