What this page is for
SystemCheck makes measurement claims, so it owes you the arithmetic behind them. This page is the reference: what each stage runs, how long it runs for, what is sampled and at what rate, how those samples become a decay figure and a grade, and where the measurement stops. Everything below describes the code that actually executes in your browser. Where a figure is an assumption, a placeholder, or a provisional constant, it is named as one. If you have a hardware monitor open beside the run, you should find nothing here that claims more than the browser can see.
The stages
There are two kinds of run. A Standard run is three minutes from launch to report and runs four stages in this order: CPU, memory, GPU, and path tracing. A Deep run is eight minutes and runs seven: the screen, CPU, memory, the GPU pass looped three times, CPU and GPU loaded together, path tracing, and a hot re-test of the CPU. The stage numbers below follow the Standard run; the Deep run is described in its own section.
CPU sustained throughput, 60 seconds
One Web Worker per logical processor runs a floating-point kernel in time-boxed chunks. The main thread attributes the finished work to fixed 250 ms windows, four samples a second, and keeps the whole series. On a Deep run the stage lasts two and a half minutes.
Memory bandwidth and latency, about 20 seconds
Workers stream 24 MiB arrays to measure bandwidth with one thread and then with up to six, and a single worker walks a random 64 MiB chain of dependent loads to measure the memory round trip against a 128 KiB cache walk. Reported, not scored.
GPU raster at a fixed 1600 by 900, 50 seconds
One lit model renders at a fixed internal resolution of 1600 by 900 pixels, whatever the window size, on a camera path that repeats every 10 seconds. Every frame is timed to GPU completion. The figure is frames per second at that resolution. On a Deep run it loops three times, 30 seconds each.
Path tracing under continuous load, to the end of the run
A WebGL2 path tracer runs samples back to back at a fixed 960 by 540 pixels, so the GPU is loaded for the whole stage. On a Standard run it is the last stage and runs until the run reaches three minutes; on a Deep run it runs for 40 seconds before the hot re-test. Samples per second is the measurement.
Stage 1, CPU sustained throughput
The stage runs for 60 seconds on a Standard run and 150 seconds on a Deep run. At the start, SystemCheck reads the number of logical processors the browser reports and clamps it to between 1 and 32, then creates one Web Worker per processor. Each worker loops a floating-point kernel that computes a square root, a sine, and a cosine per iteration and accumulates the result into a sink so the engine cannot optimise the loop away. Workers run in 90ms chunks and yield an 8ms slice between chunks, which is what keeps the progress readout alive while every core is loaded.
Each worker reports every chunk with its start, end and iteration count, and the main thread, ticking every 150ms, attributes that work to fixed 250ms windows in proportion to overlap. That gives four samples a second, about 240 across a 60-second stage. It also records a responsiveness figure derived from how far each tick drifted from its scheduled time, which is a measure of scheduling pressure, not of the CPU itself.
The first 1.5 seconds are discarded as warm-up, which covers worker start and engine tier-up but not the boost window that follows, because that is part of the signal. From what remains, SystemCheck reports the peak and the valley of the per-second means, the sustained rate as the mean of the whole post-warm-up pool, and a consistency figure equal to one minus the coefficient of variation across the per-second means, expressed out of 100.
One caveat on the operations-per-second tile shown while the stage runs: the benchmark counts kernel iterations, and that live tile multiplies them by 68, an estimate of the floating-point operations one iteration performs. That constant is an assumption, not a measurement, so the report does not use it: every CPU figure on the report is the counted iterations, in millions per second across all workers (M ops/s). Compare it against your own earlier runs, and do not compare it against another benchmark that counts operations differently.
Stage 2, memory bandwidth and latency
The stage runs for about 20 seconds and sits second so that both CPU-side measurements happen before the GPU stages warm the chassis. Up to six Web Workers are created, clamped to the number of logical processors. Each worker owns two 24 MiB double-precision arrays and copies one into the other in a loop, which the engine executes as a plain memory copy.
Bytes read plus bytes written are counted per 80ms chunk and the main thread attributes them to fixed 250ms windows. For the first five seconds one worker streams alone; for the next eight, all of them do. Each phase reports the mean of its last 60% of samples, past the ramp. The working set, 48 MiB per thread and 288 MiB in total, is far past any last-level cache, so the figure is the memory system rather than the cache.
The ratio between the two bandwidth figures is the part that carries a diagnosis. A memory system with headroom gives added threads more bandwidth; one that is already saturated by a single thread does not. Below about 1.35× the report says the memory system, rather than the cores, looks like the ceiling, which can indicate a single module or a single populated channel. The report does not claim to know the channel count, clock, timings or capacity, because no browser API exposes them. It reports the ratio and says what that ratio usually means.
Latency is measured last, with every stream stopped so the walk is uncontended. One worker fills a 64 MiB array of 32-bit indices with a single-cycle random permutation (Sattolo’s algorithm, so the walk visits every element with no short loops) and then follows it for three million steps. Every load depends on the previous one, so the processor cannot prefetch or overlap them, and the time per step is the round trip to memory including translation misses.
Four rounds are taken and the median reported, because the first round pays the translation warm-up. The same walk through a 128 KiB array gives the cache round trip for contrast. All memory figures are reported and not scored: there is no calibration set yet that says what a given bandwidth means for a machine of a given class, and a number folded into the score without one would be a weight attached to a guess.
Stage 3, GPU raster at a fixed resolution
The stage runs for 50 seconds on a Standard run, and as three 30-second loops on a Deep run. One model renders at a fixed internal resolution of 1600 by 900 pixels with a device pixel ratio of 1, independent of the window, and the result is scaled to fit the screen. The camera follows the same path on every machine and repeats every 10 seconds. Every frame ends on a GPU sync point, so a frame time is the time the GPU took to finish the frame, not the time the browser took to queue it. Where the browser exposes a GPU timer query, GPU-side time is recorded alongside. The first 3 seconds are excluded, which covers shader compilation and driver warm-up.
From what remains: the headline figure is frames per second at 1600 by 900, the median of the best five one-second windows. The sustained figure is the frames counted divided by the active time. Mean and 95th percentile frame times cover the whole stage. Stability is the share of one-second windows within 85% of the median window.
If frame times sit at the timer’s resolution or exactly at a display refresh interval, the report says the frame rate is at a floor: the GPU may be faster than the figure shows, so the figure is a lower bound. The VRAM badge shown during the stage is a load label derived from frame time, not a memory reading. The tab being hidden pauses the stage and its clock, and the hidden time is reported. Results from before revision 2026.09.3 used an adaptive supersampling index instead and are not comparable.
Stage 4, path tracing under continuous load
Path tracing follows the GPU stage on a Standard run, and the combined stage on a Deep run, without a pause, because a pause lets the machine cool. It requires WebGL2 with floating-point render targets. A fragment shader raymarches a small signed-distance-field scene, taking one jittered path per pixel per sample and accumulating a running mean into a float texture using a ping-pong pair. The stage has a fixed length, so the run keeps its fixed length on every GPU, and within it samples run back to back: the GPU is loaded for the whole stage rather than for one sample every so often.
The internal resolution is fixed at 960 by 540 pixels, independent of the window and of the device pixel ratio, so a high density display does not quietly change the workload. Each sample pass is timed to GPU completion with a sync point, and GPU-side time is recorded where the browser exposes a timer query. The on-screen image is refreshed at most about 30 times a second, and that display pass is not part of the timing.
Samples per second is the samples measured divided by the active time, after the first sample, which pays for shader compilation. Consistency is one minus the coefficient of variation across the per-sample times. Fewer than 20 measured samples and the result is not trusted. A hidden tab pauses the stage and its clock, and the hidden time is reported. Results from before revision 2026.09.3 paced the tracer to about 150 samples and are not comparable.
The deep run
The standard CPU stage is 60 seconds: long enough to catch a sustained-power budget expiring, which on Intel parts happens after a boost timer of 28 seconds at stock and 56 seconds on some boards, and short enough to sit through. It is too short for cooling to saturate. Reviewers who measure that run Cinebench for ten minutes or longer, and a laptop typically settles two to three minutes in.
The deep run is exactly eight minutes across seven stages, ordered to build heat and then price it: the screen, the CPU stage, memory, the GPU pass looped three times, CPU and GPU loaded together, path tracing, and a hot re-test of the CPU on the warmed machine, set against the cold stage.
The CPU stage runs for two and a half minutes. The settled level is the median of the means of three 20-second windows in the last minute, and the spread of those three is reported with it, so a level that was still moving is not presented as settled. The moment the machine reached that level is the end of the last ten-second bin that sat above it by more than the run’s own noise gate: 3%, or two and a half times the sample-to-sample jitter, whichever is larger.
The GPU pass runs three times, and the stability figure is the worst loop over the best. For reference, 3DMark’s stress test uses the same form with 97% as its pass mark over 20 loops; three loops is not the same test, so the figure is not a pass or a fail. Both kinds of run are free to run, and every figure either one measures, the settled level and loop figures included, is in the free report.
If the tab goes to the background during the CPU stage, the run pauses: the clock stops, the workers stop, and both resume when the tab returns. The pause is stated on the report, because the machine cooled while it waited.
Both runs are a fixed length from launch to report: three minutes and eight. Every stage before the last has a set duration, and the last runs until the run’s deadline, so time lost earlier shortens it instead of lengthening the run. A run that paused for a background tab ends late by the length of the pause. The screen stage times the interval between animation frames, which the browser paces to the display’s refresh rate, and reads the colour gamut and HDR support the browser reports; a gamut the browser does not report is recorded as not reported, never as a narrow panel.
Repeatability
One run is one sample. From the report, the CPU stage can be run again, up to two more times, and the report then shows every run side by side with a spread: the difference between the highest and lowest sustained throughput as a percentage of their mean. Under 3% is reported as tight, under 8% as moderate, and anything above as noisy, with the plain statement that a single run on this machine cannot be read more precisely than that spread.
Run 1 remains the scored run. The repeats start with the machine already warm from the full run, so a second run that comes in lower on a cooling-limited machine is expected, and the report says which case applied: later runs consistently lower is consistent with heat that did not clear between runs, and runs that jump in both directions point at something else competing for the cores. The spread is the honest error bar on everything else on the page, and it is the one figure here that no single measurement can produce.
How decay is calculated
Decay is the percentage by which throughput fell from an early window of a run to a closing window of the same run. It is not a comparison against another machine, a specification sheet, or a previous session. For the CPU stage, SystemCheck averages the first five seconds of samples after the 1.5-second warm-up, averages the last 20% of the post-warm-up samples, and expresses the difference as a percentage of the early average.
For the GPU stage it compares the frame rate over the first full 10-second camera period after the warm-up against the last full period, so both windows draw the same views. Both figures are noise-gated: a drop smaller than two and a half times the measurement’s own sample-to-sample change reads 0%, with the ungated figure kept alongside. Both are floored at zero: a machine that speeds up over a run reports 0% decay rather than a negative number. A GPU stage too short for two separate camera periods reports that its decay is not matched.
A high decay figure is evidence that the system could not hold its opening output. It is not proof of heat. Power policy, background load, driver behaviour, and browser heuristics all produce the same shape. The bands below are the ones the thermal throttling guide publishes, and they are the only bands this site uses.
How the grade is computed
The score is provisional. The weights and bounds below were chosen from the ranges we expect machines to measure, not fitted to a measured population, and they will change once enough runs on real machines exist to fit them. Until then the report prints a Provisional label beside every score, with the kind of run it came from, and the scoring version on every report says which set produced it.
The overall score is a weighted combination of five components measured in this run, each scored from 0 to 100. It is not a ranking of product names: CPU performance 30, CPU retention 25, GPU performance 20, GPU retention 10, and path tracing 15. The CPU carries the largest share because most work is CPU-bound, and because this site exists to measure what a machine keeps under sustained load; that way a fast graphics card cannot carry a slow, throttling processor to a high score. GPU retention carries least, because a GPU pass of 30 to 50 seconds is too short to heat a graphics cooler through. Memory is reported and not scored.
The three performance components are normalised on a logarithmic curve between a floor, which scores 0, and a ceiling, which scores 100: 10 to 600 million operations per second of sustained CPU throughput, 10 to 2,000 frames per second for the GPU at 1600 by 900, and 1 to 500 samples per second for path tracing at 960 by 540. The two retention components are 100 minus the decay. A logarithmic curve means doubling a figure adds the same number of points wherever you start.
Standard and Deep scores use the same CPU window. A Deep run’s CPU stage lasts two and a half minutes, and decay measured over that length is not the same figure as decay over a minute. So CPU retention is always scored from the first 60 seconds of the stage, by the method described under decay: the first five seconds after the warm-up against the last 20% of that minute, noise-gated. The decay across the whole Deep stage stays on the report as a diagnosis.
GPU retention is not window-matched in the same way: a Standard run scores the decay of its one 50-second pass, and a Deep run the decay of its first 30-second loop. The GPU result does not keep per-second data that would let both be cut to the same 30 seconds, so the two are close but not identical, and GPU retention carries only 10 points. When the GPU frame rate sits at a timer or refresh floor, GPU performance is scored as the lower bound it is and GPU retention is not penalised.
A component whose stage fell back, did not run, or ran with the tab in the background is left out, and its weight is spread over the components that did measure. The report marks such a score as partial and says how many components counted. A single-core CPU run is not scored for CPU performance, and a CPU stage that paused for a background tab is not scored for retention, because the machine cooled during the pause. GPU results from before revision 2026.09.3 have no fixed-resolution frame rate and are not scored for GPU performance.
The grade follows the score, with two limits. A partial run cannot grade above B. Decay of 15% or more caps the grade at B, and 30% or more caps it at C; a machine that gives up 30% or more, in the scored minute or across a Deep stage, is labelled “Slows heavily under load” rather than with any positive word.
What we cannot measure, and why
In every case below the reason is the same: no browser API exposes the value. This is not a decision about scope or a feature held back for a later release. A web page has no path to the sensors, and any site that prints a temperature from a browser benchmark is estimating it.
The one hardware identifier a browser does expose is the GPU renderer string, read through the WebGL debug renderer extension. SystemCheck cleans it by unwrapping the ANGLE prefix and stripping device identifiers, graphics API tokens, and shader model suffixes, then checks it for software renderer signatures such as SwiftShader and llvmpipe. That string is what the vendor and browser chose to report. It is a label, not a probe.
What SystemCheck v1 does not measure at all
Storage and network are untouched. There is no disk read or write test, no sequential or random throughput figure, and no network test of any kind. Memory is measured for bandwidth and dependent-load latency only: there is no capacity reading, no error test, and no check of the modules themselves. If you arrived here after running what you thought of as a PC stress test, it is reasonable to assume your drive was exercised and your RAM was tested for faults. Neither happened. A healthy grade here is not evidence that a failing drive or a faulty memory module is fine.
There is no crowd baseline. A completed run is stored on our server as its measured figures, the processor you picked and the graphics string the browser reported, with no address and nothing that identifies you, so that a calibration set can be built and a percentile can one day be honest; today SystemCheck still compares your run against nobody.
The only baseline is your own earlier run: the last five reports are kept in your browser, on this device, and when you run the same processor again the report shows the two side by side, curve over curve, with the change per figure. A change inside the run-to-run spread is reported as no change. Your address is attached to a stored run only when you ask for an emailed link or buy an unlock.
Measurement revision
Every report is stamped with the measurement revision that produced it, the scoring version, and the GPU backend the run used. The current stamp reads measurement identity 2026.09.3, forensic scoring v3, with the backend named alongside it. That stamp exists because a score is only meaningful inside the revision that generated it. Change a stage duration, a sample gate, a normalisation bound, or a weighting, and every previous number shifts underneath you even though both are printed as plain figures out of 100.
So two reports from different revisions are not directly comparable, and neither are two reports from different GPU backends at the same revision. Before comparing any two runs, check that the revision line matches and the backend matches. If either differs, the comparison is directional at best and should be described that way.
Fallbacks and partial runs
Each stage has a safety path so a failure cannot leave you on a frozen screen. Those paths matter to you, because two of them substitute fixed placeholder values for measurements, and one of them reaches the score.
Stage 4 fallback
If floating-point render targets are unavailable, if the WebGL context is lost, if no sample arrives within 6 seconds of starting, or if the stage runs eight seconds past its length, the tracer is replaced by a pre-rendered video and the result becomes a fixed placeholder: 6.8 samples per second, 100% consistency, 150 samples. That is not a measurement of your GPU, so the report prints “not measured” in the path-tracing row instead of the figure. It is flagged, and scoring refuses to trust it: path tracing is left out of the score, the score is marked partial, and the grade cannot go above B. So a fallback Stage 4 cannot inflate your score.
Stage 3 fallback
If the scene cannot obtain a GPU context, if assets fail to load, if no progress tick arrives within 6 seconds, if the stage exceeds its 50 second backstop, or if the stage throws and the error boundary recovers it, Stage 3 substitutes a fixed result: 18ms average frame time, 96% stability, and 6% decay. That result carries a fallback flag, and scoring refuses to trust it: both GPU components are left out, the score is marked partial and cannot grade above B, and the GPU cannot be named as the weakest link.
A fallback Stage 3 therefore cannot inflate your score, and the report prints “not measured” for its frame rate. If Stage 3 showed a video rather than a rotating lit model, or if you saw a recovery screen, repeat the run.
Stage 2 fallback
If Web Workers cannot be created, if a 24 MiB or 64 MiB allocation fails, or if the latency walk never reports, the memory stage ends with a result flagged as not measured. Nothing is substituted: the report prints “not measured” for every memory figure and the memory section says the stage could not complete. Because memory figures are reported and not scored, a missing memory result changes no other number on the report.
Skips, aborts, and partial runs
Skipping Stage 4 at the prompt records no path-tracing result at all, so path tracing is left out of the score and the run is graded as partial. Aborting any stage discards every partial result from that run rather than carrying half a session into a summary, because the score compares the stages against each other. If Stage 1 cannot create Web Workers it runs the same kernel single-threaded on the main thread, which produces an honest but much lower figure; the report labels it single-core and lists it under run quality.
Confounders we cannot control
Everything in this section moves your result without appearing anywhere in it. None of it is detectable from inside a browser tab. Publishing these first is the only honest way to hand you a number and ask you to act on it.
Browser thermal and power heuristics
Browsers reduce timer resolution, rendering rate, and background work under their own pressure signals, and those signals are neither documented nor readable from the page. A drop measured in the closing seconds may be the browser managing itself rather than the silicon backing off. Nothing in the run can distinguish the two. Treat a single run as a description of the whole stack, browser included.
Background-tab throttling
If the tab loses focus, requestAnimationFrame stops and timers are clamped. Every stage pauses rather than measure that: the CPU stage stops its clock and its workers, and the GPU and path-tracing stages stop their clocks, until the tab returns. The hidden time is reported, because the machine cooled while it waited, and a stage hidden for more than a second is left out of the score. Keep the tab in the foreground for the whole run.
Operating system scheduling
The scheduler decides which of your cores the workers land on, whether they get performance or efficiency cores, and how often they are preempted. Hybrid CPUs are especially sensitive: an identical machine can post a materially different sustained figure depending on where the workers were placed. Repeat the run and compare the spread rather than trusting one number.
Other load on the machine
Game launchers, update services, browser extensions, hardware monitoring tools, and other open tabs all compete for the same cores and the same GPU. This inflates decay and depresses consistency, and it looks identical to a cooling problem in the output. Close everything you can before a run you intend to keep, and note what you could not close.
Battery versus mains power
On battery, most laptops apply a lower sustained power limit, a lower boost ceiling, and a more aggressive fan curve, and Windows power plans do the same on mains. SystemCheck records charging state and charge drawn, so you can see which case applied, but it cannot read the power policy itself. A battery run and a mains run on one machine are two different measurements.
Thread and isolation limits
The CPU stage creates one Web Worker per logical processor reported by the browser, clamped to a maximum of 32. That figure is itself a browser estimate and some browsers deliberately round it down for fingerprinting reasons. SystemCheck does not use WebAssembly or SharedArrayBuffer, and the site does not send COOP and COEP headers, so cross-origin isolation is unavailable and none of the shared-memory threading paths apply. If worker creation is blocked outright, by a strict content security policy or a hardened browser, the stage silently falls back to running the same kernel single-threaded on the main thread. The number that produces is genuine, but it is a single-core figure, and the report labels it as one and lists it under run quality.
Driver and browser version
The JavaScript engine, the ANGLE translation layer, and the GPU driver all change between releases, and each of them can move a result by more than the hardware difference you are trying to see. A 15% gap between two browsers on one machine is entirely possible and says nothing about the hardware. Record your browser and driver version alongside any baseline you intend to compare against later.
Thermal state at the start of the run
A machine that has been idle for an hour starts cold and has more headroom to lose, which raises measured decay. A machine that has just finished a game starts hot and may show almost no decay because it had already given up its headroom before the run began. This is the single largest source of run-to-run disagreement, and it is invisible in the output. Standardise your starting state, then compare runs that began the same way.
The practical consequence of the list above is that a single run is a sample, not a verdict. Run the test three times from a consistent starting state, keep the tab in front, and compare the spread. If three runs agree closely, the number describes your machine. If they do not, the disagreement is itself the finding, and it usually points at background load or a starting thermal state rather than at the hardware.
Corrections policy
Methodology changes get versioned, dated, and disclosed. Any change that alters what a stage runs, how long it runs, what is sampled, how decay is derived, or how the stages are weighted increments the measurement revision, and every report generated afterwards carries the new stamp. Reports generated before a change keep the revision they were produced under, so a saved report stays interpretable in the terms that created it, and this page will continue to describe how superseded revisions worked rather than quietly rewriting history.
If a figure published here turns out to be wrong, the correction gets written into this page and dated, not deleted. If a defect is found in a stage, the defect gets described alongside which revisions it affected and what it did to the score. This policy is written now, while nothing is in dispute, because a corrections policy published after the first disputed number is not worth reading.
Revision 2026.09.3 and scoring v3, September 2026
The GPU raster stage now renders at a fixed 1600 by 900 with every frame timed to GPU completion, and reports frames per second at that resolution. Before it, the stage reported a raster index derived from an adaptive supersampling factor, which could read ten to fifty times higher than the pixels actually drawn. Path tracing now runs under continuous load at a fixed 960 by 540; before it, the tracer was paced to about 150 samples, so the GPU sat idle between samples. Both GPU stages now pause with a hidden tab, the combined stage leaves a core free for the render loop, and CPU decay is noise-gated.
Scoring v3 replaced v2 at the same time. Under v2 the score was mostly GPU and path tracing: CPU speed added at most 6 points, and its floor of 200 million operations per second sat above what most machines sustain, so it added nothing on most of them. Decay was measured over the whole CPU stage, so a Deep run and a Standard run of one machine were not comparable, and a grade of B was labelled Solid even at 40% decay. Scores from v2 and v3 are not comparable, and neither are revisions before 2026.09.3.