[jjwalker]

What this is for:

This guide is intended to make high performance overclocks easier to daily drive. You'll be able to max out your processor's performance easily, while retaining the convenience of the dynamic clocking provided by the SMU. You can not set a fixed frequency, but this will allow you to easily pick a point in the SMU's performance and voltage table and set it as your default performance target. The SMU will operate around this performance target, and will abide by normal safety limits unless you manipulate or disable them. If you are attempting to break a world record and/or set static clocks, this may assist you, but there may be easier ways to achieve that. This guide is not focused on that.

This is where it all started, and the work that got me to this is detailed in this post...

Using Ohm's Law power equation for overclocking

I continued with this and discovered the math behind the SMU's Dynamic Voltage Table (DVT), how it is calculated, and how to set it for a specific performance target. This is for Zen 2 (3000's) and Zen 3 (5000's). I am old school and I do not like using software to overclock, and when I purchase an unlocked processor, I want it actually unlocked. All of this can be done in the BIOS.

How to set a specific performance target:

This guide is written around how to do it with an Asus motherboard, however, as long as you have cTDP, PPL and PBO, you will be able to do this and it is not manufacturer specific.

To get started, you will need a "K" value which is your performance target and with this K value you can easily calculate this. You need Cinebench R23 to get this value along with HWinfo.

In your BIOS, set PBO Manual with scalar X1 or X2 and PPT/TDC/EDC as Auto. This works with or without Fmax enhancer as it does something similar, but isn't adjustable. For this purpose, the only value it has is getting rid of EDC. Leave it off and keep EDC if you choose. Voltage needs to be set to auto along with LLC with no offsets. Your memory OC needs to be already done before you start. Make sure "performance Enhancer" is set to default, not Auto.

Now, let's get your K value...

To get your K, start cinebench and run a multicore bench and while it is loading, bring HWinfo to the foreground. Reset the timer as the render window goes black and watch HWinfo. When you get to your MAXIMUM clocks on your cores and/or your thermal target (this can be whatever, I chose 70*C for the screenshots) note your current PPT and core voltage at CPU TFN2 as you'll need these. The PPT in watts is going to be your performance target/TDP target and the reading at CPU TFN2 is the voltage we need to base your TDC calculation on. This give us a specific "point" on the voltage table that is unique to your silicon. All of this can be adjusted to your needs, and I'll get to that later.
Take your Voltage you noted in CBR23 and do " PPTw / Vcore = TDC ". This your new TDC value you'll enter in PBO. For example, I had " 150w / 1.344v = 111.6A " so my TDC became 112A.

Reboot and go back into your BIOS and hop over to AMD CBS/NBIO/SMU and set cTDP to manual. Put the PPT you noted in CBR23 there, mine was 150w. Scroll down to Package Power limit and set that to manual. I recommend you set this to 40 watts above your cTDP maximum, and the minimum you can set this is the same as cTDP. Do not set PPL less than the cTDP you just entered.
Now while still in the BIOS, go to PBO and set PPT to what you set as PPL in AMD CBS, and set TDC to the value you calculated earlier. Set EDC to your motherboard VRM limit (or don't worry about it if it is disabled). Set the bios options that reduce latency and turn off power savers that I detailed in the post linked above. This is optional, but there is a lot on the table if you do so.

That's it. It's that simple. This moves your processor power target to the cTDP you entered and the effective requested VID to the voltage you used to calculate your TDC. If there is a variance, continue reading as I get to that a little further down.

To give you an example, I am running these numbers right now...

Example:

TDC = 112

PPT = 190

EDC = Set to board VRM limit (mine is 247)

cTDP = 150 (which brings me around the Zen2's 70*c soft thermal throttle)

PPL = 190

The SMU uses TDC and cTDP to calculate what voltage to use. In my example, full load @ 150 watt TDP the SMU will request 1.344v to get maximum clock speed. 1.344v is my new p0 VID maximum.

Depending on your board and/or bios, there will be a variance. After everything is set, if you change Vcore from "Auto" to "Offset +/- 0.006v" it should take care of the variance. My variance brought my voltage slightly low, so I had better results with +0.006v offset. You'll need to watch HWinfo under CBR23 to determine whether you need to correct + or -. So far, I know this variance is caused by at least 2 things. The first is manufacturer programmed voltage offset in the BIOS and the other is power reporting deviation. Regardless, you'll be very close first try if you did the math correctly.

How to customize this to fit your needs:

Let's say 1.344v makes you uncomfortable at full load, and you would feel better with 1.300v. You can calculate " cTDP / 1.3v = TDC ". Your new max VID for that state will now be 1.3v at max TDP @ max sustained frequency. To be clear, the SMU will still choose a lower voltage if it feels it is appropriate for the given load, your choice on voltage to calculate TDC sets its upper limit.

The SMU will not exceed defined operating limits unless you disable or modify them. If you where to set the voltage to something outside the SMU operating limitations, it would simply not use it and you will have a significant performance reduction. Adjusting the full load voltage with the TDC calculation is very useful in fact, just be aware it has limitations and test it if you deviated from the base equation to set a lower voltage. The same also applies to higher voltages. The bottom line is, deviating from the base calculation here is very useful for fine adjustment, and may not be suitable for larger ones. I suggest using "Max voltage offset" setting in AMD CBS/NBIO/SMU or using the standard voltage offset setting provided by your motherboard manufacturer for larger adjustments. Large adjustments to voltage using this method can throw the equation off and you'll spend more time fixing voltage variance. If you are okay with that, then go right ahead.

This process can also be helpful to DECREASE your processors power target for quiet computing or HTPC applications. You keep all the safety, have full control of the SMU performance target and you can retain the dynamic clocks. It's everything I think any Ryzen owner ever wanted instead of hoping you hit the magic PBO scalar. Below is a quick list of the equations used for reference so you don't have to dig through the information in the event you need to reference them again.

Quick reference equations:

V * A = W

W / V = A

W / A = V

TDC = Desired TDP / Desired Max Voltage

cTDP = Desired max power @ temp / Desired Max Voltage

PPT/PPL = CPUw + SoCw + MemC + *headroom (if desired - Minimum PPT/PPL is cTDP)

special notes
1.) If you use extreme loads such as Prime95 on a regular basis, I would recommend using it for your K value instead of CBR23. I chose CBR23 as it is a proper full load and "real world" and not extreme. CBR23 is probably the highest load 90% of processors ever see. Choose what fits your specific worst case. The SMU will not remove any defined limits unless you change or remove them, nor will it exceed/boost beyond the specified performance target.

This guide will be updated with additional information as it is available. I am currently testing ways to quickly correct for deviation.

If anyone has questions or needs clarification, please let me know!

 

[Melan]

I'd guess this is generally useless for non-X SKUs?
I've been playing around with PBO on my 3600 and results are pretty much the same... except higher temps for margin of error benefits.

 

[jjwalker]

While I don't believe non-X sku's can be pushed beyond the baked in TDP from AMD, it is worth a shot. I haven't tested this on a non-X processor yet and everyone who has tested this so far besides myself has been all X processors.

It's worth a shot though. Worst case scenario is that you set your BIOS back to the way you have it now and nothing changes.

Edit: Actually, you could use this to lower your standard operating voltage across the DVT and get higher boost clocks up to the factory TDP if it is in fact locked.

 

[Melan]

I tried it. As usual I cap out on 105/60/90 (or slightly above according to hwinfo). Now I just set PBO to "motherboard" which in turn slaps 1000/114/168 without any benefit other than less stuff to type in.
Waiting on that new 5600X with extra cache.

 

[jjwalker]

I tried it. As usual I cap out on 105/60/90 (or slightly above according to hwinfo). Now I just set PBO to "motherboard" which in turn slaps 1000/114/168 without any benefit other than less stuff to type in.
Waiting on that new 5600X with extra cache.

If you want to use this to lower your thermals and eek out a little extra clock before you slam into the 105w limit, run HWinfo to get your K value as outlined and let your temperature settle to 70C or below. Note your voltage at TFN2 but also note what the % power reporting deviation is as well. Take your K value and calculate TDC but use a voltage -0.0125 or -0.025 lower than what you noted. Take your deviation percentage you also noted and if it is negative, reduce the calculated TDC by that percentage or if it was positive, increase your calculated TDC by that percentage.

Once you boot back into windows, run HWinfo again with the same load and note your voltage and deviation percentage. The goal is to get it as close as possible to 100%. If you can do that and shave off just a few degrees, I've seen 100mhz+ increases in boost clocks by doing so in some of my tests. You still need to do what's outlined in the guide, just make your power target 105w.

What board is this if you don't mind me asking?

 

[Melan]

MSI B450M Mortar MAX with latest bios.

Edit: Played around with it some more. It's not gonna happen with non-X SKU. You'll keep slamming into the limit.
At the limit I get ~4030mhz and 1.325v all core but at toasty 80C. On stock it's 3950mhz and 1.235 at 70C but 150-200 less cinebench epeen. Deviation on both was ~98% though which aligned with previously mentioned "slightly above according to hwinfo" statement.

tl;dr Get the X SKU to play the PBO game.

 

[ZealotKi11er]

I tried it. As usual I cap out on 105/60/90 (or slightly above according to hwinfo). Now I just set PBO to "motherboard" which in turn slaps 1000/114/168 without any benefit other than less stuff to type in.
Waiting on that new 5600X with extra cache.

What is this new 5600x with extra cache?

 

[The Pook]

What is this new 5600x with extra cache?

won't really be a "new" 5600X, I doubt they'd release it under the same name even if all the other specs are identical.

AMD Shows New 3D V-Cache Ryzen Chiplets, up to 192MB of L3 Cache, 15% Gaming Improvement (Updated)

AMD shocks the chip world

www.tomshardware.com

I'll eat my shoes if the new V-Cache models don't get a new SKU.

 

[jjwalker]

MSI B450M Mortar MAX with latest bios.

Edit: Played around with it some more. It's not gonna happen with non-X SKU. You'll keep slamming into the limit.
At the limit I get ~4030mhz and 1.325v all core but at toasty 80C. On stock it's 3950mhz and 1.235 at 70C but 150-200 less cinebench epeen. Deviation on both was ~98% though which aligned with previously mentioned "slightly above according to hwinfo" statement.

tl;dr Get the X SKU to play the PBO game.

Everyone so far who has had a problem doing this has an MSI board, so I had already kind of guessed. It may not be your processor, but I don't have enough tests to know. Another fellow with an MSI board and a 3800X couldn't do it either. I'll have to find more people with MSI boards to test and try and pinpoint what the deal is. MSI setups are where I have the least test data.

I am glad to hear that the math got you so close so easily, not that this hasn't already been tested very thoroughly, but as further proof that it just works and I managed to nail it.

 

[munternet]

Everyone so far who has had a problem doing this has an MSI board, so I had already kind of guessed. It may not be your processor, but I don't have enough tests to know. Another fellow with an MSI board and a 3800X couldn't do it either. I'll have to find more people with MSI boards to test and try and pinpoint what the deal is. MSI setups are where I have the least test data.

I am glad to hear that the math got you so close so easily, not that this hasn't already been tested very thoroughly, but as further proof that it just works and I managed to nail it.

I'm looking forward to trying this method of getting my voltages lower
I'm glad this is the "simple" version
Running a 5950x as in my sig at 1.48vcore spike and reporting 1.336v in HWinfo under load running at 4.5GHz dropping to 4.45GHz at 85°c

I would appreciate an opinion or 2 on my current overclock as I'm new to AMD, cheers

 

[jjwalker]

I did FINALLY get one test back on an MSI board. It works but it requires a substantial amount of BIOS trickery and... well BS.

So it can be done but jeez! 0_o

Also, I've spent 3 weeks hammering this to death and it just doesn't fail. Finally, AMD's secret "formular" (Mr. Krabs) isn't so secret.

 

[Luggage]

Any hints at the MSI BIOS trickery and BS? I want to try this on my Unify

 

[sty]

I registered to say thank you to the OP for sharing his experience in details, and also to offer my opinion on this topic.

First of all, I didn't read the Reddit post so I can't rule out there were some valid points there. From the brief moment I skimmed through that post, I was quite skeptical about the unnecessary complexity in describing them.

Now back to the OP in this thread. It seems going through all the steps just to achieve one goal: 1) lower sustained all core voltage with a workload typical of CR20, 2) limit max temp to a chosen level with all core workload typical of CR20 (this is just a different way of expressing #1) or 3) cap max power consumption to a certain limit with all core workload typical of CR20 (this is also a different way of expressing #1).

I haven't verified if AMD's boost algorithm will shift along the "DVT" curve according to the OP. Nor I pretend to understand what exactly that means. On its face value, I don't see special benefits (more on this below) of going through the complexity. Seems simpler & single knob in BIOS such as Vcore voltage offset, Platform Thermal Limit or Package Power Limit could achieve the same result while AGESA will do automatic adjustment in the boost algo under the hood.

Nevertheless, when OP is proven to have figured out the relationships of multiple knobs in AMD's boost algorithm, it will be some very good finding to further understanding in AMD's boost algorithm.

---

Now why did I bother to post my response?

Because I firmly believe there were bugs inside AMD's boost algorithm since zen2. If test hard enough, I believe most OC will run into errors that will be considered unstable to people who insist 100% error free under all types of workloads.

I ran into such a "bug" that I've been trying to workaround on & off since I built my R5 3600 system two years ago. The "bug" shows up under such conditions:

• ambient temperature near or above 30C
• some sort of PBO based OC striking a balance between maximum performance at an acceptable power cap
• stock memory speed i.e. JEDEC 2400/2666/2966 or 3200 that your sticks natively come with
• a guest VM (which OS doesn't matter) running under Linux host with QEMU KVM.

And the actual tests in guest VM:

• fire up LuxMark stress test (GPU only) and keep it running through out the test session
• run Prime95 128K FFT for 30mins
• run Prime95 7M to 8M FFT for one loop
• run Prime95 128K FFT for up to 60mins (N.B.: some threads will fail)

My result: anywhere between 10min to an hour (depending on how stable your OC were during the tests), one or more threads would die in the 2nd run of P95 128K FFT.

I think I eventually figured out a way to avoid such a failure. I only ran the P95 128K 2nd time up to 1.5hrs so I won't rule out I might still run into dying threads if I had run much longer. But for the number of times I tried and the duration I tested, I could no longer reproduce the issue. I considered my system 'absolutely' stable enough.

What does this have to do with OP?

I found arbitrarily coming up with PPT/TDC/EDC values like voodoo. While I'm aware of and have been using PPT for limiting over-boost, I paid little attention to TDC and its unknown side-effect on AMD's boost algorithm.

So I found OP's way of 'calibrating' the TDC value interesting. And I gave it a try. From running CR20, I calculated my R5 3600's TDC to be 68A. Strangely and separately, P95 128K FFT turns out to be actually consuming around 68A if it's allowed to run under the same BIOS settings used for running CR20 'calibration'. IDK if this is pure coincidence of my R5 3600 sample (and MSI B450 Mortar Max). Or other R5 3600 samples and Ryzen SKUs have some sort of similar relationship..

So I put 68A as TDC in BIOS. Adjusted PPT, PPL accordingly. To feel comfort, I limit max temp below 90C and actually put 86C in Platform Thermal Limit after a few rounds of brief trial runs.

I think it doesn't matter what exact values PPT & PPL are as long as they don't limit in achieving 68A TDC. But I could be wrong. Because I thought the same about TDC when I used PPT for limiting over-boost. So I put in some sane but still will-never-be-reached values (112W to be exact and I didn't follow OP's formula here).

Boom.

It appears to be a better workaround to avoid the "bug" I described above. The additional benefits are: I could run my R5 3600 at a higher power budget (+2 to 5W higher dependent on P95 workload and ambient temp during tests). Single core for general workload can be allowed to boost +25MHz higher than it was in my old workaround. I think this is not bad.

Lastly, CR20 seems consistently scoring higher than before though within margin of measurement error i.e. <1%. Perhaps I should just believe in AMD's boost algorithm running smoother with the change. Time will tell.

TL;DR: Don't OC if you treasure your life. If you have to, only spend 20% of your allocated time for OC and reap 80% of the reward. Be happy with it. If you're insane & desperate to stabilize your Zen2 or newer systems, perhaps re-visit your TDC value in PBO settings. To find a sane TDC value, OP's calibration method is a worthy consideration!

 

[sty]

I spoke too soon.

I have to scale down 25MHz in PBO in order to avoid dying threads in the P95 Test described in my previous post.

Will report back if I've to forfeit any benefits of 'calibrated TDC' that I said in my previous post.

 

[dansi]

honestly Amd ran their firmware ship super tight for zen, you cannot have much 'unlock' leftover.

just keep the zen cpu as cool as possible and let amd firmware and pbo do their work

 

[sty]

honestly Amd ran their firmware ship super tight for zen, you cannot have much 'unlock' leftover.

just keep the zen cpu as cool as possible and let amd firmware and pbo do their work

Agree with this assessment. It's from my personal experience with Zen2. I believe won't be far off for Zen3.

Fixed-clock OC is a minority group and let's hope it's an increasingly shrinking one. Most people if they OC, they're doing PBO+200MHz thing and tinkering associated parameters effecting AMD's boost algorithm.

While on stock settings, the boost algorithm works quite well in terms of stability. It's not so when it enters the territory of PBO+200MHz. The reason is very simple actually. If everyone can do, AMD would have included portion of this left-over performance in their stock settings from the factory and marketing such samples as better SKUs.

What I've been 'struggling' on & off is trying to bring my PBO+200MHz OC to absolute stability. It's unnecessarily wasted effort because of AMD marketing not being completely honest and documenting various knobs clearly. It's also jaw dropping that DIYPC consumers accept the status quo and even go the extra mile in praising AMD. lol. But such discussion is perhaps for another year..

So with PBO+200MHz OC, understandably everyone will have a different acceptance test. For casual workloads such as gaming, I believe it's fairly easy to get passed. I chose my test described in post #13 because it's a huge workload. Enabling SVM and working inside VM further stress Ryzen more than otherwise. And the test consistently failed on me and was easy (though take some time) to reproduce.

Gradually I found PPT, PTL, freq boost limit and etc all have some sort of effect on the stability of the boost algorithm. I won't jump to conclusion on their exact effect 'cos the algorithm is a blackbox and should be treated so.

What OP contributed to my journey is redirecting my attention back to TDC. Goodness me. I have zero idea why I punched in 68A. Think it through again it doesn't make sense at all. However, I still believe in TDC as a better control in suppressing the boost algorithm and hence higher stability. My initial trials said so and I'll report back how my journey ends.

 

[dansi]

Silicon Lottery store which was offering prebinned Intel and AMD CPUs is shutting down - VideoCardz.com

Silicon Lottery, a specialized webstore offering prebinned CPUs is shutting down After years of operation, prested and often delidded CPUs from Silicon Lottery are a thing of the past. Just a month away from Intel launching its Alder Lake processor series, the retailer announced that it is...

videocardz.com

silicon lottery.com is shutting down, another showcase why we should like the uefi firmware do its boost thing.

just max out the power available and keep your temps as low as possible

 

[sty]

So I'm back to square one with respect to my test described above. 'Calibrating TDC' has ZERO effect on the stability (or instability) of AMD's boost algorithm.

Let me also try to put a conclusion on OP's guide: don't waste your time. The same things can be achieved much simpler in multiple ways by limiting PPT, TDC, PTL, or PPL. Which limit you impose depends on your situation. If you have little idea, then go limiting TDC first.

To make myself a bit less miserable (of wasted time), I did learn some new bits: boost override (i.e. +xxx MHz), PBO Scalar, Vsoc, tRC, and tRFC are all linked in subtle ways when Zen2 (presumably also Zen3) is pushed to the edge through PBO. They affect the stability of the boost algorithm.

Can't emphasize once more: Don't overclock if you treasure your life. Spend 20% of the time reaping 80% of the reward if you can't resist.

Peace

 

[sty]

Now why did I bother to post my response?

Because I firmly believe there were bugs inside AMD's boost algorithm since zen2. If test hard enough, I believe most OC will run into errors that will be considered unstable to people who insist 100% error free under all types of workloads.

I ran into such a "bug" that I've been trying to workaround on & off since I built my R5 3600 system two years ago. The "bug" shows up under such conditions:

• ambient temperature near or above 30C
• some sort of PBO based OC striking a balance between maximum performance at an acceptable power cap
• stock memory speed i.e. JEDEC 2400/2666/2966 or 3200 that your sticks natively come with
• a guest VM (which OS doesn't matter) running under Linux host with QEMU KVM.

And the actual tests in guest VM:

• fire up LuxMark stress test (GPU only) and keep it running through out the test session
• run Prime95 128K FFT for 30mins
• run Prime95 7M to 8M FFT for one loop
• run Prime95 128K FFT for up to 60mins (N.B.: some threads will fail)

My result: anywhere between 10min to an hour (depending on how stable your OC were during the tests), one or more threads would die in the 2nd run of P95 128K FFT.

I think I eventually figured out a way to avoid such a failure. I only ran the P95 128K 2nd time up to 1.5hrs so I won't rule out I might still run into dying threads if I had run much longer. But for the number of times I tried and the duration I tested, I could no longer reproduce the issue. I considered my system 'absolutely' stable enough.

For anyone landing on this page from search engines, I want to provide an update and clear the name for AMD/Zen2/AGESA..

Recent failure of my previous workaround triggered me to look into the issue further and think outside the box this time round. The above test can reveal lots of different stability issues. But the final and lasting one on my personal list that I originally thought caused by AMD's boost algorithm or bugs in AGESA... turns out it's not true. It has nothing to do with AGESA, over boost, or PBO. I finally can pin point the issue reliably to potential bugs in the Linux hypervisor.

The culprit is partly my own making because I compile my own kernel in which hundreds and thousands of knobs to dial (and like many monkeys who like to touch & dial...) If I had stayed with stock kernel or stay on bare metal, I probably would never had stepped into the rabbit hole (twice now I realized and in different ways)!

Anyway, the issue has bugging me for over a year. I'm happy to see it gone.

May the zen be with you.

 

[johny_mnemonic]

I did FINALLY get one test back on an MSI board. It works but it requires a substantial amount of BIOS trickery and... well BS.

So it can be done but jeez! 0_o

Also, I've spent 3 weeks hammering this to death and it just doesn't fail. Finally, AMD's secret "formular" (Mr. Krabs) isn't so secret.

Thanks for taking time to tune this.

Would you share your findings on MSI boards? Another MSI B450M Mortar MAX owner here ;-)