Prime95 on Ryzen: Testing PBO and Curve Optimizer

Curve Optimizer lets Ryzen owners lower the voltage the CPU requests at each frequency, which can mean lower temperatures or higher boost clocks. The catch is stability: a setting that sails through an all-core Prime95 run can still crash at idle or in light loads. This guide explains why all-core tests miss the problem, how per-core testing with CoreCycler works, and how people approach the settings safely.

What Curve Optimizer does

Every CPU follows a voltage-frequency curve: at each clock speed, it asks for a certain voltage. Curve Optimizer is an AMD Ryzen feature, used together with Precision Boost Overdrive (PBO), that shifts that curve by a number of steps per core. A negative offset means the CPU asks for less voltage than stock at the same frequency. Less voltage means less heat, so the chip either runs cooler or has more headroom to boost higher.

The trade-off is that silicon varies. Some cores can run on far less voltage than others, and push too far and a core becomes unstable. Because the setting is per core, finding each core’s limit is the real work.

Why all-core Prime95 isn’t enough

Instability from Curve Optimizer tends to appear at high boost clocks, and an all-core load keeps clocks low. The CoreCycler project explains the problem directly: its README notes that running Prime95 on all cores is not effective for Curve Optimizer testing, because the cores cannot boost as high, so instabilities that appear at higher clock speeds can go undetected.

A common result is a system that passes hours of all-core Prime95 and then crashes while idling or loading a web page, which is when a single core boosts as high as it can on little voltage. That’s the situation per-core testing was created to catch. For the all-core side of testing, see how to stress test your CPU with Prime95.

What CoreCycler is

CoreCycler is an open-source tool that runs a stress test, such as Prime95, on one physical core at a time and cycles through all of them. Testing cores individually lets each one boost freely, which exposes a weak core that an all-core run would hide. Discussion of the tool and how people use it is on Overclock.net, and the project’s GitHub page holds the documentation and settings.

How people approach the settings

The CoreCycler documentation suggests starting around a negative offset of -15 or -20 on each core, then adjusting each core in steps of 2 or 3 depending on whether it errors. Results differ widely. One forum user’s per-core offsets ranged from +3 to -25, which shows why a single all-core value is often not the best choice. And an offset copied from someone else’s PC is only a guess, since results vary by chip, firmware version and cooling.

A step-by-step process

1. Update the BIOS and note baseline temperatures, clocks and a benchmark score.
2. Set a moderate negative offset on all cores, or per core if you’re confident, following the starting range above.
3. Run a per-core test with CoreCycler, letting each core finish its time.
4. If a core errors, make its offset less negative by 2 to 3 and retest that core.
5. Repeat until every core passes at its own value.
6. Confirm with an all-core test, such as Prime95 Blend, to check the combined behaviour. See which mode to choose.
7. Test real use: idle, light loads and your games or apps for several days.

How long does it take?

A long time. A guide to the method notes that a 12-hour pass on a 12-core CPU works out to roughly 144 hours when each core is tested in turn. Most people use shorter runs per core during tuning, then extend testing on the final settings. Plan for days, not an evening. You can spread the effort by tuning the weakest cores first.

Why instability can show up at idle

When the PC is mostly idle, a single core may boost very high for a moment while drawing little voltage. If that core’s offset is too aggressive, it fails during that brief burst, and you get a random reboot or freeze with no heavy load running. Per-core testing, which lets each core boost high in isolation, is the best way to reproduce it. If you get such crashes after a change, loosen the offsets on your best cores first.

Cautions

• The CoreCycler README warns that using PBO technically voids the warranty of a Ryzen CPU. Read your warranty terms before you tune.
• Unstable settings may crash in idle or light loads, not just under stress. Test idle and gaming as well.
• If you see errors, follow the steps in Prime95 errors explained and keep temperatures within limits. See safe Prime95 temperatures.
• Cross-check with another tool before calling it stable. Prime95 vs OCCT vs AIDA64 vs Cinebench compares them.
• Don’t copy a negative-offset value from a forum post and apply it to every core. It’s a starting point at best.

What the CoreCycler README says, in detail

This page leans on one primary source, so it’s worth summarising what that source actually states. The CoreCycler README describes CoreCycler as a PowerShell script that tests the stability of single-core loads. It runs a stress test with one worker thread and moves that test’s affinity across each physical core in turn. It’s aimed at AMD Ryzen PBO and Curve Optimizer settings, and at Intel Active-Core Turbo-Boost settings.

The adjustment rules

The README’s guidance on how to change values is simple and worth following as written. Start at a value such as -15 or -20 for each core. Make the setting less negative, by about 2 or 3 points, for cores that error. Make it more negative for cores that run fine. Near the limit, adjust by a single point at a time and run longer to catch the last instabilities.

The README also gives a realistic picture of time. Its worked example is a “12h prime-stable” goal on a 12-core 5900X, which means running each core for 12 hours, or 144 hours in total. The FAQ’s answer to how long to test is, basically, as long as you can. That honesty is a good model: tuning is a long process, and shortcuts show up later as random crashes.

Warnings from the README

• Warranty: the README says using PBO technically voids the warranty of a Ryzen CPU, so use it at your own risk.
• Degradation: the author warns there’s a certain risk of degradation for your chip under prolonged maximum temperatures, and takes no responsibility for hardware damage.
• Test depth: SSE testing is lighter and can reveal boost-related instabilities, but AVX and AVX2 should also be tested for full coverage.
• RAM: overclocked RAM can cause errors that look like CPU problems, so the author recommends testing CPU and RAM overclocks separately.
• Crashes: if the PC crashes during testing, the FAQ says it’s very likely your Boost or Curve Optimizer setting is unstable.

Requirements and common setup problems

CoreCycler requires Windows with the .NET Framework, at least version 3.5, and the Windows Performance Process Counter (PerfProc) enabled. If PerfProc is disabled, the script shows a “FATAL ERROR: Could not access the Windows Performance Process Counter!” message. Stress test binaries must sit in the matching test_programs folders, and configuration lives in a config.ini that’s generated on first run, with documented defaults in the project’s default configuration file. The script reports which core and virtual CPU it’s testing, so you can see where a failure happened.

Frequently asked questions

Related guides