UPDATE: I will continue to update this post with relevant learnings if I have them and updated results if I'm still tuning. I answered almost every question the first day, but I can't keep up with answering your questions, especially about your individual cases. Please help each other.

I come from many generations of Intel builds. Over the decades, the experience of overclocking Intel roughly translated to pouring voltage into core and maybe some into uncore while raising the multiplier until you hit a ceiling. Overclocking Zen 3 has been a completely different experience, with boost and PBO doing smart things that you want your OC efforts to support and optimize rather than replace.

I've spent many hours over the past four days overclocking both my 5900X and 5600X rigs, and I've learned a lot on the way. I figured I should share some important information with the community.

I included a background section for newbies that many of you might want to skip.

BACKGROUND

Your CPU will algorithmically boost the frequency of its cores depending on workload. For single threaded workloads, it will boost one core, and for multithreaded workloads, it will boost multiple cores. The frequency at which your core(s) will boost is governed by internal limits, such as power, current, voltage, temperature, and likely other factors, but the important thing to understand is that, holding limits constant, your CPU can boost one core to a higher frequency than it can boost multiple cores. This should make common sense to you.

PBO raises the current and power limits that govern your CPU's boost algorithm. You can raise your PBO settings as high as you'd like, but PBO has a hard limit of allowing 105W TDP CPUs to draw ~220W and 65W TDP CPUs to draw ~130W. PBO does not raise your CPU's max boost frequency, which is 4.8GHz stock for the 5900X and 4.65GHz stock for the 5600X, both of which are typically achievable only when the CPUs are boosting 1-2 cores. Practically speaking, enabling and maxing out PBO translates to your CPU boosting clocks during multithreaded workloads until your CPU is drawing ~220W / ~130W.

Auto OC raises the maximum stock boost clock by an offset, up to +200MHz, that you set. For example, a +200MHz offset will raise the stock 4.65GHz boost limit of a 5600X to 4.85GHz. Auto OC does not guarantee your CPU will be able to reach the boost clock under load. All it does is allow the CPU to try, but the CPU boosting algorithm will still take into account all the factors as usual to determine boost.

PBO 2.0 w/ Curve Optimizer: Undervolting is a way of overclocking CPUs and GPUs that have an internal table that maps voltage to operating frequency. Basically, a 50mV undervolt tells a CPU that instead of operating at, say, 2GHz at 1V, operate at 2GHz at 0.95V instead, and whatever frequency is mapped to 1V is now >2GHz. When a Zen 3 CPU is undervolted, this means that the same power limits that govern its boost algorithm all map to higher operating frequencies.

Curve optimizer basically allows you to undervolt each core independently.

GUIDE STARTS HERE

The steps for using Curve Optimizer to OC are:

1. Curve Optimizer is part of PBO 2.0, so enable PBO and set it to your platform's limits.

2. Under PBO, leave the scalar at Auto. Auto performed the best for me, but if you want to try to tweak this, I'll mention when you should do this.

3. In Curve Optimizer, start with an all core undervolt of -5. Iterate between STABILITY TESTING (HIGHLY TRICKY. SEE BELOW.) and lowering this by -5 each time until you find the lowest stable value.

4. Now you know the undervolt limit of at least one of your cores. You can now go into per core undervolting to find which cores you can bring down further using the same iterative method above.

5. You're done. Now's the time to test a custom scalar value if you really wish to.

You will find that undervolting nets significant gains in both single and multithreaded performance. The more you can undervolt, the greater the gains.

AN IMPORTANT COMPLICATION: UNDERVOTING & AUTOOC

The relationship between undervolting stability and your AutoOC setting is critical. Broadly speaking, the more aggressive you undervolt, the more gains you get, but the higher you set your AutoOC offset, the less aggressive you can stably undervolt. This should make sense to you because your cores require more voltage to attempt the higher boost ceiling you specified. Practically speaking, you will likely find that your once stable undervolt setting is now unstable if you raise AutoOC from +0 to +200MHz.

Let's illustrate this relationship using an example. Say you set your AutoOC offset to +200MHz for a CPU with a 4.8GHz boost limit because you want it to boost to 5GHz. However, you find that the best stable undervolt you can achieve now results in a single core boost speed that barely blips to 4.95GHz. At this point, you should lower your AutoOC offset in order to undervolt further so that your undervolt boost can actually achieve what your offset specifies.

On the flip side, say you have a +0 offset, but your stable undervolt has your single core boost pretty much glued to its limit of 4.8GHz. In this situation, you should increase your AutoOC offset and back off on your undervolting until your offset is again equal to the what your undervolt boost can achieve.

EVEN MORE IMPORTANT: STABILITY TESTING

Your Curve Optimized undervolt will not be stable in low power workloads long before it will show any stability issues in any high power workloads, including every single benchmarking tool you use, including Cinebench and Prime95. An unstable undervolt will result in your PC sometimes randomly freezing, restarting, or BSODing when you're not doing much beyond browsing File Explorer or similar tasks.

Finding a low power workload for stability testing undervolting was the primary challenge of this entire process. The best one I found is the Windows 10 Automatic Repair and Diagnosis workload that can happen pre-boot. You can manually trigger this workload by restarting your PC after it posts but before Windows boots two consecutive times. The third boot will automatically start this workload after post.

This workload completing successfully means it will put you into a menu with a Restart option that you can click on to successfully restart your computer. An unstable undervolt can result in a myriad of different things going wrong, including:

1. The PC suddenly reboots by itself before you reach the menu screen.

2. A BSOD at any point in the workload.

3. Making it to the menu and choosing to restart the PC, but then your PC freezes before restarting.

Once you have successfully triggered the Automatic Repair process, your next boot will be normal. However, if you reset your PC during this next normal boot before Windows successfully loads, it will trigger Automatic Repair in your subsequent boot again.

To test stability, I recommend 10x consecutive successful passes of this workload. This involves using the Automatic Repair workload to restart your computer, resetting your computer in the next boot to trigger the workload again, and repeating. I hope your PC has a reset button next to the power switch, because that comes in handy here.

UPDATE

This stability test works most consistently for finding the limits of your top 2-3 cores in terms of priority. You will notice that after finding these limits, you can undervolt your other cores significantly lower while still passing this test. I haven't yet found a reliable, consistent, and reproducible workload to test these other cores beyond just using your PC and waiting for a random restart or WHEA/other BSOD. Others have mentioned their own jury rigged tests in the comments that you can try.

Finally, low power stability testing is in addition to normal high load stability testing via the usual benchmarks. In fact, if you are failing those, then your OC efforts are in an even worse state than those who only fail low load stability.

MY RESULTS

My final results for my 5900X are:

Core 0: -18
Core 1: -5
Core 2: -18
Core 3: -18
Core 4: -18
Core 5: -18
Core 6: -18
Core 7: -18
Core 8: -18
Core 9: -18
Core 10: -18
Core 11: -18

Scalar: Auto
AutoOC offset: +25 MHz (4.95GHz stock boost limit for unknown reasons, so 4.975GHz with offset)

Cinebench R23 results: https://i.imgur.com/BQNcdbk.png

Takeaways:

1. My all core undervolt wasn't stable beyond -5. As you can see, I eventually realized that it was my Core 1 bottlenecking that.

2. My core 1 happens to be my highest priority core. This means my single threaded score is not nearly as impressive as I'd like. Silicon lottery at play here.

3. I only really bothered individually optimizing Core 1, 2, 0, and 5, as those are my highest priority cores. I always tested cores 3 and 4 together and found stability with them at -20. I tested all my second CCD's cores (cores 6-11) in one batch; there may be some optimizations there, but I couldn't be bothered.

4. While my highest priority core could only support a -5 undervolt, my other cores can be undervolted quite significantly, resulting in a pretty impressive multicore benchmark score, IMO.

My final results for my 5600X are:

Core 0: -8
Core 1: -8
Core 2: -4
Core 3: -8
Core 4: -8
Core 5: -4

Scalar: Auto
AutoOC offset: +200 MHz

Cinebench R23 results: https://i.imgur.com/88JXBOh.png

Takeaways:

1. SC boost was glued to 4.85 GHz, which is the maximum allowed.

2. More interestingly, MC all core boost was at 4.6-4.65 GHz, which is basically the stock single core boost of the chip. Pretty impressive.

Hi,

So running my 5600x curve optimizer all cores to negative 22, I saw some videos running negative per core with much lower numbers (5, 10, 15, 5, 10, 5), not sure what I'm doing is right or wrong? should the preferred core have the lowest negative or the highest?

GB Aorus Elite X570.

thanks,

This is free performance that I hadn’t taken advantage of in the year I’ve owned my Ryzen 5600, so I’m writing to this to advocate that nobody else wait as long as I did.

This is my guide. There are many like it, but this one is mine😁.

Curve Optimization is very easy - the testing being automated - and poses no danger whatsoever to one’s hardware; the worst you can expect is a Windows bluescreen, and that is no more deleterious than stalling a car. The only drawback is that you will need to have your computer running tests that render it useless – if you are prepared to leave it running overnight and/or while at work, though, this is not a problem – and it can take a long time.

1. Software (all free)

You will need:

• AMD Ryzen Master (latest version)

• HWINFO (to get the preferred core order and, optionally, compare before and after temps/power)

• Core Cycler (which contains PBO2Tuner – set and test curve optimizer values)

• CPU and gaming benchmarks (compare before and after performance, test for real-world stability)

2. Preliminaries

• Open HWINFO and uncheck both boxes, then navigate to “Central Processor(s)”-> <your CPU>. Make a note of the sequence after “Core Performance Order” – this is the order in which we will be testing them with Core Cycler, but you must SUBTRACT 1 from each value; Core Cycler starts numbering cores at 0, not 1.

• Open AMD Ryzen Master, select Advanced View, click Curve Optimizer, Per Core, then click Start Optimizing. Ryzen Master will then enter an automated procedure to generate its best estimate of what your CPU is capable of. Plan to be away from your computer for at least an hour while this is going on; when you come back, make a note of the values it generates, but DO NOT APPLY them - just close the program. Note that the “subtract 1” rule applies to Ryzen Master, as with HWINFO.

• Open the Core Cycler config file and make the following changes:

“stressTestProgram = YCRUNCHER”

“coreTestOrder = <your order from earlier>” - remember to subtract one from each

“numberOfThreads = 2”

“mode = 20-ZN3 ~ Yuzuki” in the ycruncher section, halfway down the page.

Some rationale:

The preferred core order is from WORST to BEST under-volter, and thus MOST to LEAST likely to fail – this is because the more preferred a core is, the more efficiently it is already running, and so the lower the voltage floor is. This makes testing faster because the most unstable cores will fail first, and dropped cores are left out of subsequent intra-session iterations by Core Cycler. Also, the ycruncher Yuzuki test is considered to be the most difficult one to pass, so we might as well start with it; you can – and should – run others afterwards.

• Open Windows Event Viewer, right-click on Custom Views, and click Create Custom View. Check “Warning”, and “Error”, then “By source”, and check “WHEA Error” in event sources. Name the view something meaningful, then exit the Event Viewer. This is just in case Windows ever BSODs – not likely, but possible – and we will need to know which core failed.

3. Testing – Round One

Create a spreadsheet like the one below – we will be keeping track of passes and fails.

When you’re ready to leave the computer alone, close all programs, open PBO2Tuner and key in the values given by Ryzen Master earlier, then click Apply, and minimize the program. These values are applied as though they were typed into the BIOS, and persist until they are changed, or the computer is restarted.

Run “Run CoreCycler” - the testing will begin, and will run until you stop it, or until every core has thrown an error.

~TESTING HAPPENS – LEAVE FOR AS LONG AS POSSIBLE, PREFERABLY 6+ HOURS~

When you come back to the computer, if Core Cycler is still running, stop it with Ctrl-C, and see which core/s, if any, have failed; Ryzen Master’s supplied values are usually rather optimistic, so you should expect some errors, which show up in bright purple text. (If you accidentally close the window, the log file contains all the same information, but is more annoying to parse.)

Scroll around the window and see how long it took for the core/s in question to error out – a fast error is anything under 10 mins, IMO, and a slow error is anything over. Any core with a fast error will be having its CO value increased by 2, while slows will have theirs increased by 1; if any cores don’t error (in which case, Core Cycler will still be running on those cores when you come to check), add them to the

“coresToIgnore =”

– no point hitting these cores again until Round 2.

(If the machine has reset, go into Event Viewer and look in your custom view – under Error, there will be an entry called “Processor APIC ID”, with a number, the number corresponding to a thread. Core 0 will run threads 0 and 1, Core 1, threads 2 and 3, and so on; whichever core was running the failed thread, increase its CO by 3 or 4 – that core was not even close to stable!)

Update your spreadsheet as shown below, with the adjusted CO values, and save it – when you are ready for your next test session, put these new values into PBO2Tuner before you start.

Keep repeating the above until all cores pass a session of this “all cores at once” testing.

and so on; my last all-core session, after shedding cores as they passed, looked like this:

4. Testing – Round 2

The next step is to extend the testing for each core. You can jump right to hitting one core for 6+ hours (as I did), or divide the cores into two groups (“front half, back half”, from the order earlier, is best), and test them one half at a time, Ignoring the cores in the other half. This will double the amount of time each core is under stress, and might generate errors that didn’t appear before, but you will be much closer to the true stable value thanks to the previous testing.

Change the core testing order to match the results from Round One - they might not be the same as the HWINFO values; for example, HWINFO gave me 2 ,1 ,0, 4, 3, 5, but ordering by the results of my Round One, worst to best, would be 0, 1, 4, 5, 3, 2.

Do the “increment on error” procedure from before, until the front half all pass, and then do the same for the rear half.

5. Testing – Round 3-4-5

If you like, you can split the cores again, and repeat, getting all groups stable. Keep splitting until you get to the point where only one core is being tested at a time:

• Ryzen 3 – four, two twos, four ones.

• Ryzen 5 – six, two threes (or three twos), six ones.

• Ryzen 7 – eight, two fours, four twos, eight ones.

• Ryzen 9 – 5900 = twelve, two sixes, then each six as per Ryzen 5; 5950 = sixteen, two eights, then each eight as Ryzen 7.

Yes, this CAN be a lot of testing, but Curve Optimizer CPUs are most likely to crash at the highest boosts (= lowest loads), so sheer duration is the only way to generate any confidence in stability. Thankfully, Ryzen Master gets us most of the way there; the values it gives are usually stable enough at least for idle Windows tasks.

My last round of Yuzuki was a 40-iteration test on each core individually - 5-6 hours per core:

From Ryzen Master's -28, -30, -30, -30, -30, -30, I ended up at -20, -21, -29, -26, -22, -26.

6. Further Testing

It is advisable to use the PRIME95 HUGE on each core in turn, as this is another very low load situation that lets the CPU boost to its maximum; make these changes in the Core Cycler config file. Feel free to try to some other presets as well – no such thing as too much testing. Read what other users found to be their “magic bullet” test settings, and try those out.

The best test, though, is, as always, to use the thing - browse, game, edit, do whatever you normally do.

7. Finalizing

When you’re happy that everything tests stably, go into the BIOS and enter your final values in the Curve Optimizer menu – this will save you having to use PBOTuner2 every time you boot up.

If your computer ever crashes (not impossible) use the Event Viewer to identify the rogue core, and increase its CO value in the BIOS.

Each CCD sharesone voltage rail for all the cores within that ccd. Most people assume that since curve optimizer allows per core offsets then each core has its own dedicated voltage rail for each specific core however this is NOT the case. If 1 or more cores are active (not parked) and they have a different offsets then the SMU will pick the lowest offset of the group and that’s what you will run at. It doesn’t care that every other core is at -60, if you have one core at -5 and all cores are active then the cpu will effectively run as a -5 offset cpu.

Per-core CO helps single/light-thread boost. (Think single core benchmarks, marketing) no modern AAA game runs on 1 or 2 cores, the year is not 1999)

TL/DR: Worst core dominates anything beyond ideal single threaded conditions.