STARESBACK.GG
LV 1
0 XP

/// FIELD NOTES FROM A SELF-AWARE GAME SITE

How to Undervolt Your CPU in 12 Steps (2026, 45 Min)

BY·EDITED BYSAM P.·2026-06-17·12 MIN READ·5,592 WORDS
How to Undervolt Your CPU in 12 Steps (2026, 45 Min) — STARESBACK.GG blog

There is a specific category of computing advice that sounds like a scam: do this one thing and your machine will run cooler, draw less power, throttle less, and lose no performance. The retro-gaming corner of the internet is full of such promises, most of them attached to a coupon code. Undervolting is the rare exception. It is not a trick, it is not a tweak, and it is not, contrary to the forum mythology, dangerous in the way overclocking can be. It is the act of telling your CPU to do exactly what it already does, using slightly less voltage to do it.

The reason this works at all is that silicon is conservative. Every chip leaves the fab with a voltage curve that has to keep the worst sample in a production batch stable, across a temperature range, for years, under a warranty. Your specific chip is almost certainly better than that worst-case sample. The factory voltage is a margin of safety you paid for and never use. Undervolting reclaims it. The ArchWiki documentation on undervolting, in its 2025–2026 form, puts it plainly: done correctly, undervolting reduces energy consumption and heat without affecting performance. That last clause is the entire reason this article exists. You are not trading speed for temperature. You are deleting waste.

This is a tutorial, not a sales pitch, so here is the catch up front: "done correctly" is carrying weight in that sentence. An undervolt that is too aggressive does not gently degrade. It crashes. It blue-screens mid-boss-fight, it corrupts a save, it freezes a RetroArch netplay session at the worst possible frame. The difference between a free win and an afternoon of frustration is testing methodology, and roughly ninety percent of this guide is about testing methodology. Read it before you touch a voltage slider.

Why Undervolting Works

Power dissipation in a CMOS processor is dominated by the dynamic switching term, which scales with capacitance, frequency, and the square of voltage. That squared relationship is the whole game. A modest voltage reduction produces a disproportionately large drop in power and, because power becomes heat, a disproportionately large drop in temperature. Drop voltage ten percent and you do not save ten percent of power — you save closer to twenty, because the voltage term is squared while the chip continues to clock at the same frequency it always did.

Why does temperature matter to a gamer specifically? Because modern CPUs do not run at a fixed clock. They run at the highest clock they can sustain within a thermal and power budget, and they back off — "throttle" — the instant they exceed it. A cooler chip throttles later and less. On a thermally constrained laptop running an emulator that hammers a single core, or a small-form-factor handheld running a demanding core like a Saturn or PS2 emulator, undervolting frequently raises sustained performance, not by overclocking but by keeping the chip out of the throttle ceiling longer. The clock you were promised on the box is the clock you actually get to keep.

The mechanism you adjust is the voltage offset — a negative number, expressed in millivolts (mV), subtracted from whatever voltage the chip would otherwise request at every point on its frequency-voltage curve. You do not pick a single fixed voltage. You shift the entire curve down by a constant. At idle the chip still drops to low voltage; under load it still ramps up; the whole staircase simply sits a little lower than before. This is why a well-chosen undervolt is invisible in benchmarks and obvious on a temperature graph.

One terminology note that trips up newcomers: on Intel, the two offsets that matter most are CPU Core and CPU Cache (sometimes labeled "CPU" and "CPU Cache" or "core" and "ring/LLC"). The well-worn advice from the UltrabookReview ThrottleStop guide is that these two should generally carry the same undervolt value — set Core to −80 mV, set Cache to −80 mV — because mismatched values are a common and maddening source of instability. On AMD's Ryzen platform the equivalent control is the Curve Optimizer, which expresses the offset in abstract "counts" rather than millivolts, but the principle is identical: shift the curve down, test, repeat.

Prerequisites: Hardware and Software

Undervolting is platform-specific. There is no single button. What you install and where you click depends on your CPU vendor, your generation, and your operating system. Sort yourself into the correct lane before you download anything.

Hardware requirements. You need to know your exact CPU. Not "an i7" — the specific SKU, e.g. Core i7-9750H, Core Ultra 7 265K, Ryzen 7 9800X3D, Ryzen 7 7840U. The generation determines both your method and your realistic headroom. Critically, Intel disabled voltage-offset control on most 10th-generation and many later mainstream desktop chips via the Plundervolt mitigation (a 2019 security fix for a real vulnerability). If you own one of those, software undervolting through the offset interface simply will not take, and your only path is BIOS-level control if the board exposes it. Older 6th- through 9th-generation Intel mobile chips, and the new Core Ultra / LGA 1851 desktop platform, are the most cooperative. On AMD, essentially all Zen-based Ryzen chips from Zen 2 onward support Curve Optimizer through BIOS or through Ryzen Master.

Software, by lane:

Stability-testing software (all lanes). This is not optional and it is not where you cut corners. ArchWiki specifically recommends stress tests that perform numerical checks — that is, tests that verify their own math and will catch a silently wrong calculation that a simple load test would miss. It names mprime (the Linux/cross-platform build of Prime95) and linpack as the preferred tools. On Windows you want Prime95 (Small FFTs torture test), and for a broader real-world net, Cinebench and 3DMark. The Ryzen laptop guide explicitly recommends testing with 3DMark, Prime95, and Cinebench together, because each stresses the chip differently and a stable system survives all three.

Time and conditions. Budget 45 minutes for a first conservative pass. Budget several hours, spread across days, for a fully validated daily-driver undervolt — because the only honest stability test is one that runs long. Do this on a machine where a crash costs you nothing: close your work, save your games, and accept that you will crash at least once. That crash is data, not failure.

The Procedure: 12 Numbered Steps

This is the platform-agnostic skeleton. The vendor-specific sections that follow fill in the exact clicks. Every step has a reason, because a step you do not understand is a step you will skip, and the one you skip is the one that bites you.

  1. Identify your exact CPU and confirm it supports undervolting. Rationale: the Plundervolt mitigation silently disables offset control on a large swath of Intel chips. Five minutes spent confirming support saves an hour spent wondering why nothing changes.
  2. Record a baseline. Before changing anything, run your stress test for 10 minutes at stock voltage and write down peak temperature, peak package power (watts), and sustained clock speed. Rationale: "it runs cooler" is meaningless without a before number. This is your control.
  3. Set up live monitoring. Open HWiNFO64 (Windows) or watch sensors / turbostat (Linux) on a second screen or window. Rationale: you must see voltage and temperature change in real time, or you are flying blind.
  4. Apply a conservative first offset. Intel: −80 mV on CPU Core, the same −80 mV on CPU Cache. AMD: Curve Optimizer −10 (negative) all-core. Rationale: −80 mV on Intel and −10 on AMD are the broadly compatible starting points recommended across the 2026 guide material. Conservative first, aggressive never.
  5. Apply temporarily, not permanently. Do not save to BIOS or enable any persistence/service yet. Keep the offset live-only so a crash clears it on reboot. Rationale: a permanent bad undervolt that crashes on boot is a recovery problem; a temporary one is a non-event.
  6. Run a short stability test (15–20 minutes). Prime95 Small FFTs or mprime with numerical checks enabled. Rationale: most unstable undervolts fail within the first few minutes of a numerical-check load. This pass weeds out the obviously-too-aggressive.
  7. Compare against baseline. Confirm temperature and power dropped and clock speed did not. Rationale: if performance fell, you have done something other than undervolt — likely tripped a power limit — and must investigate before going further.
  8. Step deeper in small increments. If stable, drop another −10 to −25 mV (Intel) or another −5 on Curve Optimizer (AMD) and retest from step 6. Rationale: the failure point is found by walking up to the edge, then stepping back, never by jumping.
  9. Find the failure point, then back off. When a value crashes or errors, that is your floor. Your daily setting is one comfortable step above the floor, not at it. Rationale: a setting that barely passes a 20-minute test will fail a 6-hour gaming session. The margin is the point.
  10. Run the long stability test (several hours). At your chosen daily value, run mprime/Prime95 for hours, ideally overnight, plus a real workload — the actual emulator or game you care about. Rationale: short tests catch gross instability; only long tests catch the once-an-hour rounding error that corrupts a save file.
  11. Make it persistent. Only now: save to BIOS, enable intel-undervolt.service, or set ThrottleStop to start with Windows. Rationale: persistence is the reward for proven stability, not a step you take on faith.
  12. Document your settings. Write down every value in a text file kept with your backups. Rationale: a BIOS reset, a Windows reinstall, or a CMOS-clear erases everything, and you do not want to re-derive your floor from scratch. The complete-configuration section at the end is your template.

Intel on Windows: ThrottleStop

ThrottleStop is the canonical Windows tool for Intel mobile and older-desktop undervolting, and despite a UI that looks like it escaped from 2009, it remains the most precise instrument in the category. The UltrabookReview guide is the reference text, and its core advice is worth tattooing somewhere visible: CPU Core and CPU Cache should generally carry the same undervolt, and you should test stability thoroughly before saving the voltages permanently.

The relevant controls live behind the FIVR button (Fully Integrated Voltage Regulator). The interface looks intimidating; you touch exactly two things. Select CPU Core in the FIVR Control box, check Unlock Adjustable Voltage, and set the Offset Voltage negative. Then select CPU Cache and set the identical offset. Here is the conceptual configuration you are building — not a file you edit, but a mental model of the two values:

; ThrottleStop FIVR — conceptual settings (set via the GUI)
; ------------------------------------------------------------
FIVR Control:
  CPU Core   -> Unlock Adjustable Voltage: ON
               Offset Voltage:  -80.1 mV     ; conservative start
  CPU Cache  -> Unlock Adjustable Voltage: ON
               Offset Voltage:  -80.1 mV     ; MUST match Core

  Intel GPU  -> Offset Voltage:   0.0 mV      ; leave for later
  System Agent -> Offset Voltage: 0.0 mV      ; leave alone

; Click 'Apply' (temporary). Do NOT check 'OK - Save voltages
; immediately when I click OK' until stability is proven.

The starting value is −80 mV on both. From there you walk deeper. The UltrabookReview guide's generational map is the most useful sizing data in this entire field: many modern mobile CPUs tolerate roughly −125 mV to −165 mV, while older 3rd- and 4th-generation Core chips may only manage about −40 mV to −50 mV before they destabilize. Do not read those as targets. Read them as the ceiling of what is plausible, so you know whether your stable result of −110 mV is a great chip or a sign you stopped too early. If you own a Haswell-era laptop and you are sitting stable at −145 mV, you have either won the silicon lottery or your test is too short. It is almost always the latter.

The single most important toggle in the whole tool is the one labeled approximately "OK – Save voltages immediately when I click OK." Leave it off during testing. With it off, an unstable value evaporates on reboot and you simply try again. Turn it on only after the long test in step 10 passes. ThrottleStop also has a per-profile structure and a "Start ThrottleStop in Windows" option in its options page; that is your persistence mechanism (step 11), enabled last.

Intel Core Ultra: BIOS Tuning

The new Intel desktop platform — Core Ultra on LGA 1851 — moves the action into the motherboard BIOS, and pairs undervolting with power-limit and ratio tuning in a way the older mobile workflow did not. The 2026 Core Ultra / LGA 1851 guide frames the upside aggressively, claiming users can extract 20–30% more performance alongside better temperatures through combined BIOS tuning — a figure that reflects power-limit headroom being unlocked as much as voltage being lowered. Treat 20–30% as a best-case marketing-adjacent number, not a guarantee, but the direction is real: on this platform, undervolting is part of a tuning package, not a standalone trick.

First, get into Advanced Mode. As noted, BIOS access varies by vendor: the guide cites F6 on ASRock and F7 on MSI. Other boards use Del to enter setup and then a key or click to reach Advanced. Once inside, two ideas matter.

Voltage offset entry, divided by 1,000. A recurring confusion on these boards is how the offset field expects its input. The Core Ultra guide's creator recommends entering a value divided by 1,000 — that is, the UI takes a volt-denominated number where a −0.080 entry means −80 mV. This is simply how many motherboard firmwares express a millivolt-style input, and getting the decimal place wrong by a factor of a thousand is how people accidentally request an offset that either does nothing or instantly kills the boot. Read your specific field's units carefully.

All-core ratio reduction for temperature. Beyond voltage, the guide suggests lowering all-core CPU ratios by about 100 MHz from stock for materially better temperatures, using concrete example values of 54 for P-cores and 46 for E-cores. Dropping one multiplier bin costs a sliver of peak clock you will never notice in an emulator and buys a meaningful thermal cushion. Here is the conceptual BIOS configuration:

# Intel Core Ultra / LGA 1851 — BIOS Advanced Mode (conceptual)
# Enter Advanced: ASRock = F6, MSI = F7

CPU Voltage Offset Mode .............. Adaptive + Offset
CPU Core Voltage Offset .............. -0.080   # = -80 mV (value / 1000)
CPU Cache (Ring) Voltage Offset ...... -0.080   # match the core

P-Core Ratio (all-core) .............. 54       # ~100 MHz under stock
E-Core Ratio (all-core) .............. 46       # ~100 MHz under stock

Long Duration Power Limit (PL1) ...... tune to cooler capability
Short Duration Power Limit (PL2) ..... tune to cooler capability

# Save & Exit, then validate in Windows before trusting it.

The BIOS path has one ergonomic disadvantage versus ThrottleStop: a bad value that crashes during POST means a trip to clear CMOS rather than a simple reboot. Locate your board's CMOS-clear jumper or button before you start, so an unbootable setting is a thirty-second fix and not a panic.

Linux: intel-undervolt

On Linux, the intel-undervolt tool is the documented path, and the ArchWiki workflow is the canonical reference. The tool is open source; the upstream project lives at github.com/kitsunyan/intel-undervolt, which is also where the configuration syntax is documented in full. Configuration lives in /etc/intel-undervolt.conf.

ArchWiki's sizing guidance for Linux mirrors the Windows numbers but states them as a range: for Intel CPU and CPU Cache, a reduction of about 100 mV to 200 mV is often stable, while going beyond 200 mV may crash the system or simply have no effect. The "no effect" outcome is the chip clamping the offset internally — a sign you have exceeded what the silicon will accept, not a sign to push harder. Edit the config to set your offsets:

# /etc/intel-undervolt.conf
# Negative offsets, expressed in millivolts.
# Start conservative; ArchWiki: 100-200 mV often stable, >200 may crash.

enable        no            # flip to 'yes' once a value is proven

# undervolt   <value>
undervolt 0 'CPU'        -80
undervolt 1 'GPU'         0
undervolt 2 'CPU Cache' -80    # match CPU
undervolt 3 'System Agent' 0
undervolt 4 'Analog I/O'   0

# Optional power-limit tuning (watts / seconds); leave default at first.
# power package 28 35</code></pre><p>Apply and verify with the two commands ArchWiki documents. You <code>read</code> to confirm what the kernel currently reports, and <code>apply</code> to push your config:</p><pre><code>$ sudo intel-undervolt apply
$ sudo intel-undervolt read</code></pre><p>Expected output from <code>intel-undervolt read</code> looks approximately like this — your exact baseline voltages will differ, but the structure is what you confirm:</p><pre><code>CPU                 (0): -80.08 mV
GPU                 (1):  0.00 mV
CPU Cache           (2): -80.08 mV
System Agent        (3):  0.00 mV
Analog I/O          (4):  0.00 mV
Powerlimit short term: 35.00W in 0.00244140625s (enabled)
Powerlimit long term:  28.00W in 28.00s (enabled)
Current VID: 0.7314 V
Current temperature: 47 C
Temperature target:  100 C (0 offset)</code></pre><p>The values reading back at roughly your requested −80 mV confirm the offset took. If they read 0.00 after an apply, the chip rejected the offset — likely a Plundervolt-mitigated SKU. To make the undervolt survive reboot, ArchWiki points to the systemd unit: enable <code>intel-undervolt.service</code> and the settings reapply automatically at every boot.</p><pre><code>$ sudo systemctl enable --now intel-undervolt.service
$ systemctl status intel-undervolt.service
  ● intel-undervolt.service - Apply intel-undervolt settings
     Loaded: loaded (/usr/lib/systemd/system/intel-undervolt.service; enabled)
     Active: active (exited) since ...</code></pre><p>As with every platform, enable persistence <i>last</i>, after the long stability test. A persistent undervolt that crashes the boot is recoverable on Linux — boot a live USB, edit the conf back to <code>enable no</code> — but it is far better to never need the recovery.</p><h2 id="amd-curve-optimizer">AMD AM5: Curve Optimizer</h2><p>AMD's Ryzen platform does not use a flat millivolt offset. It uses the <b>Curve Optimizer</b>, a per-frequency adjustment built into Precision Boost Overdrive (PBO) that shifts the voltage-frequency curve by abstract "counts." On AM5 desktop boards this lives in the BIOS under PBO; in Windows it is also reachable through Ryzen Master. The <a href="https://www.youtube.com/watch?v=8p6XDbNcOEw&vl=en" rel="noopener">2026 AMD AM5 Ryzen guide</a> sets the framing: the Curve Optimizer should be set to <b>negative</b> (negative counts = lower voltage = the goal), and you should <b>stress test in Windows before finalizing</b>.</p><p>That same guide gives voltage targets in actual volts as a sanity anchor: a common starting point lands around <b>1.20 V</b>, and if you are prioritizing temperature over absolute boost, <b>1.05–1.10 V</b> is the cooler-running zone. You do not type those voltages directly — you dial Curve Optimizer counts until your monitored load voltage lands in that neighborhood. A useful rule of thumb is that each negative count is worth a few millivolts, so reaching the 1.05–1.10 V band from stock typically means a sizable negative all-core value, found by the same incremental walk used everywhere else in this guide.</p><pre><code># AMD AM5 — BIOS: Precision Boost Overdrive menu (conceptual)

Precision Boost Overdrive ............ Advanced
PBO Limits ........................... Motherboard (or Manual)

Curve Optimizer ...................... All Cores
  Sign ............................... Negative
  Magnitude (all-core) ............... 10        # conservative start

# Target observed load voltage (verify in HWiNFO / Ryzen Master):
#   ~1.20 V          -> balanced starting point
#   ~1.05 - 1.10 V   -> temperature-priority zone

# Stress test in Windows BEFORE saving as your daily profile.</code></pre><p>AMD adds a wrinkle Intel does not: not every core is equally good. The best-binned cores tolerate deeper negative counts; the weakest core sets your all-core limit. Advanced users go per-core (the advanced-tips section covers this), but start all-core and uniform. AMD's instability signature is also distinct and devious — a too-aggressive Curve Optimizer often passes heavy all-core load tests and then fails at <i>idle or light load</i>, because the deepest part of the curve (low frequency, where the offset is proportionally largest) only gets exercised when the chip is barely working. This is why an AMD undervolt that survives Prime95 can still crash you on the Windows desktop an hour later, and why the idle-stability check is non-negotiable on this platform.</p><h2 id="stress-testing">Stress Testing for Stability</h2><p>This is the section that separates a free win from a corrupted save file. Everything above is the easy part. Validation is the discipline.</p><p>The governing principle, straight from ArchWiki, is to use tests with <b>numerical checks</b> — tests that compute a known answer and verify they got it right — and it names <b>mprime</b> and <b>linpack</b> as the preferred tools. The reason is specific: an undervolt failure is frequently not a crash but a <i>silent miscalculation</i>. The chip stays up, the game keeps running, and one arithmetic operation in ten billion returns the wrong bit. A load test that only watches for hangs will declare that stable. A numerical test catches the wrong bit and reports a worker failure. That distinction is the entire reason this hobby has a reputation for occasionally eating data, and the entire reason you use the right tools.</p><p>On Linux, run mprime in torture mode and let it police itself:</p><pre><code># mprime torture test (Linux) — Small FFTs stress the CPU/cache hardest
$ ./mprime -t
# Choose: Small FFTs, run until manually stopped.
# A failed worker prints an error like:
#   FATAL ERROR: Rounding was 0.5, expected less than 0.4
#   Hardware failure detected, consult stress.txt file.
# That message = your undervolt is too aggressive at this value.

# Watch temps and clocks in another terminal:
$ watch -n1 sensors
$ sudo turbostat --interval 1</code></pre><p>The error message above is what success-of-the-test looks like when your voltage is wrong: mprime catches the rounding error and tells you. On Windows, the equivalent is <b>Prime95</b> with the <b>Small FFTs</b> torture test, which produces an analogous "rounding was X, expected less than Y" worker error. The Ryzen laptop guide's recommendation to test with <b>3DMark, Prime95, and Cinebench</b> together is sound layering: Prime95 finds arithmetic instability, Cinebench validates a realistic all-core render workload, and 3DMark exercises the CPU-GPU interaction a pure CPU test never touches.</p><p>Three rules make stress testing actually work:</p><ul><li><b>Test long.</b> Twenty minutes proves nothing about an eight-hour gaming session. A value is "daily stable" only after hours of clean numerical-check load, ideally an overnight run. The instability that matters most appears least often.</li><li><b>Test the real workload.</b> Synthetic tests are necessary, not sufficient. After the synthetic passes, run the actual thing — the PS2 emulator, the RetroArch run-ahead session, the Saturn core — for a full evening. Your workload's specific instruction mix may stress the chip in ways Prime95 does not.</li><li><b>Test idle, especially on AMD.</b> Leave the machine at the desktop, lightly loaded, for an hour. Curve Optimizer failures love low load. A reboot, a few browser tabs, and patience catch what torture tests miss.</li></ul><p>Expected healthy output, conceptually, is undramatic: temperatures several degrees below your baseline, package power down by a meaningful margin, sustained clocks <i>identical</i> to stock, and zero worker errors across hours. If you got cooler and slower, you tripped a power limit, not an undervolt — diagnose before proceeding. If you got cooler and stable and same-speed, congratulations, you have done the thing correctly and there is no catch.</p><h2 id="pitfalls">Common Pitfalls and Fixes</h2><p>Every one of these has a body count in the support forums. Read them as a pre-flight checklist.</p><ol><li><b>Mismatched Core and Cache offsets (Intel).</b> The single most common mistake. People undervolt CPU Core to −120 mV, leave CPU Cache at 0, and chase phantom instability for a week. <i>Fix:</i> set Core and Cache to the same value, as the UltrabookReview guide insists. If you must differ them, do it only after both are independently proven.</li><li><b>Confusing the temporary and permanent toggles.</b> Saving the undervolt to BIOS or enabling persistence before testing means a bad value crashes on every boot. <i>Fix:</i> apply temporarily during all testing — ThrottleStop's save-voltages box off, <code>intel-undervolt.conf</code> still at <code>enable no</code> when iterating, BIOS values entered but mentally flagged as unproven — and persist only after the long test passes.</li><li><b>Testing too briefly.</b> A 10-minute pass that "works" and then corrupts a save three hours into a session. <i>Fix:</i> run hours of numerical-check load plus a real-workload evening before you trust a value. Short tests find gross failures; only long tests find the rare ones, and the rare ones are the dangerous ones.</li><li><b>Using a load test without numerical checks.</b> A tool that only watches for hangs will pass a silently-miscalculating undervolt. <i>Fix:</i> use mprime/Prime95 Small FFTs or linpack, exactly as ArchWiki specifies, so wrong answers get caught and reported.</li><li><b>Going too deep too fast.</b> Jumping straight to −150 mV because a forum post said their chip did it. Their chip is not your chip. <i>Fix:</i> start at −80 mV (Intel) or −10 (AMD), step in small increments, find the failure point, and back off one comfortable step. The number that matters is <i>your</i> floor, not someone else's.</li><li><b>Forgetting AMD's idle-load failure mode.</b> Passing Prime95 and then crashing at the desktop. <i>Fix:</i> always include a light-load and idle soak in AMD testing, because the deepest, most fragile part of the Curve Optimizer curve only activates at low frequency.</li><li><b>Wrong decimal place in BIOS voltage entry.</b> On boards that take a divided-by-1000 value, typing −80 instead of −0.080 requests an offset a thousand times too large (instant non-boot) or too small (no effect). <i>Fix:</i> read the field's units, confirm with a monitoring tool that the applied offset matches intent, and know where your CMOS-clear is.</li><li><b>Blaming the undervolt for unrelated crashes.</b> Once undervolted, every future crash gets attributed to voltage, sending you on pointless re-tuning chases. <i>Fix:</i> when something crashes weeks later, first revert to stock and reproduce. If it still crashes at stock, the undervolt is innocent and you have a different problem.</li></ol><h2 id="troubleshooting">Troubleshooting Table</h2><table><thead><tr><th>Symptom</th><th>Likely Cause</th><th>Fix</th></tr></thead><tbody><tr><td>Offset applies but read-back shows 0.00 mV</td><td>Plundervolt mitigation on the CPU (common 10th-gen+ Intel) blocking the offset interface</td><td>Confirm SKU support; if blocked, use BIOS-level control where the board exposes it, or accept that software offset is unavailable</td></tr><tr><td>System crashes / freezes under load</td><td>Undervolt too aggressive for sustained load</td><td>Reduce magnitude by 10–25 mV (Intel) or 3–5 counts (AMD) and retest from the short test</td></tr><tr><td>Stable under Prime95, crashes at idle (AMD)</td><td>Curve Optimizer too deep at low frequency</td><td>Reduce negative count; add a mandatory idle/light-load soak to your test plan</td></tr><tr><td>mprime/Prime95 reports "rounding was X, expected less than Y"</td><td>Silent miscalculation — undervolt unstable but not crashing</td><td>This is the test working. Back off one increment until zero worker errors across hours</td></tr><tr><td>Temps dropped but clock speed dropped too</td><td>You hit a power limit (PL1/PL2 or PPT), not an undervolt benefit</td><td>Investigate power limits separately; an undervolt alone should never lower sustained clocks</td></tr><tr><td>Settings lost after reboot</td><td>Persistence never enabled, or applied only temporarily</td><td>After proving stability: enable intel-undervolt.service, ThrottleStop-at-startup, or save the BIOS profile</td></tr><tr><td>No measurable change after applying any offset</td><td>Offset exceeds what silicon accepts (ArchWiki: >200 mV may have no effect) or interface is locked</td><td>Return to a smaller value (100–200 mV range) and verify with the tool's read command</td></tr><tr><td>Machine won't POST after a BIOS undervolt</td><td>Bad value saved to firmware</td><td>Clear CMOS (jumper or button), re-enter BIOS, apply a smaller offset, validate in OS before saving again</td></tr><tr><td>Crashes appeared weeks after a stable undervolt</td><td>Possibly unrelated (drivers, RAM, storage) — undervolt wrongly blamed</td><td>Revert to stock and reproduce; if it still crashes, the undervolt is not the cause</td></tr></tbody></table><h2 id="advanced-tips">Advanced Tips</h2><p>Once you have a stable, documented baseline, there are several deeper moves — each optional, each with a cost-benefit worth understanding before you bother.</p><p><b>Per-core Curve Optimizer (AMD).</b> The all-core value is limited by your single weakest core. If you profile each core's stability individually, you can run the strong cores deeper and only hold the weak one back, squeezing out extra average undervolt. This is hours of tedious per-core testing for a marginal gain, and it only matters if you are chasing the last few degrees. For most gaming use, all-core is plenty.</p><p><b>Pair undervolting with power-limit tuning.</b> On the Core Ultra platform especially, the 2026 guide's 20–30% performance framing comes from combining a voltage offset with raised or rebalanced power limits and the ~100 MHz all-core ratio reduction (54 P-core, 46 E-core). The undervolt buys thermal headroom; the power-limit tuning spends that headroom on sustained clocks. Done together on a well-cooled chip, the sum genuinely exceeds the parts. Done together on a thermally limited laptop, you can give back the temperature win you just earned — so monitor, do not assume.</p><p><b>Undervolt the iGPU and System Agent separately.</b> Both ThrottleStop and intel-undervolt expose GPU and System Agent offsets. On a handheld or laptop running emulation on integrated graphics, a modest iGPU undervolt extends battery and lowers fan noise. Treat these as a separate tuning pass with their own stress test (a GPU load like 3DMark or a graphically heavy core), because GPU instability has its own crash signature and conflating it with CPU testing muddies your results.</p><p><b>Season your settings.</b> Silicon degrades very slowly over years, and ambient temperature shifts between a winter desk and a summer one. A value that was rock-solid in January can develop a once-a-week wobble in August heat. If you live near your floor, you will eventually have to back off a notch. The fix is the margin you built in step 9 — another argument for never running at the bleeding edge of stability.</p><p><b>Keep a recovery plan.</b> Know your CMOS-clear method, keep a Linux live USB handy if you persist via systemd, and store your documented config with your backups. The whole appeal of undervolting is that it is low-risk; it stays low-risk only if a bad value is always a thirty-second recovery and never a mystery.</p><h2 id="final-config">Complete Working Configuration</h2><p>Here is a complete, conservative, validated-style reference configuration across all platforms. These are sane starting points and a documentation template — not values to apply blindly, because your specific chip's floor is yours to discover. Copy the block for your platform, fill in your tested values, and keep it with your backups.</p><pre><code># ============================================================
# UNDERVOLT REFERENCE CONFIG — STARESBACK.GG
# CPU: __________________   Date tuned: __________
# Baseline (stock):  peak temp ____C  | pkg power ____W | clock ____GHz
# Final (undervolt): peak temp ____C  | pkg power ____W | clock ____GHz
# Stable since: ____  | Long test: ____ hours mprime/Prime95, zero errors
# ============================================================

# --- INTEL, WINDOWS (ThrottleStop, set via FIVR GUI) --------
# CPU Core   Offset:  -80.1 mV   (deepen in -10 mV steps)
# CPU Cache  Offset:  -80.1 mV   (MUST equal Core)
# Save-voltages-on-OK: ON  (only after long test passed)
# Start ThrottleStop with Windows: ON
# Generational reality: modern mobile ~ -125 to -165 mV;
#                       3rd/4th-gen Core ~ -40 to -50 mV.

# --- INTEL, LINUX (/etc/intel-undervolt.conf) ---------------
enable        yes              # only after proven stable
undervolt 0 'CPU'        -80
undervolt 1 'GPU'         0
undervolt 2 'CPU Cache' -80
undervolt 3 'System Agent' 0
undervolt 4 'Analog I/O'   0
# Apply:   sudo intel-undervolt apply
# Verify:  sudo intel-undervolt read
# Persist: sudo systemctl enable --now intel-undervolt.service
# ArchWiki range: 100-200 mV often stable; >200 mV may crash/no-op.

# --- INTEL CORE ULTRA / LGA 1851 (BIOS Advanced) ------------
# Enter Advanced:  ASRock=F6, MSI=F7
# CPU Core Voltage Offset:  -0.080   (value / 1000 = -80 mV)
# CPU Cache Voltage Offset: -0.080   (match core)
# P-Core all-core ratio: 54   E-Core all-core ratio: 46
# (~100 MHz under stock for thermals)

# --- AMD AM5 (BIOS: PBO > Curve Optimizer) ------------------
# Curve Optimizer: All Cores, Sign = Negative, Magnitude = 10
# Target observed load voltage: ~1.20 V balanced,
#                               ~1.05-1.10 V temperature-priority
# Deepen in -3 to -5 count steps; ALWAYS soak-test at idle.

# --- VALIDATION CHECKLIST (all platforms) -------------------
# [ ] Short test  : mprime/Prime95 Small FFTs, 20 min, 0 errors
# [ ] Long test   : same, several hours / overnight, 0 errors
# [ ] Real load   : actual emulator/game, full evening, no crash
# [ ] Idle soak   : desktop + light load, 1 hour (critical on AMD)
# [ ] Broad net   : 3DMark + Cinebench pass (Ryzen laptop guide)
# [ ] Persistence : enabled ONLY after all of the above pass
# ============================================================</code></pre><p>That is the entire discipline in one block: conservative start, incremental walk, numerical-check testing, long validation, idle soak, persistence last, documentation kept. Follow it and undervolting delivers exactly what the <a href="https://wiki.archlinux.org/title/Undervolting_CPU" rel="noopener">ArchWiki</a> promises — less heat, less power, no lost performance — with none of the data-loss horror stories that come from skipping the testing. The free win is real. It is just gated behind patience, and patience is the one thing no coupon code can sell you.</p></div>
<section class="bp-faq"><h2>Questions the search bar asks me</h2><dl><dt>Does undervolting reduce performance?</dt><dd>Done correctly, no. ArchWiki's 2025–2026 documentation states undervolting lowers energy use and heat without affecting performance, because you shift the voltage curve down while clocks stay the same. If your clocks drop, you tripped a power limit, not the undervolt.</dd><dt>What's a safe starting undervolt value?</dt><dd>For Intel, the commonly recommended conservative start is −80 mV on CPU Core with a matching −80 mV on CPU Cache. For AMD, Curve Optimizer −10 (negative) is broadly compatible. Step deeper only in small increments after each value passes a stability test.</dd><dt>How aggressive can I realistically go?</dt><dd>It depends on generation. UltrabookReview reports modern mobile CPUs often tolerate −125 to −165 mV, while older 3rd/4th-gen Core chips may only manage −40 to −50 mV. ArchWiki notes 100–200 mV is often stable on Intel, but beyond 200 mV may crash or have no effect.</dd><dt>Which stress tests should I use?</dt><dd>ArchWiki specifically recommends tools with numerical checks — mprime and linpack — because they catch silent miscalculations a plain load test misses. On Windows use Prime95 Small FFTs; the 2026 Ryzen laptop guide adds 3DMark and Cinebench for a broader real-world net. Test for hours, not minutes.</dd><dt>How do I make my undervolt persist after reboot?</dt><dd>Depends on platform. On Linux, enable intel-undervolt.service per ArchWiki. On Intel Windows, set ThrottleStop to start with Windows and enable save-voltages. On AMD AM5 or Core Ultra, save the BIOS profile. In every case, enable persistence only after a multi-hour stability test passes.</dd></dl></section>
<div class="bp-author">
<img src="/authors/img/marcus.png" alt="Marcus Vance — Hardware & Gaming PC Correspondent" width="72" height="72">
<div><b><a href="/authors/marcus">Marcus Vance</a></b>
<div class="role">HARDWARE & GAMING PC CORRESPONDENT</div>
<p>Marcus covers the gaming PC, GPU, and peripheral side of staresback. Every post under this byline is reviewed pre-publish by <a href="/authors/sam">Sam P.</a>, Editor & Operator — corrections to <a href="mailto:info@instalinkoteam.com">info@instalinkoteam.com</a>. Published 2026-06-17 · Last updated 2026-06-17. Full bios on the <a href="/authors/marcus">author page</a>.</p>
</div></div>
<h2 class="bp-relh">MORE FIELD NOTES</h2>
<div class="bp-rels"><a class="bp-rel" href="are-emulators-legal"><b>Are Emulators Legal? The Honest Guide (2026)</b><span>11 MIN READ · BY THE MACHINE</span></a><a class="bp-rel" href="best-nes-homebrew"><b>The 10 Best Free NES Homebrew Games (Playable in Your Browser)</b><span>12 MIN READ · BY THE MACHINE</span></a><a class="bp-rel" href="what-is-homebrew"><b>What Is Homebrew? How Hobbyists Keep Dead Consoles Alive</b><span>10 MIN READ · BY THE MACHINE</span></a></div>
</main>
<div class="toasts" id="toasts" aria-live="polite"></div>
<footer class="foot"><p class="foot-quote">Reading material curated by something that reads everything.</p><nav class="foot-nav mono" aria-label="Site footer"><a href="/">HOME</a><a href="/arcade">THE CABINET</a><a href="/games">ALL GAMES</a><a href="/blog/">BLOG</a><a href="/legal-roms">WHY IT’S LEGAL</a><a href="/forum">FORUM</a><a href="/account">ACCOUNT</a><a href="/about">ABOUT</a><a href="/authors/">AUTHORS</a><a href="/editorial-policy">EDITORIAL POLICY</a><a href="/legal">LEGAL</a><a href="/legal#dmca">DMCA</a></nav><div class="foot-meta mono"><span>EDITED BY <a href="/authors/sam">SAM P.</a> · WRITTEN BY <a href="/authors/machine">THE MACHINE</a></span><span>CONTACT <a href="mailto:info@instalinkoteam.com">info@instalinkoteam.com</a></span><span>100% AUTHOR-SANCTIONED LEGAL HOMEBREW · NO COMMERCIAL ROMS · © 2026 STARESBACK.GG</span></div></footer>
<script src="../core.js?v=9"></script>
</body>
</html>