How the Bottleneck Calculator Works — and How Accurate It Is

What the calculator actually computes

The bottleneck calculator compares performance headroom between your processor and your graphics card under a workload you choose, then reports which of the two runs out of headroom first and how large the gap is.

It does not measure your computer. It has no access to your machine, your drivers, your case temperature or your background processes. It compares two parts on the basis of how those parts perform in aggregate, and infers which one becomes the constraint. That distinction matters for how much weight to give the answer, and we return to it under limitations below.

Where the performance scores come from

Each processor and graphics card in the database carries a single score on a 0–100 scale. Those scores are relative positions, not units. A score of 80 does not mean 80 frames per second, 80 watts, or 80% of anything. It means the part sits at that point in the ordering of parts we hold.

The scores are derived from aggregated public benchmark results, normalised in three steps:

1. Collect across workloads. For processors we weight gaming-representative results well above heavily multi-threaded production results, because the primary use of this tool is frame rate. For graphics cards we weight rasterised rendering above ray-traced rendering, for the same reason.
2. Normalise to the current flagship. The strongest part in each database is pinned near 100 and everything else is placed relative to it. This is why scores shift slightly when a new generation launches — the reference point moved, not the hardware.
3. Collapse to one number. Each part gets a single figure so two parts can be compared directly.

Step three is a real loss of information and we would rather say so than hide it. A single score cannot express that two graphics cards rank differently in rasterised and ray-traced workloads, or that one processor leads in games while another leads in rendering. Where that distinction changes the advice, the page you are reading it on should say so in words.

How resolution weighting is applied

Resolution is the most influential input in the model, and the reason is mechanical rather than statistical.

Raising resolution multiplies the pixels a graphics card shades per frame, so graphics work scales roughly with pixel count. Processor work per frame does not scale that way — game logic, physics, and draw call submission cost approximately the same whether the result is displayed across two million pixels or eight million. The model therefore holds the processor's effective load close to flat as resolution climbs, while raising the graphics card's.

The consequence is intended: the same pair of parts will be reported as processor-limited at 1080p and graphics-limited at 4K. Neither figure is the true one. A bottleneck percentage describes a combination doing a specific job, and the job is part of the input.

Workload selection adjusts the same balance. Streaming or recording adds processor load on top of the game. Video editing and 3D rendering shift weight toward the processor and toward core count. General desktop use flattens both.

How memory and overclock inputs are treated

Memory speed, capacity and channel configuration adjust the processor's effective score rather than entering as a separate component. Memory feeds the processor, so a configuration that starves it lowers what that processor can deliver. The adjustment is deliberately conservative, and it is directional rather than precise — we can say with confidence that a single-module configuration costs real performance, and we cannot tell you the exact figure for your kit on your board.

Overclock offsets raise the relevant component's score in proportion to the clock increase you enter. This assumes the clock is stable and thermally sustainable, which the model cannot verify. Treat overclock results as the best case rather than the expected case.

What the percentage ranges mean

The thresholds below are interpretive guidance, not measurements. They exist because a bare number is not actionable, and they are deliberately wide. A percentage is not a share of the frames you are losing — what a bottleneck percentage does not mean covers that misreading alongside three others, and the arithmetic behind the figure shows how it is derived. To test any result against your own hardware, two settings changes verify it without monitoring software.

Result	Interpretation
0–5%	Well balanced. No action.
5–10%	Normal. Not noticeable in play.
10–20%	Mild limit, visible in processor-heavy titles. Tune before buying.
20–35%	Clear limit on the named component. Plan an upgrade.
35%+	Severe mismatch. The named part is holding the other back substantially.

A 19% result and a 21% result describe the same system. If a threshold appears to change your decision, the decision was not driven by the data.

The CPU refresh-rate model

The CPU bottleneck calculator answers a different question and uses a different model. It takes no graphics card, and it reports a verdict band plus a binding specification rather than a frame rate.

Each genre carries a demand figure on the same 0–100 scale as the processor score, representing the frame-preparation capability needed to hold a 144 Hz reference. Simulation and strategy sit highest, story-driven linear titles lowest. Target refresh scales that demand — 60 Hz asks for roughly 70% of the reference, 240 Hz roughly 128%. The processor's score minus that requirement gives the headroom that produces the verdict.

The binding specification is decided in order: if thread count falls below what the genre spreads work across, that is the constraint. If threads are sufficient but the absolute score is modest, per-core throughput is the constraint. If both are strong and the target is still demanding, cache and memory latency is what remains — which is why large-cache parts pull ahead at high refresh rates.

Why no frame-rate figure. Converting a relative score into an absolute frame rate would require knowing your engine, driver version, thermals and background load. We do not know any of those, so a specific number would be invented precision. Bands and a named constraint are what the available data actually supports.

Resolution is reported as context rather than folded into the arithmetic, because resolution does not change how much work the processor does per frame. It changes whether the graphics card will ever reach the processor's ceiling.

The GPU compute-versus-VRAM model

The GPU bottleneck calculator separates two failure modes that a single percentage cannot express, and it takes no processor.

Compute is handled like the main model: each resolution carries a demand figure on the 0–100 scale, adjusted upward for ray tracing and downward for upscaling. The card's score minus that demand gives the compute margin.

Memory is handled as pressure points rather than a predicted gigabyte total. Resolution, texture quality, ray tracing and additional displays each add pressure; upscaling subtracts it. That total maps to a capacity the settings want, which is then compared against the card's real memory capacity from the database. The output is a band — ample, adequate, tight, or over budget — because the useful question is whether you are within budget, not what the exact figure is.

Whichever of the two shows the larger deficit is reported as binding. This matters because the remedies differ: texture quality is the largest memory cost and nearly free on compute, while shadow and volumetric settings are the reverse. Treating both cases identically is how people spend an afternoon changing settings that were never the constraint.

The memory thresholds are deliberately conservative and describe comfortable operation rather than the absolute minimum a title will launch with. A card reported as tight will usually run; it will be closer to the cliff described on that page.

The memory configuration model

The RAM bottleneck calculator uses no hardware scores at all. It evaluates a configuration against three variables and reports which one binds, in a fixed priority order that reflects their real impact:

1. Channel population. A single module halves available bandwidth. Nothing else about the memory matters as much, so this is checked first and always outranks the other two.
2. Capacity. Assessed against thresholds that vary by workload rather than a single blanket figure, because gaming, streaming and video editing want materially different amounts. Exceeding capacity forces paging to storage, which is a cliff rather than a gradient.
3. Speed and latency. Compared against a platform floor and a practical ceiling. Platforms where the memory clock is coupled to the processor's internal fabric are flagged as more sensitive, because they are.

Systems using integrated graphics have a portion of capacity deducted and their channel verdict escalated, since the processor and graphics block share the same bandwidth.

No frame-rate delta is produced. Translating a memory change into frames would require knowing your resolution, engine and processor. What we can say honestly — and what the page says — is that memory changes land on 1% low frame rates more heavily than on averages.

The motherboard bandwidth model

The motherboard bottleneck calculator is the one tool here working from hard published specifications rather than a relative model. PCIe bandwidth per lane per direction is defined by the standard:

Generation	Transfer rate	Per lane	At ×16
PCIe 3.0	8 GT/s	≈0.985 GB/s	≈15.8 GB/s
PCIe 4.0	16 GT/s	≈1.969 GB/s	≈31.5 GB/s
PCIe 5.0	32 GT/s	≈3.938 GB/s	≈63.0 GB/s

Slot bandwidth is that per-lane figure multiplied by lane width — straightforward arithmetic over real numbers. The interpretation bands are ours: roughly 15 GB/s and above is ample for any current card, below about 3.5 GB/s is genuinely constrained, with two bands between.

The output that matters is the interaction. When lane width is reduced and the card is short of memory, the tool escalates the warning, because a card that has run out of local memory streams assets across exactly the link that has been narrowed. Either condition alone is usually survivable; together they compound.

The power-delivery assessment is a coarse pairing of board tier against processor tier rather than a measurement. We do not hold a database of board designs, and we would rather say so than imply a precision we cannot support. It flags the combination that actually bites — a modest power stage under a flagship processor — and stays quiet otherwise.

The power supply estimation model

The PSU bottleneck calculator produces no performance figure, because a power supply does not degrade gradually — it delivers or it protects itself.

The graphics card figure comes from you, not from us. The tool asks for your card's rated board power because that is a published manufacturer specification, and using the real number is better than any estimate we could substitute. We hold no power database, and we would rather ask than guess.

Processor draw and platform overhead are given as bands, because both vary with the work being done, the board and the cooling. Mid-range, high-end and flagship processors carry conventional sizing ranges; platform overhead covers board, memory, a drive and stock fans. Extra drives, fans and a liquid cooler add their own small ranges. The sum is therefore reported as a range rather than a point figure, which is the honest shape for this estimate.

The recommended rating applies a multiplier to the top of that range. It is larger for cards at or above roughly 250 W rated board power, because those draw brief excursions well above their rating and the unit must absorb them without tripping over-current protection. It is larger again for older or unknown-quality units, which typically have less margin in their protection circuitry.

Two things the model deliberately does not do. It does not prescribe a purchase — it reports draw and headroom, and what you buy depends on how long you intend to keep the unit. And it does not claim a frame-rate effect, because there almost never is one.

The display and refresh model

The monitor bottleneck calculator is the most straightforward on the site, and most of it is arithmetic rather than modelling.

Your frame rate comes from you. You can read it off an in-game overlay, which makes it a real measurement rather than an inference. Displayed frames are then simply the lesser of your frame rate and your refresh rate, and the surplus is the difference.

The latency point the page makes is mechanical rather than modelled: a panel shows the most recently completed frame, so finishing frames more often means the frame waiting to be displayed is fresher. No measurement is required to state that, and we make no claim about how many milliseconds it is worth on your system.

The frame-cap recommendation sits a few frames below your refresh ceiling. That is established practice for keeping a variable refresh panel inside its sync window rather than a figure we derived, and the tool only offers it when you tell it variable refresh is enabled.

Multi-display costs are reported qualitatively — minimal, small, or notable — keyed off what you say is on the second display rather than a predicted megabyte or watt figure. The number of displays is a poor predictor on its own; the content is what matters.

The storage symptom model

The storage bottleneck calculator is not a calculator in the usual sense, and that is deliberate. Storage does not participate in sustained frame rate — once a scene is in memory the drive is idle with respect to rendering — so returning a percentage would be answering a question the component takes no part in.

Instead it matches your symptom against what storage can and cannot cause. Each symptom carries a fixed role: loading times are a storage problem outright; traversal hitching and texture pop-in are conditional on the drive class and how heavily the game streams; a merely low frame rate, combat stutter and first-run shader stutter are not storage problems at all, and the tool names what they are instead.

The conditional cases resolve against the drive. On solid-state with light streaming, storage stops being a credible explanation and the tool says so rather than hedging. Where a symptom involves asset streaming and the card has 8 GB or less, it flags the interaction — assets evicted from graphics memory must be re-read from the drive, so a memory-starved card generates far more storage traffic than a well-provisioned one.

Drive classes are relative capability rather than benchmark figures. The model encodes one large step and one small one: mechanical to any solid-state is decisive, while SATA to NVMe is modest for games because game engines rarely issue the deep request queues that let NVMe show its advantage. We publish no transfer figures because we have measured none.

The integrated graphics model

The integrated graphics calculator is the only tool here whose output is a viability verdict rather than a limit. With no dedicated card there is no second component to compare against, and the graphics side is almost always the constraint — so naming it tells the reader nothing they did not already know.

Its defining mechanic is that memory bandwidth caps the graphics capability. Integrated graphics read from system memory over the bus the processor is also using, so effective capability is the lower of what the graphics block can do and what the memory configuration can feed it. A single module halves that bandwidth, and the tool treats it as the dominant constraint because it is one.

Graphics classes are described by generation and memory breadth — older or basic desktop, current desktop, recent wide-memory APU — rather than by model name. We hold no integrated-graphics database, and inventing model-level figures would be worse than tiering honestly.

The capacity note deducts a reserved portion for graphics before assessing what remains, because on an integrated system every gigabyte is doing two jobs. The reservation is an approximation; some designs adjust it dynamically and we do not attempt to predict that.

How accurate is this, and what the model leaves out

Accurate enough to rank upgrade options, not accurate enough to predict a frame rate. The estimate is reliable about which component runs out first and approximate about by how much, because the five items below are invisible to it. These are known gaps, not oversights: each is excluded because we cannot estimate it honestly from hardware identity alone, and a figure we cannot stand behind is worse than an admitted omission.

• Thermal and power behaviour. Sustained clocks depend on your cooler, case airflow, ambient temperature and the power limit your board or laptop manufacturer set. Two identical part lists can perform measurably differently. This is the single largest source of error in any bottleneck estimate, and it is largest of all for laptops.
• Per-title behaviour. Driver overhead differs between games and between vendors. Engine threading differs enormously. A pairing can be processor-limited in one title and graphics-limited in another on the same day.
• Software environment. Background applications, overlays and recording software consume processor time a game would otherwise use.
• VRAM exhaustion. Running out of graphics memory is a different failure mode from running out of compute, and it does not appear as a percentage. It appears as texture pop-in and sudden frame-time spikes. A balanced pairing on a memory-starved card can still perform badly.
• Frame-time consistency. The model reports a capacity gap, which is an average-case measure. Stutter is a worst-case phenomenon. A system can be well balanced on average and still feel poor to play on.

How the database is maintained

Parts are added as they become widely available at retail rather than at announcement. When a new flagship launches, the normalisation reference moves and existing scores are recalculated against it, which can shift a previously checked result by a few points without any hardware having changed.

The database currently holds 102 processors and 76 graphics cards. It is not exhaustive, and it is weighted toward parts people are realistically choosing between today rather than toward complete historical coverage. If a part you own is missing, the closest model in the same tier is a reasonable substitute for estimating balance.

How to verify this on your own PC

We would rather you measured this than trusted it. This is the only section on the site that covers method.

What to measure, and why averages mislead

Utilisation figures are where you start, but an average settles less than it appears to. Frame time — how long each frame takes to arrive — is the signal that matches what you feel. As an illustration, ninety frames per second arriving unevenly plays worse than seventy-five arriving on schedule.

This is why 1% low frame rates diagnose better than averages: the 1% low is the slowest hundredth of frames in a capture, which is where stalls live.

Reading the utilisation pattern

• Graphics card near maximum, processor with headroom to spare. The graphics card is the limit, and this is the condition to aim for, because it answers to settings and resolution.
• Processor loaded, graphics card well under maximum. The processor is the limit and the graphics card is waiting on it.
• Neither near maximum. Something outside the pair is deciding your frame rate — a frame cap in the game or driver, the refresh ceiling of your display, or a stall while the system waits on memory or storage.

Read processor utilisation per core rather than as a total. A game that saturates one core while the others idle reports a comfortable overall figure and is processor-limited regardless.

The two tests that settle it

These beat any overlay, because they change the answer rather than describe it.

• Drop the resolution. If frame rate barely moves, the processor is the limit.
• Drop the graphics settings. If frame rate barely moves, the processor is the limit. If it climbs, the graphics card was.

Both work for the same reason: lowering resolution or settings cuts graphics work per frame while leaving processor work per frame roughly where it was. Remove graphics work from a graphics-limited system and frame rate rises; remove it from a processor-limited one and nothing changes, because the graphics card was already waiting.

What to capture, and for how long

Record during real play, in the scenes that feel worst, across several minutes rather than seconds. A built-in benchmark loop is the wrong instrument: it is built to load the graphics card evenly, which is the condition under which a processor limit disappears. Dense areas, crowds of entities and fast traversal expose one. Vendor overlays, third-party overlays and frame-time loggers all report these numbers; only the loggers give frame times rather than a rolling average.

Then compare what you measured against what we told you:

• If we named your processor, you should see graphics utilisation sitting below maximum, and frame rate that barely responds when you lower graphics settings. The CPU bottleneck calculator goes further into that diagnosis.
• If we named your graphics card, you should see it near maximum, with frame rate that responds immediately to settings and resolution. The GPU bottleneck calculator separates a compute limit from a VRAM one.
• If neither pattern appears, our answer is wrong for your system. Trust your measurement.

Corrections

If a score looks wrong, a part is missing, or a result contradicts your own measurements, tell us and include your parts, resolution and what you measured. Scores are revised when the aggregate evidence says they should be. Reach us at bottleneckcalculatorsio@gmail.com.