Showing results for 
Search instead for 
Did you mean: 

X670 resource


ill use this thread to collect some new test bioses for the boards, maybe also to explain some less understood options

to disable cores ccd go here and choose ccd xx bit map down core.
each ones stand for an enabled core
best to disable from the back, ie:
instead of 0011000
after selection press downcore apply changes or discard if made mistake


7950x not boosting pass 5.5G -> check that CStates is not disabled
Detailed Explanation on CState Boot Limiter

Test BIOSes:

X3D OC Preset for those MB with asynch BCLK Support: (for simple slight perf boost for X3D)

DOCP/EXPO Tweaked: (for simple timings tightening)

strixe-e 1515 

strixe-f 1515 

strix e a 1515 

crosshair hero 1515 

crosshair gene 1515 

crosshair extreme 1515 

creator 670 1515

creator b650 1515

strix 650E I

strix 670 itx



for crosshair and strix e-e:

explanation of segment2 Loadline:


customize a heterogenous loadline for a dual segment workload range.

example above shows loadline=L6 when current is in range of 0~40A, and Level4 when current is above 40A.




Adds for x3d

dynamic ccd priority switch with core flex, os / driver agnostic so win10 win11 ok



Algo as follows:
If condition reached and ccd0 specified, then check current mem/cache activity > threshold and hysteresis reached, if fulfilled then switch
If condition reached and ccd1 specified, then check current mem/cache activity <=threshold and hysteresis reached,, if fulfilled then switch
Default hysteresis =4

Can combine multiple algos for ccd priority so combinations are wide

works on non x3d too but of course senseless on it. detailed explanation here.

2,404 REPLIES 2,404

I meant performance gap is almost same now with this bios. I had 29k cb23 score on 5950 and now on with 7950 i have 34k and when I revert to with same settings i have 39600 this new bios is junk.

New BIOS contains a fix from AMD for the inception security. In order for them to fix it, they had to hinder the performance of the CPU. Now the sad part is, they didn't exactly provide a way to turn that crap off. It's fixing something that affects nobody, edge case.

Go back to and wait for next AGESA which hopefully has an option to turn it off

Yeah I already did that, and waiting for improvment, or atleast ryzen 8000. Because I think this whole series 7000 and x670 is beta poligon for the next gen cpu.

Yes, I agree with that, it does feel like a paying beta program, that’s for sure.

How sure are you that your BIOS or more precisely the mitigations is the reason here? Do you know or do you have response from Cinebench programmers that this type of code is even affected by the mitigations?

These mitigations can of course cause performance degradation in some specific scenarios but they are not generally causing a drop of 15%. You describe your CB35 have dropped by about 15% from 39600 to 34000 around. On the other hand you are also claiming that this is basically equal to 29000 you got on Ryzen 5950 which is another drop of 15% which seems in this case to be negliable for you.

Also I can confirm that I am on X670-P with BIOS 1808 (AGESA and my cinebench scores on the 7950X are about 35600 using PBO cTDP 105W. To be honest I did not try 170W cTDP but it sounds unreasonable that you are not reaching my 105W results with a full 170W setup. So you might be actually suffering from another settings issue like different memory timings and not comparing apples-to-apples when it comes to other settings.

It's actually true that of course you can find very specific workload which is impacted heavily by those mitigations but the majority of use-cases. Also many people refer to articles like this one and ignoring the fact they tested worst-case scenarios. First of all picking only the worst out of the results (while many others did not show significant changes) and testing with IBPB mitigations known to be slowest - but default is "safe RET" and not IBPB. As well as you can turn the mitigations off by using mitigations=off on kernel option. Not running linux? well the benchmarks might not apply to your use-case then at all. You cna also read a more-detailed analysis using different workloads on phronix. Some relevant benchmarks for 3D Rendering (this is what you seem to do as you use CB23) are Blender or 3DMark which showed no significant impact by mitigations.

Also read the summary:

"For the most part users are unlikely to notice anything drastic, aside from some sizable database performance hits in a few cases.[...]For those wanting to avoid the new mitigation, there is always the "mitigations=off" route[...]"

Unfortunately these things are a bit complex to understand and we will see more people being virtually unaffected but whining about their gaming performance dropping by mitigations which are completely unrelated to their workload and not affecting it in any way. Sure, I can be wrong about your use case as you did not specify if you are running heavy database loads on your machine but if you do so then you know you can also use mitigations=off and on isolated developer machines it's entirely fine to do so.

With last Final 1709 and now last Beta Bios my RAM don't boot with EXPO 2. With 1516 working fine. When i enable first MCR then EXPO 2 boot but without MCR Bios boot in Safe Mode. The same issues i have with the first Biose for 1 year. EXPO 1 running normal with 1709 and Beta Bios, but EXPO 2 only run when enabled FIRST MCR. When i use EXPO 2 and enable after MCR Bios also boot in Safe Mode. I have the Strix E. My Ram with EXPO 2 see attachment.


I also did Corona 10  benchmark so I have to push cpu to the limits since 3d render is my job. So at 7950 is going (with my bios settings) to 5.35ghz all cores giving me 13,550,000 points. With with all the same settings, I have 12.400.000 points and cpu doesn't go above 5050mhz, I also tryed several variations of settings, different CO per core and all core, plus minus strong weak cores and nothing coudn't get what it was on previous version on bios. It's a very strange behavior and I dont know why, I had  similar problem on 5950 with performance degradation with stuttering and I solve that with tpm external chip.

Now with 1709 hat I can do 2200 FLCK on 8000MHz RAM instead of 2067, every benchmark I've tried tests better.

Like CB23 I gained about 120 points.

I am surprised by your results: I personally updated from 1516 to 1709 last Friday and did a lot of stability and performances tests this whole week-end.

For me, the performances ever so slightly improved with 1709 (like +1-2% for large software compilations with gcc or clang), and I got zero regression; the stability at high FCLK is also much better, as already reported in this thread. With 1516, I would not POST at 2100MHz and would crash from time to time with 2067MHz and therefore adopted 2000MHz only (for a 6000MT/s DDR5 OCed at 6200MT/s) for my stable settings; with 1709, I can POST at 2200MHz (and could also do an error-free full Memtest86+ run) but would not POST at 2233MHz, so I adopted 2133MHz for my stable settings (it's above the theoretically "ideal" 2067MHz (6200/3), but gives me ever so slightly better performances than the latter, so...).

As for the new mitigation in the microcode, it got strictly ZERO impact for me, with a Linux kernel compiled with all mitigations disabled, and here again I get 1-2% better results with 1709 than with 1516 (likely due to the higher FCLK) for CPU-heavy tasks (e.g. large software compilation); the key here is that as long as you do not enable the OS-side of the mitigations, you wont see ANY impact on the performances. The same holds true under Windows 11, e.g with Cinebench23 (R24 is less "sensitive" to slight performances deviations, mainly because R23 scores are counted in dozens of thousands instead of just thousands for R24), where I actually get slightly better scores (+200 or so), even with FCLK=2000MHz (i.e. all things equal when compared to 1516).

As I see it, your issues are likely due to an overdone overclocking, causing clock stretching to avoid crashes in the cores hitting too high a frequency for the provided Vcore. It is quite possible that AMD changed some parameters to improve the stability (how else would they have gained +200MHz on FCLK ?) and that, as a result, clock stretching happens "sooner" now with the new AGESA...

I have been tweaking my 7900X for 6 months now, and found out the following:

  1. On the 7900X, AMD apparently did a great job on adapting the VID table to the CCD0, but simply adopted a (rather large) "security margin" for CCD1; it means that as soon as I try and set a negative CO for any core on CCD0, I get stability issues at idle or medium loads (the more transitions in the load, the more likely you get crashes). On the other hand I can run all CCD1 cores at CO -24 without any stability issue whatsoever, which helps a great deal to get better CCD1 cores frequencies at full load (e.g. parallel compilations, Prime95, Cinebench, etc), and nicely improves the multi-cores perfs.
  2. You should not push "Max CPU Boost Clock Override" setting over +100MHz, or you will get crashes at medium or light loads under Windows (I had no such issue seen under Linux, even at +200MHz, but it was a few months ago, when the AMD P-state scheduler was not yet fully developed/optimized).
  3. The ASUS EFI is somewhat optimistic with max CPU core frequencies, and those are very sensitive to the ambient temperature, so it is best to set the max CPU core frequency individually and use a sane security margin when compared to was the ASUS EFI recommends: I use a 60MHz margin compared with ASUS' recommendations, at TA = 22°C.
  4. ASUS' "Core voltage suspension" helps avoiding too low a VID when using large COs (such as my -24 on CCD1): I use it in static mode, with a floor limit set at 0.950V; this avoid issues during transitions from low to light CPU loads and vice versa.
  5. For OCing close to the limits, you will get way better results with core C-states and package P-state disabled (this is not specific to AMD, and holds true as well with Intel CPUs): the less transitions, the less transitory states and voltage dropouts and overshoots in the CPU, the lowest the risks of crashes.
  6. For very high loads (e.g. Prime95 with AVX-512 and AVX-FMA3), using ASUS' dynamic overclocking (with adapted VID and frequency to match the maximum you can get under such loads from your CPU) helps a lot in getting higher frequencies and (ironically) lower heating: under Linux (which loads the CPU WAY more than Windows, while running Prime95; likely the result of a better scheduler and less time passed running its code in proportion of the Prime95 code), the CPU cores would normally (using PBO2 only) barely reach 4750MHz (Busy MHz, as measured by 'turbostat') for "Small FFTs" torture test and forcing FMA3 (which causes the highest heating/Amps with Zen4, much more than AVX-512; use "CpuSupportsAVX512F=0" in the local.txt file to force Prime95 to use FMA3 instead of  AVX-512),  while when you set a fixed clock, you can reach 4875MHz (or even 4900MHz, but then the core temps get too high for my taste: 100-105°C). I personally use a VID set at +50mv compared with what ASUS' EFI recommends for 4875MHz, and a switching current (137A) adjusted so that the EFI forces the fixed frequency mode as soon as the cores start dropping below 4900MHz in AVX-512 full load.
  7. ASUS "dynamic" overclocking does NOT play nice with Linux' latest "amd_prefcore" feature (which allows the AMD P-state driver to pick up the best performing core): as soon as the EFI switches back from the fixed core frequency mode to the PBO mode, you get a crash!... So, either do not use dynamic overclocking with Linux, or pass "amd_prefcore=disable" in the kernel command line (I do the latter)... Note that there is also a bug in ASUS "ec" sensors locking on the X670 HERO (the wrong lock is used, unlike what happens with the GENE and EXTREME); you must use the very latest Linux kernel implementing the corresponding fix to avoid race conditions due to bad locking, when EC sensors are read (e.g. for the VRM temperature reading).

Here are the settings I changed manually from the default (not listing peripheral-related ones, neither DRAM timings automatically changed via the EXPO setting):

Ai Overclock Tuner [EXPO Tweaked]
DOCP [DDR5-6000 36-38-38-80-1.35V-1.35V]
Memory Frequency [DDR5-6200MHz]
FCLK Frequency [2133 MHz]
Core VID [1.155]
CCX0 Ratio [48.75]
CCX0 Ratio [48.75]
Dynamic OC Switcher [Enabled]
Current Threshold to Switch to OC Mode [137]
Calibrated Temperature Threshold to switch back [87]
Hysteresis [4]
Power Down Enable [Enabled]
Memory Context Restore [Enabled]
Prochot VRM Throttling [Disable]
Medium Load Boostit [Enabled]
Precision Boost Overdrive [Enabled]
Precision Boost Overdrive Scalar [Manual]
Customized Precision Boost Overdrive Scalar [1x]
CPU Boost Clock Override [Enabled (Positive)]
Max CPU Boost Clock Override(+) [100]
Per-Core Boost Clock Limit [Enabled]
Core 0 [5744]
Core 1 [5744]
Core 2 [5766]
Core 3 [5722]
Core 4 [5766]
Core 5 [5766]
Core 6 [5386]
Core 7 [5430]
Core 8 [5364]
Core 9 [5408]
Core 10 [5452]
Core 11 [5386]
Curve Optimizer [Per Core]
Core 0 Curve Optimizer Sign [Negative]
Core 0 Curve Optimizer Magnitude [0]
Core 1 Curve Optimizer Sign [Negative]
Core 1 Curve Optimizer Magnitude [0]
Core 2 Curve Optimizer Sign [Negative]
Core 2 Curve Optimizer Magnitude [0]
Core 3 Curve Optimizer Sign [Negative]
Core 3 Curve Optimizer Magnitude [0]
Core 4 Curve Optimizer Sign [Negative]
Core 4 Curve Optimizer Magnitude [0]
Core 5 Curve Optimizer Sign [Negative]
Core 5 Curve Optimizer Magnitude [0]
Core 6 Curve Optimizer Sign [Negative]
Core 6 Curve Optimizer Magnitude [24]
Core 7 Curve Optimizer Sign [Negative]
Core 7 Curve Optimizer Magnitude [24]
Core 8 Curve Optimizer Sign [Negative]
Core 8 Curve Optimizer Magnitude [24]
Core 9 Curve Optimizer Sign [Negative]
Core 9 Curve Optimizer Magnitude [24]
Core 10 Curve Optimizer Sign [Negative]
Core 10 Curve Optimizer Magnitude [24]
Core 11 Curve Optimizer Sign [Negative]
Core 11 Curve Optimizer Magnitude [24]
CPU Load-line Calibration [Level 5:Recommended for OC]
Segment2 Loadline [Disabled]
Core Voltage Suspension [Enabled]
Voltage Floor Mode [Static]
Voltage floor [0.95000]
Voltage ceiling Mode [Static]
Voltage ceiling [1.50000]
CPU VRM Switching Frequency [Manual]
Fixed CPU VRM Switching Frequency(KHz) [750]
CPU Power Duty Control [Extreme]
CPU Power Phase Control [Extreme]
VDDSOC Power Phase Control [Extreme]
Performance Bias [None]
Clock Spread Spectrum [Disabled]
CPU PCIE ASPM Mode Control [Disabled]
Integrated Graphics [Disabled]
Global C-state Control [Disabled]
L1 Stream HW Prefetcher [Enable]
L2 Stream HW Prefetcher [Enable]
L1 Stride Prefetcher [Enable]
L1 Region Prefetcher [Enable]
L1 Burst Prefetch Mode [Enable]
L2 Up/Down Prefetcher [Enable]
Power Supply Idle Control [Typical Current Idle]
Opcache Control [Enabled]
Streaming Stores Control [Enabled]
SMU and PSP Debug Mode [Enabled]
Fast Short REP MOVSB (FSRM) [Enabled]
SMEE [Disable]
AVX512 [Enabled]
Corrector Branch Predictor [Enabled]
PAUSE Delay [16 Cycles]
CPU Speculative Store Modes [Blanced]
ACPI SRAT L3 Cache As NUMA Domain [Disabled]
Disable DF to external downstream IP Sync Flood Propagation [Sync flood disabled]
Disable DF sync flood propagation [Sync flood disabled]
GFXOFF [Enable]
SoC/Uncore OC Mode [Enabled]

And here is the result with Geekbench v6.2 under Linux.

I'm also happy that ASUS 1709 EFI now trains faster (only one training, instead of two in a raw for 12xx-16xx EFIs), and only when actually needed (like 1101 did), i.e. only when a timing/voltage/frequency setting that could affect the RAM training has been changed.

However, still no luck with DRAM power down disabling and memory context restore enabled: that's too bad, because PD does bring a (slight but measurable) perfs gain, but I'm not ready to endure 50 more seconds of waiting each time I reboot the computer with MCR disabled!

Hi, your settings are great, can you please give me the specific settings for the 7950X3D processor ?

Hi have the ROG CROSSHAIR X670E HERO mobo with bios 1801 installed but I don't find where in the menus I can these settings:

DOCP [DDR5-6000 36-38-38-80-1.35V-1.35V]
Core VID [1.155]
CCX0 Ratio [48.75]
CCX0 Ratio [48.75]
Dynamic OC Switcher [Enabled]
Current Threshold to Switch to OC Mode [137]
Calibrated Temperature Threshold to switch back [87]
Hysteresis [4]

Could you please help me ?

Thanks a lot in advance.