Benchmark methodology

PC Benchmark X measures the execution of defined CPU/GPU scenarios and the latency of response to a software signal. The amount of work within a scenario is fixed. Durations and score weights are set by the methodology that the client receives from the server.

This page describes engine generation 0.8.0 and the base parameters. The actual parameters of a new run may differ after the server methodology is updated. An already completed test does not receive new measurements from a change in settings: only a recalculation of its scores from the saved data is possible.

Preparation

Open BoosterX → Benchmark → Test, select a profile and check the displayed parameters. During measurements, BoosterX pauses its own monitoring and minimizes its windows, then restores their state. External programs keep running and can affect the numbers.

Repeat tests with the same engine and driver version, the same power, overclocking and cooling settings. On a laptop, connect the charger. For a before/after comparison, change one setting and record exactly what you changed.

Candidate sequence

Run part	Base duration	Purpose
Warm-up	15 s	Prepare the load for the scored measurements
CPU	20 s total	Three blocks of approximately 6,67 s
GPU	30 s total	10 s each on Geometry, Shader and Compute, in three blocks each
Combined	30 s total	Three blocks of 10 s
Calibration	10 s	Select the Loaded Latency complexity
Latency warm-up	2 s	Prepare the measurement path
Baseline Latency	20 s	Measure latency under base load
Loaded Latency	20 s	Measure latency under calibrated load

The Baseline in the base Candidate has been increased from the previous 5 to 20 seconds. The GPU value in the table refers to the entire GPU part, not to each of the three scenarios separately. Transitions, resource preparation and completion add time to the stated durations.

Performance loads alternate in three rounds. Before each CPU block, the simulation state is reset and 512 preparatory frames are executed outside the score. This reduces dependence on the previous block, but does not eliminate warm-up, frequency changes or background load.

Run profiles and durations

Profile	Purpose	Transition	Warm-up	CPU	GPU total	Combined	Calibration	Latency warm-up	Baseline	Loaded
Candidate	Publication of a suitable result	0,5 s	15 s	20 s	30 s	30 s	10 s	2 s	20 s	20 s
Quick	Short local diagnostics	0,25 s	7,5 s	10 s	15 s	15 s	5 s	1 s	2,5 s	10 s
Extended	Long local diagnostics	1 s	30 s	40 s	60 s	60 s	20 s	4 s	40 s	40 s

These are base durations that can be changed by the server. Profile availability is also controlled remotely. Candidate is intended for normal publication; Quick and Extended remain local. A custom incomplete set of tests is not a substitute for a rated run.

A longer recording provides more observations, but by itself does not guarantee a better score or the absence of interference. Do not mix profiles in a before/after experiment.

Collection without writing to disk in every frame

Measurements are collected into pre-allocated memory blocks. On every frame, the program does not format JSON and does not write a result record to disk. After the work is completed, the data is merged and processed. This reduces the impact of collection on the test, but does not make the measurement tool free in terms of resources.

Summary metrics, time distributions and run details are saved. Recalculation from the saved measurements verifies the arithmetic; hardware repeatability can only be verified by new runs.

Run quality and unsuitability of a result

Pay attention to warnings about background load, power, window switching, display changes and environment conditions. Virtualization or a separate warning by itself proves neither tampering nor a specific cause of a low score.

A cancelled, incomplete or incorrectly measured run may not have a suitable score and is not allowed for normal publication. The server separately determines publication availability and whether verification is needed. Follow the message in the program; repeat the test under quiet conditions if the cause is related to measurement.

Recording quality does not mean that all external interference has been ruled out. A practical conclusion requires repeated tests and comparable conditions.

How to read the result

Metric	Meaning
CPU Score	Speed of the CPU scenario and P99 of CPU frame time
GPU Score	Normalized speed of Geometry, Shader and Compute
Core Latency Score	Estimate of internal latency; more points is better
Consistency	Additional characteristic of the slow tail within a run
PC Score	Geometric combination of CPU, GPU and Latency; base weights 60/20/20

Real latencies are shown in milliseconds, and for them lower is better. Consistency is not included as a separate component in the new final formula and does not replace repeatability between runs. The detailed formulas, references and weights are open.

Limits of the result

• A synthetic scenario helps detect system changes, but does not replace a test of a specific game.
• Low variance does not yet prove the accuracy of every timestamp or the absence of systematic error.
• Core Latency does not measure the full path from mouse to pixel illumination.
• The overall position in the rating depends on the chosen weights, the composition of participants and server-side recalculation.
• Recalculating an old score does not make an old version of the load new. To compare corrected scenarios, perform a new test.

The repeatability verification archive refers to version 0.5.2. The new methodology does not automatically inherit its measured variance figures.

Updated: 2026-10-02.