CPU Undervolting 2026: -50mV in 12 Steps, 60 Min

Overclocking asks a question no engineer at AMD or Intel wants you to ask out loud: how much voltage will this chip tolerate before it dies? Undervolting asks the polite inverse — how little voltage does this chip actually need? — and the answer, on very nearly every modern CPU, is less than the factory gave it. The gap between what your specific silicon needs and what the whole product bin was promised is not a defect. It is deliberate insurance, paid for in watts and degrees, and undervolting is the disciplined art of repossessing it.

This guide is written for the person who wants the gains without the folklore. We will do it in twelve steps, in roughly an hour of hands-on work (the stress testing that validates it runs longer, and we will be honest about that), and we will cover both camps: AMD's Precision Boost Overdrive with Curve Optimizer, and Intel's negative voltage offset. Along the way we will meet a Windows error log that behaves like a black-box flight recorder, a Linux MSR that returns zero because of a 2019 security disclosure, and the single equation that makes the entire practice make sense.

Undervolting in 2026: The Free Lunch

Economists like to say there is no free lunch. Economists do not tune CPUs. Undervolting, applied correctly, is the closest thing PC hardware offers to a coupon: it costs nothing, voids nothing, and on a boost-limited chip it frequently hands back performance as a tip. You are not pushing voltage up the electromigration curve toward an early grave. You are pulling it down, which is the direction the silicon does not mind at all.

What you actually get

Three outcomes, in descending order of reliability. First, lower temperatures — the most dependable result, because you have directly attacked the term in the power equation that matters most. Second, lower power draw and quieter fans, which follow from the first as night follows day. Third, and least guaranteed, higher sustained performance, because Precision Boost and Turbo spend their entire lives colliding with limits; move the voltage wall back and they walk a little further before they stop.

On a desktop the performance bump is a bonus and the quiet is the prize. On a laptop or a handheld it inverts: the same tuning that shaves a handful of degrees off a tower can add genuine frames to a Ryzen mobile part that is strangling itself inside a fifteen-watt envelope. That is why 2026 saw a surge of interest in undervolting from the portable-gaming crowd, who discovered that efficiency and frame rate are, on power-starved silicon, the same lever.

Why it isn't overclocking's evil twin

Overclocking and undervolting share a dashboard but not a risk profile. Overvolting is the dangerous direction; it accelerates aging and, taken far enough, kills transistors. Undervolting through a sanctioned interface — Curve Optimizer, a BIOS offset, Intel's Extreme Tuning Utility — moves voltage the safe way. You will not wear the chip out by giving it less to push. If anything you buy it a longer life at lower temperature. Think of it as the well-read, law-abiding sibling to the GPU overclocking ritual we walked through in twelve steps: same instruments, opposite sign, a fraction of the stakes.

The one honest risk

Instability — and not the courteous, blue-screen kind. Starve a core of a few millivolts too many and it will not always crash. It may compute exactly one wrong bit, write it to memory, and carry on as though nothing happened. A corrupted archive here, a single mangled pixel in a render there, a Windows Hardware Error Architecture event quietly logged while the operating system patches over the damage. That silent-corruption failure mode is the entire reason this guide spends as much time on stress testing as on settings. If it sounds paranoid, hold the thought: the physics that makes a sloppy undervolt corrupt your data is a documented attack technique, and it carries the identifier CVE-2019-11157. We will come back to it.

The Physics: Why V² Is the Whole Game

You do not need a semiconductor degree to undervolt, but you do need one equation, and the moment you internalise it the whole practice stops feeling like witchcraft and starts feeling like accounting. Dynamic power in a CMOS processor is approximately P = α · C · V² · f — an activity factor times capacitance times voltage squared times frequency. Everything that makes undervolting worthwhile lives in that little exponent sitting on the V.

Dynamic power scales with the square of voltage

Frequency enters the equation linearly. Voltage enters it squared. That asymmetry is the whole trick. Shave voltage by five percent while holding frequency constant and dynamic power falls by roughly ten. Heat is power, and temperature is heat losing an argument with your cooler, so the voltage knob is by a wide margin the most thermally efficient control on the die. Overclockers push frequency and pay for it in voltage and heat quadratically; undervolters do the reverse and get paid quadratically. This is not a marketing framing invented for a spec sheet — it is arithmetic that has been true since the first CMOS gate switched.

The silicon lottery and the guardband

So why is there any margin to reclaim? Because no two dies are identical, and the fab cannot test yours specifically against the next five years of its own aging. When AMD or Intel sets the stock voltage-frequency curve, they set it to guarantee stability for the worst acceptable die in the bin, under worst-case conditions, after years of drift. Your particular chip is almost never that worst-case die. The delta between the voltage your silicon truly needs and the voltage the curve promises the entire bin is called the guardband, and it is exactly what you are taking back. Win the silicon lottery and there is a lot of it; lose and there is less. This is also why nobody honest can hand you a single magic number — your neighbour's rock-stable offset may refuse to POST on your board, and the reverse is just as true.

Boost algorithms spend your voltage headroom

The last piece explains how undervolting adds performance instead of merely subtracting heat. Modern CPUs do not run a fixed clock; they boost opportunistically, raising frequency until they hit the first of several ceilings — a temperature limit, a power budget (AMD's PPT, Intel's PL1/PL2), or a current limit (AMD's TDC and EDC, Intel's ICCMAX). AMD arbitrates this continuously through an on-die reliability monitor and a digital low-dropout regulator that trades voltage for frequency in real time; Intel does its own flavour through Turbo. Undervolt, and every one of those ceilings is reached later, because the chip now makes less heat and draws less current at any given clock. The boost algorithm notices the slack and spends it on frequency. That is the mechanism behind "free performance," and it is strongest precisely where desktop chips spend most of their lives — light, one-or-two-thread loads — and where a thermally cramped laptop lives permanently. If you want to watch thermal budget dictate real-world frames on portable silicon, our 2026 gaming-laptop breakdown is the same story told through a chassis instead of a curve.

Prerequisites: Hardware, Software, Versions

Undervolting punishes improvisation. Assemble the tools, pin the versions, and learn your escape hatch before you change a single value. Everything below is what you actually need in mid-2026.

Hardware you need

On the AMD side, any Ryzen from Zen 2 onward technically exposes Precision Boost Overdrive, but Curve Optimizer — the per-core undervolt that makes the whole exercise worthwhile — arrived with Zen 3 and is at its best on Zen 4 and Zen 5. You need a motherboard that genuinely surfaces PBO, which in practice means a B- or X-series chipset; budget A-series boards routinely bury or lock it. On the Intel side this guide targets 12th-gen Alder Lake and newer, for reasons that turn into a short security lecture below. You want a Z-series board — Z690, Z790, Z890 — because full voltage control and Intel XTU expect it; locked H- and B-boards, and the overwhelming majority of OEM laptops, will simply refuse the offset. In both camps you need a cooler competent enough to survive a stock stress test without an immediate thermal shutdown, because your entire method is measurement against a stock baseline. If the baseline is invalid, so is everything downstream.

Software and exact versions

Do not start until these are installed and identified by version:

• HWiNFO64 v8.x — the monitoring backbone. Over a thousand sensors, per-core voltage/clock/temperature, a running WHEA counter, and (recent builds) CSV, JSON and YAML logging. Get it from hwinfo.com and nowhere else.
• AMD Ryzen Master 3.1.0.x — first-party, with Curve Optimizer controls and a built-in stress test; current builds add Ryzen 9000 and the AM5 platform. Read the official Curve Optimizer documentation before you touch it.
• Intel Extreme Tuning Utility (XTU) — version 7.14.x for 14th-gen and older (7.14.2.93 shipped July 2026), version 10.0.x for Core Ultra Series 2 (10.0.1.45, March 2026). Download only from the official Intel XTU page; full tuning still requires a Z-chipset.
• Cinebench 2026 — Maxon's January 2026 release, rebuilt on the Redshift core with the Clang 19 compiler. It renders the same multi-threaded scene about thirteen percent faster than the 2024 build and posts scores roughly three times higher, which are not comparable to 2024. Grab it from Maxon and pick one version for the whole session.
• A real stress tool — OCCT, y-cruncher, or Prime95; and for Ryzen per-core validation, CoreCycler, which is the community standard for catching Curve Optimizer instability the way nothing else can.
• (Linux) RyzenAdj for APU power tuning, intel-undervolt (or georgewhewell's undervolt) for Intel MSR work, plus lm-sensors and mcelog or journalctl for error monitoring.

The twenty-minute reading assignment

Before you change anything, do three boring things. Learn how to clear CMOS on your exact board — the jumper, the rear button, or pulling the coin cell — because you will fail to POST at least once, and a dead boot with no rehearsed recovery turns a fun evening into a two-in-the-morning panic. Save a BIOS profile of your working stock configuration so you always have a one-keystroke road home. And take a baseline snapshot in HWiNFO at stock, running Cinebench 2026 multi-core, so you have honest numbers to judge every later change against. Here is what a stock snapshot on a modern Ryzen 9 looks like; yours will differ, which is the entire point:

# HWiNFO64 v8.x — Sensors snapshot (EXAMPLE), Ryzen 9, stock, Cinebench 2026 MT
Core VID (max) .............. 1.312 V
CPU Core Voltage (SVI3 TFN) . 1.288 V
CPU Package Power (max) ..... 142.0 W
CPU (Tctl/Tdie, max) ........ 89.4 C
Core Effective Clock (avg) .. 4,975 MHz
WHEA errors (this session) .. 0

The Procedure: 12 Steps to Stable

This is the spine of the whole guide: a platform-agnostic loop that works for Ryzen and Core alike, branching only where the two genuinely diverge. Each step carries its reason, because a step you understand is a step you will not skip at midnight.

1. Update BIOS/AGESA and chipset drivers first. Why: Curve Optimizer behaviour — including how many millivolts a single "count" is worth — changed across AGESA revisions (notably at 1.2.0.5). Newer firmware is more predictable and less likely to fight you. Intel boards likewise ship microcode that changes what offsets are even honoured.
2. Enable your memory profile (EXPO or XMP) and confirm it is stable on its own. Why: you cannot diagnose an undervolt while your RAM is the real culprit. Prove the memory stable first, or every later crash is a coin flip between two variables.
3. Set PBO to Auto/Enabled on AMD — do not force-disable it. Why: Curve Optimizer rides on top of PBO. Disabling PBO throws away the exact boost headroom you are trying to reclaim, which is self-defeating.
4. Establish a baseline. Run Cinebench 2026 multi-core at stock and record the score plus the max package temperature, max Vcore, and average effective clock from HWiNFO. Why: every later change is judged against this one set of numbers. No baseline, no verdict, only vibes.
5. Make exactly one small change. AMD: all-core Curve Optimizer -10. Intel: core offset -0.050 V (or a timid -0.010 V for your first ever attempt). Why: one variable at a time, and a conservative first move so a crash is diagnostic rather than catastrophic.
6. Reboot and re-run Cinebench 2026. Compare score and temperature to baseline. Why: confirm the change actually applied and did not regress the score. A large score drop means you overshot into throttling or silent error-correction, not into free performance.
7. Stress test for ten to fifteen minutes minimum. OCCT or y-cruncher for everyone; CoreCycler additionally for Ryzen. Why: a quick screen catches gross instability before you sink hours into a value that was never going to hold.
8. If stable, step deeper. AMD: another -5 to -10 counts. Intel: toward -0.075 V. Why: this is the refinement loop — descend in small increments until something breaks, then you will know exactly where the edge is.
9. Watch WHEA, not just crashes. Check Event Viewer's WHEA-Logger source and the WHEA counter in HWiNFO. Why: a rising corrected-error count with no blue screen is the earliest warning that you have gone too far. Treat any nonzero count as failure.
10. On any crash, reboot loop, or WHEA storm, back off. AMD: roughly +5 Curve Optimizer counts toward zero. Intel: +0.010 to +0.015 V. Why: return to the last known-good value and add a margin of safety on top, because "just barely stable" is not stable.
11. Long-soak validate. An overnight y-cruncher run or a full CoreCycler pass, plus an idle/light-load test. Why: undervolt instability hides in single-core max-boost and in idle transitions, not only under all-core load. Ten minutes of stability is a hypothesis; eight hours is closer to a proof.
12. Save the BIOS profile and write down your final values. Why: a future BIOS update or an accidental CMOS clear wipes everything, and a written config is your recovery plan. Undocumented tuning is tuning you will do twice.

Use this small table as your scorecard. Fill in the blanks; do not invent the targets — they are directional, because the exact figures depend on your silicon:

Metric	Stock baseline	After undervolt	What it should do
Cinebench 2026 MT score	(record)	(record)	Equal or higher
Max package power (W)	(record)	(record)	Lower
Max core temperature (°C)	(record)	(record)	Lower, often by several degrees
Max Vcore (V)	(record)	(record)	Lower
Avg effective clock (MHz)	(record)	(record)	Equal or higher
WHEA errors (session)	0	0	Must stay 0

The AMD Path: PBO and Curve Optimizer

AMD gave undervolters the best toy in the business and then, with typical understatement, buried it two menus deep. Precision Boost Overdrive raises the power and current ceilings; Curve Optimizer reshapes the voltage-frequency curve underneath them. Used together they are the reason a Ryzen can run cooler and boost higher at the same time.

PBO first, Curve Optimizer second

Precision Boost Overdrive governs three limits: PPT (package power, in watts), TDC (thermal design current, the sustained amperage the VRM delivers), and EDC (electrical design current, the peak). Set PBO to Enabled or Advanced and, on most boards, let the limits sit at Motherboard or Auto to begin with. This does not in itself undervolt anything — it simply stops the chip hitting an artificially low current wall before you have even started. AMD's own reliability logic, the on-die fitness monitor sometimes shortened to FIT, is still in charge of keeping voltages within safe long-term bounds, which is a large part of why Curve Optimizer is safe to play with. Tom's Hardware keeps a clear, current walkthrough of the whole PBO-plus-Curve-Optimizer flow in their Precision Boost Overdrive guide if you want a second pair of eyes on the menus.

Only once PBO is enabled and your EXPO memory profile is proven stable do you touch Curve Optimizer. Start with an all-core negative offset of -10 counts, then step down in smaller increments after each round of stability testing. The all-core approach is the sane default; it is fast, it is forgiving, and it gets you eighty percent of the benefit before you ever consider the per-core rabbit hole.

All-core vs per-core offsets

A Curve Optimizer count is not a fixed voltage. Depending on your AGESA version it is worth somewhere between roughly two and five millivolts, and newer AGESA (from 1.2.0.5 onward) tends toward the lower end of that range. Treat the table below as orientation, not gospel:

Curve Optimizer offset	Approx. voltage (older AGESA)	Approx. voltage (AGESA 1.2.0.5+)
-5 counts	~10-25 mV	Toward the low end
-10 counts	~20-50 mV	Toward the low end
-20 counts	~40-100 mV	Toward the low end
-30 counts	~60-150 mV	Toward the low end

The counterintuitive part of per-core tuning: your best cores — the golden two that boost highest, the ones Windows preferentially schedules to — usually tolerate the least undervolt, because they are already running closest to their own edge. So a well-tuned per-core curve is not uniform; it is deep on the ordinary cores and shallow, sometimes barely negative, on the golden ones. Ryzen Master applies these values live in Windows for fast iteration, while the BIOS is the authoritative, persistent home for your final numbers. A sane starting per-core layout looks like this:

; Precision Boost Overdrive → Advanced
PBO Limits .................. Motherboard
PPT / TDC / EDC ............. Auto (board limits)
PBO Scalar ................. 1X
Max CPU Boost Clock Override  +0 MHz   ; add this LAST, once undervolt is stable
Curve Optimizer ............ Per Core
  Core 0 (golden) .......... -5      ; best booster, least headroom
  Core 1 (golden) .......... -8
  Core 2 ................... -20
  Core 3 ................... -20
  Core 4 ................... -25
  Core 5 ................... -22
  ...remaining cores ....... -20
EXPO Profile ............... Enabled (DDR5-6000, already verified stable)

The gambler's -50, and why you probably shouldn't

Some 2026 video guides, particularly the gaming-focused ones, tell you to skip the timid approach entirely: start at an all-core -50, and if the system crashes, walk it back to -40 or -30. On a genuinely good Zen 4 or Zen 5 sample this can even work. It is also how you spend your Saturday chasing idle crashes that only appear when a single core boosts to its ceiling on an empty desktop. The Machine's recommendation is the boring one: start at -10, step in fives, and let the stress tests tell you where your particular die gives up. You end up in the same neighbourhood as the gambler, minus the reboots and the corrupted archives. For verifying that your BIOS actually applied what you asked — and for per-core tuning beyond a simple all-core value — the SMU Debug Tool lets you read back the values the platform is really using, which is the difference between tuning and guessing.

The Intel Path: Offset and Plundervolt

Intel's route is conceptually simpler — a negative offset on the core voltage — but it comes wrapped in a genuinely interesting piece of security history, and that history decides whether your chip can be undervolted at all.

Offset mode in BIOS or XTU

For 12th-gen and newer parts, the tuning path in 2026 is either the motherboard BIOS or Intel XTU, using a negative core voltage offset rather than any of the crude throttling workarounds of the past. In the UEFI you are looking for an offset or adaptive voltage mode; in XTU it is a core voltage offset field. Start conservative at -0.050 V, stress test, and refine toward -0.075 V if it holds. Do the cache/ring domain separately and more gently. A representative configuration:

# ASUS/MSI-style UEFI → Advanced → Overclocking
CPU Core Voltage Mode ....... Offset (Adaptive + Offset)
CPU Core Voltage Offset ..... -0.075 V   (start at -0.050 V, refine)
CPU Cache/Ring Offset ....... -0.050 V
CPU System Agent Offset ..... Auto
Load-Line Calibration ....... Medium
Long Duration Power (PL1) ... 125 W (spec)
Short Duration Power (PL2) .. 253 W (spec)

# Intel XTU 7.14.x equivalent (14th-gen and older)
Core Voltage Offset ......... -75 mV
Cache Voltage Offset ........ -50 mV

Why 10th-gen and older can't play (MSR 0x150)

Here is the law and the lore in one CVE. In 2019, researchers demonstrated Plundervolt — CVE-2019-11157, CVSS base score 7.9 — a software fault-injection attack that abused the very same voltage-scaling interface undervolters love. By undervolting a core at the precise moment it performed a protected computation, an attacker could flip bits inside Intel's SGX secure enclaves before they were written to memory, defeating the encryption that was supposed to protect them. Your sloppy undervolt corrupting a render and a Plundervolt attack corrupting an enclave are, physically, the same event; only the intent differs.

Intel's December 2019 response was a microcode-and-BIOS update that disabled the software voltage-scaling interface entirely on affected parts — 6th through 10th generation Core, plus Xeon E3 v5/v6 and E-2100/E-2200 — by locking the model-specific register at address 0x150 to its default. On a locked chip, a Linux tool that reads that register with rdmsr 0x150 gets back a flat zero, and any undervolt written to it silently evaporates. This is the real reason 2026 guides draw the line at 12th-gen: on Alder Lake and newer, Intel re-exposes tuning through sanctioned BIOS and XTU offsets rather than the now-bricked MSR path. If your Intel chip is 10th-gen or older with current microcode, no amount of clever software will undervolt it, and every guide promising otherwise is selling you a placebo. You can read the researchers' own writeup at the Plundervolt project site.

E-cores, ring, and the domains that matter

Modern Core parts are not one voltage domain but several. The core offset is the headline, but there is also the cache/ring domain and the System Agent, and on hybrid chips the efficiency cores can carry their own offset separate from the performance cores. The practical order of operations: tune the core offset first because it delivers the most heat and power reduction, then apply a smaller, independent cache offset, and leave System Agent on Auto unless you know exactly why you are touching it — a too-aggressive SA offset destabilises memory in ways that masquerade as a bad RAM overclock and will send you debugging the wrong subsystem for an hour.

Stress Testing and the Refinement Loop

The settings are the easy part. The validation is where undervolting is actually won or lost, because an unstable undervolt does not have the courtesy to announce itself. This section is the difference between a tune you trust and a time bomb.

Quick screen vs long soak

Run a two-tier process. The quick screen — ten to fifteen minutes of OCCT or y-cruncher after every change — catches gross instability cheaply, so you are not investing an evening in a value that dies in the first minute. Then, once you think you have a final number, comes the long soak: an overnight y-cruncher run, a full CoreCycler pass on Ryzen, and a Cinebench 2026 loop to confirm the score did not quietly regress. y-cruncher in particular has become the 2026 favourite for exposing undervolt instability, because its VST and N63 algorithms hammer the CPU in ways ordinary renders do not. Cinebench is your thermal-and-score check, not your stability proof; do not confuse the two.

:: Quick screen (any platform)
y-cruncher.exe   →  Component Stress Tester → VST/N63, 15 min

:: Ryzen per-core Curve Optimizer validation
CoreCycler.bat   →  runs Prime95 single-core, cycles every core at Fmax

Why Ryzen crashes at idle, not full load

Here is the trap that sends first-timers in circles: an all-core load like Cinebench actually makes an undervolt easier to survive, because heavy current draw causes voltage droop that pulls the requested voltage down anyway. The real killer is a single core boosting to its maximum frequency, requesting its highest voltage — which happens at light or idle load, exactly when your negative offset leaves it most starved. This is why a system can pass an hour of Cinebench and then reboot itself while you read email. It is also why CoreCycler exists: it uses Prime95 to pin one core at a time to its boost ceiling, cycling through them all, and it will find the unstable core an all-core test sails right past. Test both extremes — full load and idle — or you have only tested half the problem.

Reading WHEA like a black box recorder

The Windows Hardware Error Architecture log is your flight recorder. Open Event Viewer, filter the System log to the WHEA-Logger source, and watch for Event ID 18 and 19 — corrected machine-check errors. A corrected error means the hardware caught a fault and fixed it before it became a crash; a rising count of them under a light load is the unambiguous signal that your undervolt is too aggressive, even though nothing has blue-screened yet. HWiNFO surfaces the same count as a live sensor. Treat any nonzero value at idle or light load as a failed test and back off. A typical warning looks like this:

--- Windows Event Viewer → System (filter: WHEA-Logger) ---
Level:        Warning
Source:       WHEA-Logger
Event ID:     19
Description:  A corrected hardware error has occurred.
              Error Source: Corrected Machine Check
              Processor APIC ID: 6

That APIC ID is the actionable part: it points at the physical core that failed (roughly APIC ID divided by two on an SMT chip), so you know precisely which core to give a few counts back. On Linux the equivalent is journalctl -k | grep -i mce or mcelog. A machine-check exception is the same event wearing a different uniform.

Linux, Handhelds, and the Emulation Box

This is where a general PC topic circles back to the reason most of you are here: the handhelds and living-room emulation boxes that live or die on thermals and battery. The Linux tooling is different, more honest about its limits, and genuinely useful for retro rigs.

RyzenAdj: power limits, not vcore

On a Linux handheld or emulation box running a Ryzen APU, you rarely get Curve Optimizer at all. What you get is RyzenAdj, and it is important to be precise about what it does: RyzenAdj tunes power and thermal limits — the sustained STAPM limit, the fast and slow package limits, the current limits, and the temperature target — but it does not set core voltage directly on mobile parts. Its own developers are candid that they have not found a way to change voltage on those platforms. So what you are really doing is capping sustained power, which nudges the boost algorithm into requesting less voltage to stay inside the envelope. Call it undervolting by proxy: same destination, different road. On a handheld, that means longer battery, quieter fans, and — crucially for emulation — steadier sustained clocks, so a demanding PS2 or GameCube core does not thermal-throttle mid-session.

# AMD Ryzen APU (handheld / emulation box) — RyzenAdj tunes POWER, not vcore
sudo ryzenadj --stapm-limit=15000 --fast-limit=18000 --slow-limit=15000 --tctl-temp=90
# result: lower sustained power → the boost algorithm requests less voltage

If you are building or living in a Linux emulation box, our Batocera 43.1 install walkthrough is the natural companion piece — get the box running first, then tune its power envelope for the hardware you actually have.

intel-undervolt and the MSR that returns zero

On an Intel laptop under Linux, intel-undervolt (or georgewhewell's undervolt) writes the same model-specific register we met in the Plundervolt section, MSR 0x150. The tools expose it as numbered domains: 0 is the CPU core, 1 the integrated GPU, 2 the CPU cache, 3 the System Agent, 4 the analog I/O. The syntax is refreshingly blunt — for example, undervolt 2 'CPU Cache' -25.84 to pull the cache down by about twenty-six millivolts. Two warnings, both real: these tools use reverse-engineered register access and explicitly note they may damage hardware, so they are not the sanctioned path; and if Plundervolt microcode has locked your chip, the write silently does nothing. Always verify the register is even writable before you trust the result:

# Intel laptop — intel-undervolt writes MSR 0x150 (domain 2 = CPU Cache)
sudo undervolt --core -75 --cache -50

# Verify the MSR is even writable (Plundervolt microcode may have locked it):
sudo rdmsr 0x150      # returns 0 on a locked chip → your undervolt is a no-op

# Watch for machine-check events:
sudo journalctl -k | grep -i mce

Why your Batocera box wants this

The efficiency case is strongest exactly where the retro crowd lives. A mini-PC emulation box in a media cabinet runs quieter and cooler with a sane power cap, which matters when the thing sits three feet from your ears. A handheld gains battery minutes that translate directly into finished RPG sessions. And a thermally constrained portable gains sustained clocks, which for demanding cores is the difference between locked full speed and a stuttering compromise. This is the same efficiency-equals-frames logic that makes undervolting a laptop worthwhile — and it is a close cousin of the diminishing-returns thinking we applied to refresh rates in our 144Hz-versus-240Hz breakdown: past a point, chasing the last few percent costs more than it returns, and the smart money spends its effort where the curve is still steep.

Five Pitfalls That Waste Weekends

Every one of these has cost someone an evening. Read them now and you buy that evening back.

Instability that hides

Pitfall 1 — testing only under all-core load. You run Cinebench for an hour, declare victory, and the machine reboots itself at the desktop that night. Fix: validate with CoreCycler (single-core max boost) and an explicit idle soak, because Ryzen instability lives at light load, not heavy. Pitfall 2 — ignoring WHEA because "it didn't crash." Corrected machine-check errors are silent data corruption caught in the act; a stable-seeming system logging Event ID 19 is not stable. Fix: treat any nonzero WHEA count at idle as a failed test and give the offending core about five counts back.

Settings that don't apply

Pitfall 3 — undervolting a Plundervolt-locked Intel chip and believing it worked. On 10th-gen and older with current microcode, MSR 0x150 is locked; your offset changes nothing while the utility reports success. Fix: confirm the effective Vcore actually moved in HWiNFO, or on Linux check that rdmsr 0x150 does not return zero. Pitfall 4 — force-disabling PBO before undervolting on AMD. This throws away the boost headroom that makes the whole exercise pay off, leaving you cooler but slower for no reason. Fix: set PBO to Auto or Enabled, then apply Curve Optimizer on top of it.

Measurement mistakes

Pitfall 5 — never validating EXPO/XMP on its own first. If your memory overclock is the real instability, you will blame the undervolt and chase millivolts that were never the problem. Fix: prove the memory profile stable before you touch voltage, so you are only ever debugging one variable. Pitfall 6 — comparing Cinebench 2026 scores to old 2024 numbers. The 2026 build recalibrated scoring roughly threefold and is explicitly not cross-comparable, so a "huge gain" or "huge loss" against a 2024 figure is an artefact, not a result. Fix: pick one Cinebench version and use it for the entire before-and-after.

Troubleshooting Table

When it misbehaves, it usually misbehaves in one of a handful of recognisable ways. Match the symptom, apply the fix, re-test.

Symptom	Likely cause	Fix
Random reboot at idle or on the desktop	1T undervolt too deep on a boosting core	Back off ~5 Curve Optimizer counts (AMD) or +0.01 V (Intel) on the offending core
BSOD: WHEA_UNCORRECTABLE_ERROR	Core/cache error the hardware couldn't correct	Reduce the offset and add margin; you were past the edge, not near it
WHEA-Logger Event ID 19 count rising, no crash	Corrected machine-check errors — too aggressive	Back off 3-5 counts; treat nonzero as failure
Crash only under Cinebench / heavy AVX	Core offset too deep under high current	Smaller core offset, or raise EDC (AMD) / relax PL (Intel)
No temp or power change after applying	Setting didn't apply: Plundervolt lock, OEM BIOS lock, or Ryzen Master not run as admin	Verify effective Vcore in HWiNFO; on Linux check rdmsr 0x150 is nonzero
Cinebench score dropped after undervolt	Silent error-correction/throttle, or PBO was disabled	Re-enable PBO, reduce the offset until the score recovers
System won't POST after a BIOS-saved value	Offset too aggressive and now persistent	Clear CMOS, reload your saved stock profile, restart milder
Stable in games, crashes at the desktop	Classic single-core max-boost instability	Switch to per-core Curve Optimizer; give golden cores less negative
Corrupted archive or render, but "stable"	Silent data corruption from a marginal undervolt	The tune is unstable — back off and re-run y-cruncher to confirm
EXPO + undervolt unstable, EXPO alone fine	Combined stability margin too thin	Loosen one; a small SoC/VDDG bump can help (keep SoC ≤ 1.30 V)

Advanced: Per-Core, SMU, Silicon Lottery

Everything so far gets you a stable, cooler, quieter chip. This is what you do when "good enough" stops being good enough and you want the last few percent — with clear eyes about the effort it costs.

Per-core hunting with CoreCycler

An all-core offset is limited by your worst core; a per-core curve is limited by nothing but your patience. CoreCycler is the tool for the job: it cycles Prime95 through each physical core one at a time, holding each at its maximum boost, and logs which core fails and when. The workflow is to push the all-core value until one core becomes the weak link, then instead of backing the whole chip off, you back off only that core and keep descending everywhere else. Repeat until every core has found its own floor. The reward is a curve that is aggressive where the silicon allows and cautious only where it must be — which is precisely the shape an all-core value can never take.

SMU Debug Tool and reading the real curve

Some 2026 Ryzen workflows use the SMU Debug Tool to verify the values the platform actually applied and to tune per-core behaviour with more precision than a simple all-core offset allows. This matters because BIOS menus and the running curve are not always the same thing — an offset can be quietly clamped, overridden by a board default, or interact with boost overrides in non-obvious ways. Reading the applied state back, rather than trusting the menu, is the boundary between engineering and superstition. It is also the honest answer to "did it apply?" for anyone who suspects an OEM lock is silently ignoring their input.

Positive counts, and other heresy

Two advanced tricks worth knowing. First: it is entirely legitimate to run positive Curve Optimizer counts on your one or two golden cores while going deep-negative everywhere else — a small positive offset can stabilise the highest boost bins and actually raise single-thread performance, which feels like heresy until you remember the goal is stability at the frequency the core wants, not the lowest possible number. Second: revisit your tune after six to twelve months. The guardband you reclaimed narrows slightly as the silicon ages, and a value that was rock-solid in spring can develop a rare idle WHEA event by autumn. Give it a couple of counts back and it is solid again. And none of this replaces a competent cooler or fresh paste — undervolting lowers the heat you must remove, but physics still insists you remove it. Pair the tune with adequate cooling and the two multiply; skimp on cooling and you will blame the undervolt for a mounting-pressure problem.

The Complete Working Configuration

Here are three sane, tested-shaped reference configurations to converge toward. They are starting frameworks, not magic numbers — your silicon lottery ticket decides the final values — but they encode every principle above into something you can actually type into a menu.

A sane AMD Ryzen profile

PBO enabled with board limits, a modest all-core Curve Optimizer offset with golden-core exceptions, EXPO on and proven, and the boost override added only after stability is confirmed:

# AMD Ryzen — final reference (adjust per-core to YOUR silicon)
Precision Boost Overdrive .... Advanced / Enabled
PBO Limits .................. Motherboard
PBO Scalar .................. 1X
Max CPU Boost Clock Override . +50 MHz    ; only after the undervolt is stable
Curve Optimizer ............. Per Core
  Golden cores (2) .......... -5 to -10
  All other cores ........... -20 (validated with CoreCycler)
EXPO ........................ Enabled (DDR5-6000, verified stable first)
Validation .................. CoreCycler full pass + overnight y-cruncher + idle soak
Target WHEA (session) ....... 0

A sane Intel Core profile

Core offset as the headline, a gentler independent cache offset, System Agent left alone, power limits at spec:

# Intel Core (12th-gen+) — final reference
CPU Core Voltage Mode ....... Offset (Adaptive + Offset)
CPU Core Voltage Offset ..... -0.075 V   (arrived at from -0.050 V)
CPU Cache/Ring Offset ....... -0.050 V
CPU System Agent Offset ..... Auto
Load-Line Calibration ....... Medium
PL1 / PL2 ................... 125 W / 253 W (spec)
Verify ...................... effective Vcore moved in HWiNFO (not just XTU says so)
Validation .................. OCCT + overnight y-cruncher; check WHEA-Logger

A Linux handheld profile

Power-limit tuning for a Ryzen APU handheld or emulation box, made persistent so it survives a reboot:

# Linux Ryzen APU handheld — power envelope (RyzenAdj tunes power, NOT vcore)
sudo ryzenadj --stapm-limit=15000 --fast-limit=18000 --slow-limit=15000 --tctl-temp=90

# Make it persistent (example systemd one-shot, run at boot):
#   ExecStart=/usr/bin/ryzenadj --stapm-limit=15000 --fast-limit=18000 \
#             --slow-limit=15000 --tctl-temp=90

# Confirm it took, and watch for machine-check events under load:
sudo ryzenadj --info
sudo journalctl -k | grep -i mce

That is the whole discipline. Undervolting really is the rare free lunch — lower temperatures, quieter fans, and, on boost-limited silicon, a little more performance than you started with, for the price of an evening and a stress test. The bill only ever arrives if you skip the validation, because a marginal undervolt does not crash politely; it corrupts quietly, the same way a certain famous attack does, minus the intent. Do the twelve steps, watch the WHEA log like it owes you money, save your profile, and revisit it in six months. Then go do the same trick to your GPU — the overclocking side of the ledger is waiting, and it uses the exact same instruments pointed the other way.