All equipment in my testing is my own, none is given to me or provided to me by a company. I choose combo of HW based on my needs and budget.
I am just an owner, no professional qualification or job in field of discussion.
I am just an owner, no professional qualification or job in field of discussion.
Last update:
06/04/2025
Last changes:
Updated section CO profile stability testing
Added section Articles Links
Added extra text section What is the CO value we set doing?
Added extra screen shot in section Power limits
Moved and updated section How to see best cores in HWINFO
Updated section My basic settings on ASUS boards
I do not have all the answers on topic
.I am posting this thread to put some information in one thread rather then spread across few here and there
.I am sharing what has worked for me
.Everything need to know
The CPU has a single power plane, only when a single core is loaded the core voltage can be seen, when multiple cores are loaded the highest voltage request is used.
Final voltage may depend on cache as well.
We know on 5800X3D Robert Hallock said OC was locked due to cache not sustaining high voltage that cores may use, again pointing to cores/cache use same voltage.
Then we also have IgorLAB killing a 5800X3D with high core voltage.
On 5000 series in HWINFO there was an effective VID sensor, on AM5 there isn't. I used CPU voltage SVI3 on both platforms. Based on The Stilt's insight, I thought how could I make CO per core work as optimal as possible, be repeatable process to use, so I came up with matching the voltages between the cores, core voltage harmonization. This worked well with multiple AM4 CPUs I used and has also worked on AM5, I also do not run into the binder effect that The Stilt highlighted.
This is my own method.
Simply put the process is closely match each core voltage to best core voltage, then deepen CO, check voltages and retune CO if needed. See the video below, I will improve and upload new one soon.
The wording is wrong in above quote of The Stilt, you can see in his Ryzen 1000 series post that dLDO are on die but disabled.
On AM5 it is still as past gens.
Quote from Skatterbencher RPL guide.
Final voltage may depend on cache as well.
Quote from Martin Malik writer of HWINFO.
We know on 5800X3D Robert Hallock said OC was locked due to cache not sustaining high voltage that cores may use, again pointing to cores/cache use same voltage.
Quote source TPU article.
Then we also have IgorLAB killing a 5800X3D with high core voltage.
Next there is a binder effect that we may see when do CO per core. When I got my R9 5900X I asked The Stilt for insight and he stated:-
I posted this twice, first in 5900X owners thread and 5800X3D owners thread, couple of years later members discuss The Stilt's share which had been stated before.
On 5000 series in HWINFO there was an effective VID sensor, on AM5 there isn't. I used CPU voltage SVI3 on both platforms. Based on The Stilt's insight, I thought how could I make CO per core work as optimal as possible, be repeatable process to use, so I came up with matching the voltages between the cores, core voltage harmonization. This worked well with multiple AM4 CPUs I used and has also worked on AM5, I also do not run into the binder effect that The Stilt highlighted.
This is my own method.
Simply put the process is closely match each core voltage to best core voltage, then deepen CO, check voltages and retune CO if needed. See the video below, I will improve and upload new one soon.
What is the CO value we set doing?
The CO value we set tweaks how the CPU SMU (System Management Unit) profiles the core. CPU SMU decides frequency and determines voltage. Simply put think of it as changing how the CPU SMU perceives the "Quality" of the core. Better cores need less of a CO value change, worse cores need a bigger change.
Say I have a core that is reaching ~ 5400MHz on a 9600X, lets say voltage is ~1.3V. I set a -5 CO on just that core. Lets say the CPU does ~5425MHz after adjustment, the SMU may decide to still give ~1.3V, as core clock increased.
Then you readjust CO to say -8 on that core only, you may see ~5450MHz, the SMU may decide to still give it ~1.3V, as core reached FMAX.
Then you readjust CO to say -10 on that core only, you will continue to see ~5450MHz, but now the SMU will start dropping voltage, to say ~1.29V. Now further reduction of CO value will keep yielding voltage drop, whilst sustaining MAX core clock.
Above are generalisations to explain CO magnitude.
At stock FMAX, clocks reach FMAX sooner, so going deeper on CO gets power and temperature lower.
At +200MHz FMAX, when CO is not deep, CPU gets boost increase, not a big voltage drop. So CO change is acting like a core "Quality" change, making the CPU SMU improve boost. The voltage drop comes later as CO gets deep, when CPU clock start reaching FMAX.
Below is a comparative of two differing 9600X, rest of the HW same in use, same method of tweaking CO, etc. The better cores tend to use lower CO magnitudes, as they tend to (and or) boost higher/lower voltage at stock. This fits in with my observations stated above on what CO magnitude value is.
Now reference this table of data also, stock FMAX and +200MHz. You will see until CO gets deep on +200MHz, voltage does not drop, highlighting the two fold function of CO magnitude. Changes to CO make the CPU SMU adjust clocks and voltage, like it is a better "Quality" core.
Say I have a core that is reaching ~ 5400MHz on a 9600X, lets say voltage is ~1.3V. I set a -5 CO on just that core. Lets say the CPU does ~5425MHz after adjustment, the SMU may decide to still give ~1.3V, as core clock increased.
Then you readjust CO to say -8 on that core only, you may see ~5450MHz, the SMU may decide to still give it ~1.3V, as core reached FMAX.
Then you readjust CO to say -10 on that core only, you will continue to see ~5450MHz, but now the SMU will start dropping voltage, to say ~1.29V. Now further reduction of CO value will keep yielding voltage drop, whilst sustaining MAX core clock.
Above are generalisations to explain CO magnitude.
At stock FMAX, clocks reach FMAX sooner, so going deeper on CO gets power and temperature lower.
At +200MHz FMAX, when CO is not deep, CPU gets boost increase, not a big voltage drop. So CO change is acting like a core "Quality" change, making the CPU SMU improve boost. The voltage drop comes later as CO gets deep, when CPU clock start reaching FMAX.
Below is a comparative of two differing 9600X, rest of the HW same in use, same method of tweaking CO, etc. The better cores tend to use lower CO magnitudes, as they tend to (and or) boost higher/lower voltage at stock. This fits in with my observations stated above on what CO magnitude value is.
Even though I have VID shown, I reference CPU VDDCR_VDD Voltage (SVI3 TFN), as this is from CPU telemetry.
![Text Number Font Screenshot Design]()
Now reference this table of data also, stock FMAX and +200MHz. You will see until CO gets deep on +200MHz, voltage does not drop, highlighting the two fold function of CO magnitude. Changes to CO make the CPU SMU adjust clocks and voltage, like it is a better "Quality" core.
This was the first AM5 CPU I did CO per core on. The purpose of the data collection was to see what happens when same CO is used with FMAX +200MHz applied. Looking at the data it became evident to only do +200MHz on a deep CO as then CPU clock is close to FMAX and voltages align better.
At Level 3 +200MHz best core is still lowest voltage, but on level 4 +200MHz I retune other cores, leave core 3 and core 1 becomes lowest voltage, this highlighted to me it is better to increase FMAX only when CO is deep.
Even though I have VID shown, I reference CPU VDDCR_VDD Voltage (SVI3 TFN), as this is from CPU telemetry.
![White]()
At Level 3 +200MHz best core is still lowest voltage, but on level 4 +200MHz I retune other cores, leave core 3 and core 1 becomes lowest voltage, this highlighted to me it is better to increase FMAX only when CO is deep.
Even though I have VID shown, I reference CPU VDDCR_VDD Voltage (SVI3 TFN), as this is from CPU telemetry.
How to see best cores in HWINFO
Each cores perf# can be see in HWINFO, also see tool tip for further information.
![Font Number Screenshot Technology Software]()
In below screens shot of HWINFO it shows CPPC order. CPPC numbering of cores differs. It does not start at 0. CPPC order 5, 6, 3, 1, 7, 4, 2, 8, means best to worst core order is 4, 5, 2, 0, 6, 3, 1, 7. CPPC core number just do -1 to make it as core numbering on sensors page.
Right click in CPU-Z over socket shows only best two cores info only.
![Software Number Technology Screenshot Video Game Software]()
In below screens shot of HWINFO it shows CPPC order. CPPC numbering of cores differs. It does not start at 0. CPPC order 5, 6, 3, 1, 7, 4, 2, 8, means best to worst core order is 4, 5, 2, 0, 6, 3, 1, 7. CPPC core number just do -1 to make it as core numbering on sensors page.
Right click in CPU-Z over socket shows only best two cores info only.
How I do CO per core tuning
In HWINFO I save my original setup, so I can go back to it with ease after doing CO profiling.
![Text Screenshot Font Number Software]()
Next in HWINFO I trim down sensors to observe what I want for when doing CO tuning, right click a sensor and select hide (keyboard shortcut Shift+Del).
Why I would trim down sensors, as I increase polling interval, too many sensors being read in short period may cause issues, create an overhead, etc.
Even though I have VID shown and VRM VCORE, I reference CPU VDDCR_VDD Voltage (SVI3 TFN), as this is from CPU telemetry.
![Font Number Software Technology Screenshot]()
I set a fast polling interval in HWINFO, 250ms is what I use for CO profiling.
![Text Screenshot Font Number Software]()
I did test what was better to use Snapshot mode or normal, I preferred Snapshot mode. There are two methods of enabling it, either when you open program and click settings or from sensors page (shown in spoiler below).
![White Text Screenshot Font Software]()
I save my setup of HWINFO for CO tuning. I can then flip back to CO setup of HWINFO or normal setup using the saved setting files.
Depending upon how customized HWINFO was, restoring settings may not work until you Reset Preferences, then apply saved custom settings file.
![Text Screenshot Font Number Software]()
When I go back to normal setup of HWINFO, I adjust polling interval, normally I use 500ms instead of default 2000ms.
Next in HWINFO I trim down sensors to observe what I want for when doing CO tuning, right click a sensor and select hide (keyboard shortcut Shift+Del).
Why I would trim down sensors, as I increase polling interval, too many sensors being read in short period may cause issues, create an overhead, etc.
Even though I have VID shown and VRM VCORE, I reference CPU VDDCR_VDD Voltage (SVI3 TFN), as this is from CPU telemetry.
I set a fast polling interval in HWINFO, 250ms is what I use for CO profiling.
I did test what was better to use Snapshot mode or normal, I preferred Snapshot mode. There are two methods of enabling it, either when you open program and click settings or from sensors page (shown in spoiler below).
I save my setup of HWINFO for CO tuning. I can then flip back to CO setup of HWINFO or normal setup using the saved setting files.
Depending upon how customized HWINFO was, restoring settings may not work until you Reset Preferences, then apply saved custom settings file.
When I go back to normal setup of HWINFO, I adjust polling interval, normally I use 500ms instead of default 2000ms.
I have been using Statuscore as test load to see MHz/voltage per core and tune CO for setups to stability test.
I check a core loaded with one thread, please see this ZIP has screenshots of me testing each core at stock.
When profiling CPU for CO, use same test load, as CPU behavior can change based on what is loading it.
I load a core with Statuscore, wait a second or two, then zero HWINFO sensors, wait ~30 seconds and capture screenshot, unload the core, save screenshot, load a differing core and "repeat and rinse" process.
I end up with data like below.
R5 9600X on TUF X670E, UEFI 3202 AGESA 1.2.0.3a
Take away from table of data, the better cores may have higher clocks, lower voltage. Worse cores may have lower clocks and higher voltage. Looking at the table there will be cores which take similar CO offset to harmonize voltage.
![Software Font Graphics software Technology Multimedia Software]()
Now I start tweaking the higher voltage cores to lower voltage. I used SMU Debug Tool to change CO profile.
Adjust a core's CO when CPU is not under load, press apply button, load that core with Statuscore, wait a second or two, then zero HWINFO sensors, wait ~15 to 30 seconds, observe the core clocks/voltage, unload the core and re adjust core CO again.
Be mindful of two things when tweaking CO, as said by The Stilt cores can bind, plus voltage maybe staying the same as a poor core is gaining clocks, thus SMU setting same voltage, but you will see a point where the core clock has gain, but voltage is then dropping. I will add this profiling to OP as soon as I can to show it, for now check section What is the CO value we set doing?.
I find it easier at this stage to just target to set CO so all voltages for cores are similar to the lowest voltage seen in stock profiling done in above table. Core 3 at stock had ~1.290V when loaded with one thread from Statuscore, so I set CO per core to match Core 3.
So I end up with something like below.
All clocks are maximized, voltage is harmonized, here is ZIP of screenshots.
![Software Graphics software Font Technology Screenshot]()
Now if I want the CPU to have further reduced voltage, I deepen the CO profile globally. So my level 2 CO profile is level 1 values negative 6 per core. What number you deepen by globally is your choice, mine is just an example.
![Graphics software Software Font Technology Multimedia Software]()
CB23 MC stock 16449 points
CB23 MC CO tweak level 1 16802 points
CB23 MC CO tweak level 2 17039 points
The gains in multicore benchmark is from reduction in CPU voltage, creating headroom within power budget for the boost algorithm to sustain higher muticore clocks within stock power limit of CPU. For all three of the results, I saw same max power draw from wall plug meter.
If you are raising CPU max clocks using FMAX option, I would first get voltages at stock, as I think it's easier to identify best cores and cores which may take similar CO value and see the CO per core curve. I would set increased FMAX only when you have a deep CO per core profile, otherwise the voltages boost too high and it is hard to make sense of how to set CO per core.
When you increase FMAX, you may not see a voltage drop with less deep CO. Until effective clocks have reached FMAX or close to it, the CPU SMU (System Management Unit) will keep voltage high as clocks are rising, there will be a point were clocks have risen as much as CPU SMU thinks a core will do, then voltage drop occurs with further CO tweaking. Again this is a generalization, each CPU due to silicon variance and what boost clock it is, behavior can be slightly differing.
Some CPUs like say the 5700X3D, which has a lower boost frequency, but stock power limit like a higher clocked version (5800X3D). You may see extremely small gains in sustained multicore clocks/performance gain, but you may see a drop in power usage and temperature.
5700X3D testing ZIP link, organise by time to see order of testing.
CB23 multicore was test load, power reading is HWINFO CPU package power average reading.
The per core CO value is very close on the 5700X3D I had, compared with say several 5900X/5800X3D I had done CO per core. As boost frequency is lower on 5700X3D then other mentioned CPUs, in my opinion boost is in a zone where cores are very similar for voltage requirement for clock.
Some graphs:-
Stock vs -10 all cores vs -20 all cores, link.
Stock vs -30 all cores vs CO per core, link.
Stock vs -30 all cores vs CO per core +4, link.
Link to Generic Log Viewer, used to create graphs, great app IMO.
Even though CO -30 all cores results in maximum lowering of power/temperature, stability may not be ideal. Per core CO tuning can give similar results, with enhanced stability.
I check a core loaded with one thread, please see this ZIP has screenshots of me testing each core at stock.
When profiling CPU for CO, use same test load, as CPU behavior can change based on what is loading it.
I load a core with Statuscore, wait a second or two, then zero HWINFO sensors, wait ~30 seconds and capture screenshot, unload the core, save screenshot, load a differing core and "repeat and rinse" process.
I end up with data like below.
R5 9600X on TUF X670E, UEFI 3202 AGESA 1.2.0.3a
Even though I have VID shown, I reference CPU VDDCR_VDD Voltage (SVI3 TFN), as this is from CPU telemetry.
| Clock | Eff.Clock | VID | SVI3 | |
| Core 0 (#3) | 5434MHz | 5451MHz | 1.352V | 1.362V |
| Core 1 (#1) | 5449MHz | 5463MHz | 1.310V | 1.318V |
| Core 2 (#2) | 5449MHz | 5467MHz | 1.345V | 1.354V |
| Core 3 (#1) | 5450MHz | 5466MHz | 1.290V | 1.298V |
| Core 4 (#4) | 5394MHz | 5411MHz | 1.349V | 1.355V |
| Core 5 (#5) | 5398MHz | 5416MHz | 1.350V | 1.362V |
Take away from table of data, the better cores may have higher clocks, lower voltage. Worse cores may have lower clocks and higher voltage. Looking at the table there will be cores which take similar CO offset to harmonize voltage.
Now I start tweaking the higher voltage cores to lower voltage. I used SMU Debug Tool to change CO profile.
Use PBO tab. Left side adjust CO, top right use Apply. FMAX adjustment is bottom left, use Apply bottom right.
![Red Font Screenshot Number Software]()
Adjust a core's CO when CPU is not under load, press apply button, load that core with Statuscore, wait a second or two, then zero HWINFO sensors, wait ~15 to 30 seconds, observe the core clocks/voltage, unload the core and re adjust core CO again.
Be mindful of two things when tweaking CO, as said by The Stilt cores can bind, plus voltage maybe staying the same as a poor core is gaining clocks, thus SMU setting same voltage, but you will see a point where the core clock has gain, but voltage is then dropping. I will add this profiling to OP as soon as I can to show it, for now check section What is the CO value we set doing?.
I find it easier at this stage to just target to set CO so all voltages for cores are similar to the lowest voltage seen in stock profiling done in above table. Core 3 at stock had ~1.290V when loaded with one thread from Statuscore, so I set CO per core to match Core 3.
So I end up with something like below.
Even though I have VID shown, I reference CPU VDDCR_VDD Voltage (SVI3 TFN), as this is from CPU telemetry.
| Level 1 | Clock | Eff.Clock | VID | SVI3 |
| Core 0 (-10) | 5450MHz | 5466MHz | 1.293V | 1.300V |
| Core 1 (-3) | 5450MHz | 5465MHz | 1.290V | 1.297V |
| Core 2 (-7) | 5450MHz | 5467MHz | 1.290V | 1.297V |
| Core 3 (0) | 5450MHz | 5466MHz | 1.290V | 1.298V |
| Core 4 (-14) | 5450MHz | 5467MHz | 1.293V | 1.301V |
| Core 5 (-15) | 5450MHz | 5467MHz | 1.292V | 1.300V |
All clocks are maximized, voltage is harmonized, here is ZIP of screenshots.
Now if I want the CPU to have further reduced voltage, I deepen the CO profile globally. So my level 2 CO profile is level 1 values negative 6 per core. What number you deepen by globally is your choice, mine is just an example.
Even though I have VID shown, I reference CPU VDDCR_VDD Voltage (SVI3 TFN), as this is from CPU telemetry.
| Level 2 | Clock | Eff.Clock | VID | SVI3 |
| Core 0 (-16) | 5450MHz | 5466MHz | 1.254V | 1.264V |
| Core 1 (-9) | 5450MHz | 5464MHz | 1.254V | 1.264V |
| Core 2 (-13) | 5450MHz | 5468MHz | 1.254V | 1.264V |
| Core 3 (-6) | 5450MHz | 5466MHz | 1.252V | 1.263V |
| Core 4 (-20) | 5450MHz | 5467MHz | 1.256V | 1.263V |
| Core 5 (-21) | 5450MHz | 5465MHz | 1.255V | 1.264V |
CB23 MC stock 16449 points
CB23 MC CO tweak level 1 16802 points
CB23 MC CO tweak level 2 17039 points
The gains in multicore benchmark is from reduction in CPU voltage, creating headroom within power budget for the boost algorithm to sustain higher muticore clocks within stock power limit of CPU. For all three of the results, I saw same max power draw from wall plug meter.
If you are raising CPU max clocks using FMAX option, I would first get voltages at stock, as I think it's easier to identify best cores and cores which may take similar CO value and see the CO per core curve. I would set increased FMAX only when you have a deep CO per core profile, otherwise the voltages boost too high and it is hard to make sense of how to set CO per core.
When you increase FMAX, you may not see a voltage drop with less deep CO. Until effective clocks have reached FMAX or close to it, the CPU SMU (System Management Unit) will keep voltage high as clocks are rising, there will be a point were clocks have risen as much as CPU SMU thinks a core will do, then voltage drop occurs with further CO tweaking. Again this is a generalization, each CPU due to silicon variance and what boost clock it is, behavior can be slightly differing.
Some CPUs like say the 5700X3D, which has a lower boost frequency, but stock power limit like a higher clocked version (5800X3D). You may see extremely small gains in sustained multicore clocks/performance gain, but you may see a drop in power usage and temperature.
5700X3D testing ZIP link, organise by time to see order of testing.
CB23 multicore was test load, power reading is HWINFO CPU package power average reading.
| Stock | ~100.5W |
| -10 all cores | ~92.9W |
| -20 all cores | ~86W |
| -30 all cores | ~78.5W |
| CO Profile per core | |
| -21 -21 -23 -24 -23 -23 -24 -24 | ~83.3W |
| -22 -22 -24 -25 -24 -24 -25 -25 | ~82.4W |
| -23 -23 -25 -26 -25 -25 -26 -26 | ~82.1W |
| -24 -24 -26 -27 -26 -26 -27 -27 | ~81.4W |
| -25 -25 -27 -28 -27 -27 -28 -28 | ~81.1W |
The per core CO value is very close on the 5700X3D I had, compared with say several 5900X/5800X3D I had done CO per core. As boost frequency is lower on 5700X3D then other mentioned CPUs, in my opinion boost is in a zone where cores are very similar for voltage requirement for clock.
Some graphs:-
Stock vs -10 all cores vs -20 all cores, link.
Stock vs -30 all cores vs CO per core, link.
Stock vs -30 all cores vs CO per core +4, link.
Link to Generic Log Viewer, used to create graphs, great app IMO.
Even though CO -30 all cores results in maximum lowering of power/temperature, stability may not be ideal. Per core CO tuning can give similar results, with enhanced stability.
CO profile stability testing
On the 9600X I have, MAX CO per core CB23 MC result is ~18862. I call this MAX as two of the cores have reached 50, if I adjust any of the other cores to say up to 50 I may gain tiny bit more performance, but I will lose per core voltage harmonization.
![Software Graphics software Font Technology Multimedia Software]()
A profile like above where some cores have hit MAX negative CO, in my experience from past AM4 CPUs, may not be stable in stability tests.
So I rolled CO profile globally few ticks back from MAX CO per core. This CO profile is ~18778 in CB23 MC.
![Software Font Graphics software Technology Screenshot]()
Below is clock/voltage per core, test load Statuscore.
Next ZIP of stability testing, sort files by time to which test I ran when. I didn't test a single test for lots of hours, as wanted to test multiple loads.
1. CoreCycler P95 PASS 12hrs.
2. CoreCycler Y-Cruncher PASS 6hrs.
3. Standard Y-Cruncher stress test 15min, 80C temp, cTDP 105W.
Screenshot of standard Y-Cruncher stress test, CO profile cTDP 105W temperature limit 95C (HWINFO CSV in ZIP). BBP really hammers CPU on all cores load.
![Number Technology Screenshot Software Video Game Software]()
I should have continued on UEFI 3202, but as 3203 had been released I wanted to use it. UEFI 3203 is same AGESA (1.2.0.3a) and same SMU FW as UEFI 3202. I can only assume 3203 only has fixes on ASUS side of FW.
I also started using a 6000C28 RAM profile with CO profile.
4. CoreCycler Y-Cruncher, cTDP 105W, PASS 3.5hrs.
5. CoreCycler AIDA64 CPU, CACHE, FPU, cTDP 105W, PASS 10.5hrs.
6. Standard Y-Cruncher stress test, 80C temp, cTDP 105W, PASS 6hrs.
7. RealBench stress mode, 16GB, 80C temp, cTDP 105W, PASS 1hr.
8. Kahru RAM Test, Cache Enabled, 80C temp, cTDP 105W, PASS 5k%.
9. AIDA64 CPU SHA3 80C temp, cTDP 105W, PASS 15min (seen mention of this in threads as a thing to do, significance no idea, had no issues running it).
10. Kahru RAM Test CACHE + FPU, 80C temp, cTDP 105W, PASS 21k% (link to ZIP)
Realbench was run as it hits CPU/RAM/GPU and I wanted to test more of the system in use.
As CPU clock increases, CPU cache clock increases as well.
![Text Software Font Screenshot Technology]()
Kahru RAM Test loading CPU, red line is stock CPU, green line is CO profile, same 6000C28 RAM profile in use.
![Font Screenshot Software]()
Below spoiler some other setups with same CO profile plus stock with TDP changes.
There is a filename in ZIP CO L8.1 cTDP 105W 95C 60C28 v1.7.5l CB23 MC 18743.jpg, you will see power limits are not hit on CO profile in CB23, it's temperature limit that causes slight loss of performance.
ZIP now has CO per core set in BIOS Statuscore screenshots, CB23 SC MC result, BIOS settings dump txt. The CB23 single core was best run I seen so far, don't know if setting by UEFI had effect, as before any runs CO been set via SW.
After having done more 9000 series CPUs I have come to conclusion one test load does not guarantee stability for me in other test loads. So I'm concluding do various test loads, short run, then make run longer per test load. In this post is information where a profile had passed various things but showed failure in others.
Here is a log of stability testing on my 9800X3D with 2x16GB SK Hynix A die 6200C28 2200MHz FCLK. I had done quite a lot and when did Y-Cruncher default stress test it showed I needed a setting change, then TM5 showed again to sustain FCLK I needed to bump VDDG. One test does not fully cover aspects of CPU, multiple test loads are only way, even gaming, idling, using the computer for normal purposes, testing after resume from sleep, are all valid testing.
A profile like above where some cores have hit MAX negative CO, in my experience from past AM4 CPUs, may not be stable in stability tests.
So I rolled CO profile globally few ticks back from MAX CO per core. This CO profile is ~18778 in CB23 MC.
Below is clock/voltage per core, test load Statuscore.
Even though I have VID shown, I reference CPU VDDCR_VDD Voltage (SVI3 TFN), as this is from CPU telemetry.
| Level 8.1 | Clock | Eff.Clock | VID | SVI3 |
|---|---|---|---|---|
| Core 0 (-38) | 5650MHz | 5666MHz | 1.326V | 1.337V |
| Core 1 (-27) | 5649MHz | 5662MHz | 1.324V | 1.334V |
| Core 2 (-35) | 5649MHz | 5665MHz | 1.322V | 1.331V |
| Core 3 (-24) | 5645MHz | 5660MHz | 1.321V | 1.335V |
| Core 4 (-47) | 5649MHz | 5665MHz | 1.321V | 1.330V |
| Core 5 (-47) | 5650MHz | 5663MHz | 1.324V | 1.332V |
Next ZIP of stability testing, sort files by time to which test I ran when. I didn't test a single test for lots of hours, as wanted to test multiple loads.
1. CoreCycler P95 PASS 12hrs.
2. CoreCycler Y-Cruncher PASS 6hrs.
3. Standard Y-Cruncher stress test 15min, 80C temp, cTDP 105W.
Screenshot of standard Y-Cruncher stress test, CO profile cTDP 105W temperature limit 95C (HWINFO CSV in ZIP). BBP really hammers CPU on all cores load.
I should have continued on UEFI 3202, but as 3203 had been released I wanted to use it. UEFI 3203 is same AGESA (1.2.0.3a) and same SMU FW as UEFI 3202. I can only assume 3203 only has fixes on ASUS side of FW.
I also started using a 6000C28 RAM profile with CO profile.
4. CoreCycler Y-Cruncher, cTDP 105W, PASS 3.5hrs.
5. CoreCycler AIDA64 CPU, CACHE, FPU, cTDP 105W, PASS 10.5hrs.
6. Standard Y-Cruncher stress test, 80C temp, cTDP 105W, PASS 6hrs.
7. RealBench stress mode, 16GB, 80C temp, cTDP 105W, PASS 1hr.
8. Kahru RAM Test, Cache Enabled, 80C temp, cTDP 105W, PASS 5k%.
9. AIDA64 CPU SHA3 80C temp, cTDP 105W, PASS 15min (seen mention of this in threads as a thing to do, significance no idea, had no issues running it).
10. Kahru RAM Test CACHE + FPU, 80C temp, cTDP 105W, PASS 21k% (link to ZIP)
Realbench was run as it hits CPU/RAM/GPU and I wanted to test more of the system in use.
As CPU clock increases, CPU cache clock increases as well.
Kahru RAM Test loading CPU, red line is stock CPU, green line is CO profile, same 6000C28 RAM profile in use.
Below spoiler some other setups with same CO profile plus stock with TDP changes.
| UEFI | CO Profile | RAM Profile | cTDP | Temp.Limit | CB23 result |
|---|---|---|---|---|---|
| 3202 | Stock CPU | 4800C40 | cTDP 88W | 95C | 16449 |
| 3202 | Stock CPU | 4800C40 | cTDP 105W | 95C | 17772 |
| 3202 | Stock CPU | 4800C40 | cTDP 170W | 95C | 17730 |
| 3202 | L8.1 | 4800C40 | cTDP 170W | 95C | 18778 |
| 3203 | L8.1 | 4800C40 | cTDP 105W | 80C | 18702 |
| 3203 | L8.1 | 6000C28 | cTDP 105W | 80C | 18833 |
| 3203 | L8.1 | 6000C28 | cTDP 105W | 95C | 18861 |
There is a filename in ZIP CO L8.1 cTDP 105W 95C 60C28 v1.7.5l CB23 MC 18743.jpg, you will see power limits are not hit on CO profile in CB23, it's temperature limit that causes slight loss of performance.
ZIP now has CO per core set in BIOS Statuscore screenshots, CB23 SC MC result, BIOS settings dump txt. The CB23 single core was best run I seen so far, don't know if setting by UEFI had effect, as before any runs CO been set via SW.
After having done more 9000 series CPUs I have come to conclusion one test load does not guarantee stability for me in other test loads. So I'm concluding do various test loads, short run, then make run longer per test load. In this post is information where a profile had passed various things but showed failure in others.
Here is a log of stability testing on my 9800X3D with 2x16GB SK Hynix A die 6200C28 2200MHz FCLK. I had done quite a lot and when did Y-Cruncher default stress test it showed I needed a setting change, then TM5 showed again to sustain FCLK I needed to bump VDDG. One test does not fully cover aspects of CPU, multiple test loads are only way, even gaming, idling, using the computer for normal purposes, testing after resume from sleep, are all valid testing.
Without PBO CO OC RAM/FCLK profile passed ~33k Kahru RAM Test, besides LinpackXtreme and other tests.
With PBO CO OC:-
UEFI 2804
~8hrs AIDA64 CPU FPU CACHE
~8hrs Y-Cruncher default Stress test (Required FCLK VDCI Predicative, VDDG CCD/IOD: 920mV)
~24hrs CoreCycler P95
~24hrs CoreCycler AIDA64 CPU FPU CACHE
~24hrs CoreCycler Y-Cruncher
UEFI 2806
~3hrs TM5 1usmus (Required VDDG CCD/IOD: 940mV)
~10hrs+ TM5 Absolute (7hrs test was tRDRDscl/tWRWRscl 8/8, 5/5 failed, 6/6 passed ~3hrs, so profile became 6/6)
~1hr OCCT CPU+RAM AVX2 Large Variable (only have free version so limited to 1hr run)
~8hrs+ TM5 Ryzen3D (Required SOC bump of 0.01V, so became 1.135V)
~2hrs TM5 Extreme
~2hrs TM5 Heavy
~2hrs TM5 Intel
~8hrs TM5 1usmus (Dropped tRTP from 14 to 12, changed tRAS and tRC, 59/96 to 57/94)
From here system was WC
~9hrs TM5 Ryzen3D
~4.5k% Kahru (Dropped tWR from 60 to 48)
~7hrs TM5 Ryzen3D
~3hrs TM5 Absolute
~1.5hrs TM5 Extreme
rerun TM5 Extreme FAIL ~7.5hrs of 8.5hrs
UEFI 2902
~9hrs TM5 Extreme (Used SOC bump of 0.015V, so SOC became 1.15V, may retest with slightly lower another day)
~6k% Kahru 2 runs differing POST (SOC 1.145V, Nitro 1 2 1)
~9hrs Kahru (Bank Swap Mode Swap APU)
~3hrs TM5 Absolute
~9.33hrs TM5 Extreme
~3k Kahru (GDM:Off, Swap Mode Auto, Nitro Auto)
~5.1k Kahru (GDM:Off, Swap Mode APU, Nitro 1 2 1)
~2hrs TM5 Ryzen3D
~2hrs Y-Cruncher
~10hrs TM5 Extreme
~2hrs TM5 Absolute
~2hrs TM5 Heavy
~2hrs TM5 1usmus
~10.75hrs f@h on CPU/GPU
~13hrs f@h on CPU/GPU
UEFI 2904
~6k Kahru rerun
~43k Kahru rerun
~12.5k Kahru (tRCDWR 18, CT Level 2)
~2hrs TM5 Ryzen3D
~1hr TM5 Absolute
~8hrs TM5 Extreme (CT Auto)
~9hrs TM5 1usmus
~8hrs TM5 Ryzen3D (tRDRDSD/DD 1 tWRWRSD/DD 1)
~3.3k Kahru
~8hrs TM5 Absolute
~3hrs TM5 1usmus
With PBO CO OC:-
UEFI 2804
~8hrs AIDA64 CPU FPU CACHE
~8hrs Y-Cruncher default Stress test (Required FCLK VDCI Predicative, VDDG CCD/IOD: 920mV)
~24hrs CoreCycler P95
~24hrs CoreCycler AIDA64 CPU FPU CACHE
~24hrs CoreCycler Y-Cruncher
UEFI 2806
~3hrs TM5 1usmus (Required VDDG CCD/IOD: 940mV)
~10hrs+ TM5 Absolute (7hrs test was tRDRDscl/tWRWRscl 8/8, 5/5 failed, 6/6 passed ~3hrs, so profile became 6/6)
~1hr OCCT CPU+RAM AVX2 Large Variable (only have free version so limited to 1hr run)
~8hrs+ TM5 Ryzen3D (Required SOC bump of 0.01V, so became 1.135V)
~2hrs TM5 Extreme
~2hrs TM5 Heavy
~2hrs TM5 Intel
~8hrs TM5 1usmus (Dropped tRTP from 14 to 12, changed tRAS and tRC, 59/96 to 57/94)
From here system was WC
~9hrs TM5 Ryzen3D
~4.5k% Kahru (Dropped tWR from 60 to 48)
~7hrs TM5 Ryzen3D
~3hrs TM5 Absolute
~1.5hrs TM5 Extreme
rerun TM5 Extreme FAIL ~7.5hrs of 8.5hrs
UEFI 2902
~9hrs TM5 Extreme (Used SOC bump of 0.015V, so SOC became 1.15V, may retest with slightly lower another day)
~6k% Kahru 2 runs differing POST (SOC 1.145V, Nitro 1 2 1)
~9hrs Kahru (Bank Swap Mode Swap APU)
~3hrs TM5 Absolute
~9.33hrs TM5 Extreme
~3k Kahru (GDM:Off, Swap Mode Auto, Nitro Auto)
~5.1k Kahru (GDM:Off, Swap Mode APU, Nitro 1 2 1)
~2hrs TM5 Ryzen3D
~2hrs Y-Cruncher
~10hrs TM5 Extreme
~2hrs TM5 Absolute
~2hrs TM5 Heavy
~2hrs TM5 1usmus
~10.75hrs f@h on CPU/GPU
~13hrs f@h on CPU/GPU
UEFI 2904
~6k Kahru rerun
~43k Kahru rerun
~12.5k Kahru (tRCDWR 18, CT Level 2)
~2hrs TM5 Ryzen3D
~1hr TM5 Absolute
~8hrs TM5 Extreme (CT Auto)
~9hrs TM5 1usmus
~8hrs TM5 Ryzen3D (tRDRDSD/DD 1 tWRWRSD/DD 1)
~3.3k Kahru
~8hrs TM5 Absolute
~3hrs TM5 1usmus
My basic settings on ASUS boards
Due to all the stability tests I have run on differing 9000 series CPUs I have, the 2x RAM kits I tried and 2x ASUS X670E boards. I have concluded my base profiles will always have.
VRM Spread Spectrum [Disabled]
Clock Spread Spectrum [Disabled]
Above is disabled as they variate elements named and then don't stay at fixed value, which may cause instability.
Fclk VDCI Mode Pref [Predictive] (Finding this setting)
DDR5 Robust Training Mode [Enable]
Nitro Rx Burst Length [8x]
Nitro Tx Burst Length [8x]
Above are set to enhance stability, improve training. Even though help strings in BIOS may state adds latency, I have seen none in benchmarks, nor POST time after first initial post of system.
Power Down Enable [Disabled]
Set PDE disabled as I have seen even if [Auto] default to Disabled it can become Enabled due to other BIOS setting changes, example.
I also opt to use:-
Ai Overclock Tuner [Manual]
BCLK 100MHz, then set all voltages manually, as do not like auto rules changing timings as they deem.
I have ASUS TurboV Core in screen shots/videos. I do not use the app to change voltages "On the fly". I use it firstly to see default values when use a new UEFI and check auto settings. Then later it is just to capture what settings I use.
ASUS TurboV Core v1.05.03 found in OP here has given me more values then newer ones even included with USB in X670E Hero or X870E Hero I got from a OCN forum member.
For PBO CO 1x scalar is all I use, in the past seen it aids nothing, can actually regress performance ever so slightly in benchmarks.
In ASUS menu for Precision Boost Override when flip scalar to manual it may show 2x, this is default for that menu, but I do not think it is used orginally.
AMD OC menu scalar is 1x and does not show as change.
![Technology Software Screenshot Video Game Software Multimedia]()
![Red Screenshot Font Software Technology]()
![Red Screenshot Font Technology Software]()
![Technology Software Screenshot Video Game Software Multimedia]()
![Red Screenshot Font Software Technology]()
VRM Spread Spectrum [Disabled]
Clock Spread Spectrum [Disabled]
Above is disabled as they variate elements named and then don't stay at fixed value, which may cause instability.
Fclk VDCI Mode Pref [Predictive] (Finding this setting)
DDR5 Robust Training Mode [Enable]
Nitro Rx Burst Length [8x]
Nitro Tx Burst Length [8x]
Above are set to enhance stability, improve training. Even though help strings in BIOS may state adds latency, I have seen none in benchmarks, nor POST time after first initial post of system.
Power Down Enable [Disabled]
Set PDE disabled as I have seen even if [Auto] default to Disabled it can become Enabled due to other BIOS setting changes, example.
I also opt to use:-
Ai Overclock Tuner [Manual]
BCLK 100MHz, then set all voltages manually, as do not like auto rules changing timings as they deem.
I have ASUS TurboV Core in screen shots/videos. I do not use the app to change voltages "On the fly". I use it firstly to see default values when use a new UEFI and check auto settings. Then later it is just to capture what settings I use.
ASUS TurboV Core v1.05.03 found in OP here has given me more values then newer ones even included with USB in X670E Hero or X870E Hero I got from a OCN forum member.
For PBO CO 1x scalar is all I use, in the past seen it aids nothing, can actually regress performance ever so slightly in benchmarks.
Above is from Skatterbencher RPL guide.
In ASUS menu for Precision Boost Override when flip scalar to manual it may show 2x, this is default for that menu, but I do not think it is used orginally.
AMD OC menu scalar is 1x and does not show as change.
SMU Debug Tool shows disabled cores
When I used SMU Debug Tool on sample 1 9600X to do CO profile I was thinking why are there two cores greyed out just after core 2 and not say down at bottom.
![Font Software Number Technology Screenshot]()
When I tried sample 2 9600X two differing cores were greyed out, so it looks like SMU Debug Tool shows which of the cores are disabled.
![Font Number Software Technology Screenshot]()
Sample 2 9600X is defo being sold off.
Sample 1 9600X needs SOC 1.2V VDDP 1.05V for 6400MT/s C28 1:1 GDM On. Sample 2 9600X I can't even stabilise 6200MT/s C28 1:1 GDM on with SOC 1.2V VDDP 1.05V. All the same HW in use, except CPU.
On core clocks at stock sample 2 looked slightly worse then sample 1 in same testing. Now what I call level 1 CO tune where I make all cores same VID as lowest at stock, it still didn't raise clocks to 5450MHz. You can see that in above screenshots and below is screenie side by side of VID profile record I'm creating from testing.
Only thing sample 2 has going for it is FCLK 2200 (not tried higher yet), other than that poorer IMC, poorer core clocks. Don't think it will be as good for FMAX +200MHz looking at how it's behaving for stock FMAX.
When I tried sample 2 9600X two differing cores were greyed out, so it looks like SMU Debug Tool shows which of the cores are disabled.
Sample 2 9600X is defo being sold off.
Sample 1 9600X needs SOC 1.2V VDDP 1.05V for 6400MT/s C28 1:1 GDM On. Sample 2 9600X I can't even stabilise 6200MT/s C28 1:1 GDM on with SOC 1.2V VDDP 1.05V. All the same HW in use, except CPU.
On core clocks at stock sample 2 looked slightly worse then sample 1 in same testing. Now what I call level 1 CO tune where I make all cores same VID as lowest at stock, it still didn't raise clocks to 5450MHz. You can see that in above screenshots and below is screenie side by side of VID profile record I'm creating from testing.
Sample 1 9600X on left, sample 2 on right.
Even though I have VID shown, I reference CPU VDDCR_VDD Voltage (SVI3 TFN), as this is from CPU telemetry.
![White Text Font Number Screenshot]()
Even though I have VID shown, I reference CPU VDDCR_VDD Voltage (SVI3 TFN), as this is from CPU telemetry.
Only thing sample 2 has going for it is FCLK 2200 (not tried higher yet), other than that poorer IMC, poorer core clocks. Don't think it will be as good for FMAX +200MHz looking at how it's behaving for stock FMAX.
Same CO profile, same test load, differing voltages
This ZIP contains some screen shots, all the same HW in use, all the same settings in use, even power limits/readings in HWINFO show nothing like that is cause for difference.
Check voltages in level 1 and rerun level 1 in below spoiler.
It's possible profiles on the edge of stability may pass on initial setup, but on a reboot and retesting fail.
Check voltages in level 1 and rerun level 1 in below spoiler.
Even though I have VID shown, I reference CPU VDDCR_VDD Voltage (SVI3 TFN), as this is from CPU telemetry.
![White Text Font Number Screenshot]()
It's possible profiles on the edge of stability may pass on initial setup, but on a reboot and retesting fail.
Why use core parking for CO profiling?
I use core parking as believe this way it aids seeing per core clocks, voltage as other cores will be parked.
This is an old slide from AMD, note how peak XFR frequency was seen on 1800X.
![Text Font Screenshot Number Diagram]()
I know Ryzen has come along way since 1000 series, but I still think for CO profiling core parking is the way to roll.
To see core parking option in advanced view of power plan, apply registry tweak in W10 see OP here , W11 see this guide, it is the same regedit as W10, you can just apply the file for W10 in W11.
I make core parking min to 1 core value of CPU, so say below is 9800X3D, so 8 cores, 100%/8=12.5%, I set 13% as 0.5% values you can't enter, I don't know if 12 would do never checked. Open resource monitor and you will see best core is unparked on CPU.
![Software Screenshot Electronic device Font Technology]()
This is an old slide from AMD, note how peak XFR frequency was seen on 1800X.
I know Ryzen has come along way since 1000 series, but I still think for CO profiling core parking is the way to roll.
To see core parking option in advanced view of power plan, apply registry tweak in W10 see OP here , W11 see this guide, it is the same regedit as W10, you can just apply the file for W10 in W11.
I make core parking min to 1 core value of CPU, so say below is 9800X3D, so 8 cores, 100%/8=12.5%, I set 13% as 0.5% values you can't enter, I don't know if 12 would do never checked. Open resource monitor and you will see best core is unparked on CPU.
Power limits
* under construction *
Typical values
Use manual mode within PBO menu to set power limits as needed.
Using Ryzen Master and HWINFO to see Power Limits
![Software Number Font Technology Screenshot]()
In HWINFO you can double click sensors to see graph display.
![Electronic device Software Screenshot Multimedia Software Computer]()
Typical values
| PPT | TDC | EDC | |
|---|---|---|---|
| AM4 45W | 60W | 45A | 65A |
| AM4 65W | 87W | 60A | 90A |
| AM4 105W | 142W | 95A | 140A |
| PPT | TDC | EDC | |
|---|---|---|---|
| AM5 65W | 88W | 75A | 150A |
| AM5 105W | 142W | 110A | 170A |
| AM5 120W | 162W | 120A | 180A |
| AM5 170W | 230W | 160A | 225A |
Use manual mode within PBO menu to set power limits as needed.
All motherboards will have settings in AMD OC menu, some will have them in main area of BIOS, you only need to set in one place.
![Technology Software Screenshot Video Game Software Computer]()
Using Ryzen Master and HWINFO to see Power Limits
In HWINFO you can double click sensors to see graph display.
Heat intensity
As process node gets smaller and or dies get smaller/denser, heat intensity increases. It is harder for cooling solutions to pull the heat away quickly and efficiently. Temperatures which a decade or so ago would have been deemed high are now considered normal.
Below is from The Stilt's - Strictly technical: Matisse (Not really).
Below is from The Stilt's - Strictly technical: Matisse (Not really).
I don't know if I'm correct in applying same maths as above to Zen5. Which is 70.6mm². 120W @ 70.6mm², intensity of ~1.7W/mm², 200W @ 70.6mm², intensity of ~2.83W/mm². Also 28% more transistors then Zen4, below source link.
AMD state floor plan of Zen5 was improved to improve temperatures, below source link.
CPU SP rating in Ai Features on ASUS boards
The SP rating can go up or down even on same CPU in use. It depends on CPU temperature at time of POST after flash of new UEFI (using flashback). Here is some data shared by Antsu, link. Also see Shamino's post in regard to SP rating, link.
On two R5 9600X I have, batch is same, only serials differ. Their stock FMAX differs in Ai Features and this matches up when I do CO per core tuning. Then also when do +200MHz the chip that has a lower stock FMAX, ends up lower again.
![Screenshot Text Font Number Software]()
![Screenshot Text Font Number Software]()
What interests me is the FMAX value and some what the VIDs shown in Ai Features.
On two R5 9600X I have, batch is same, only serials differ. Their stock FMAX differs in Ai Features and this matches up when I do CO per core tuning. Then also when do +200MHz the chip that has a lower stock FMAX, ends up lower again.
What FCLK to use?
tldr: Run FCLK at max stable clock.
I got AM5/DDR5 end of DEC 24, so am new to it. To get myself running I thought as platform has been out a while just read to see what insights are about. I noticed posts recommending setting FCLK based on what MEMCLK you are using. This to me seemed odd, as how I saw it was FCLK is a bottle neck on AM5 as we can't run it as high as MEMCLK/UCLK.
Pretty soon in my own testing and comparing it with others shares. It was best to run FCLK as high as stable. Any one wishing to know what this ratio setup is please read this post, but also see this post.
Now this ZIP contains 30 runs of AIDA64 memory benchmark, 3 runs per FCLK. Each run was a full run ie I did not just click the text memory to run only memory test.
The runs were done back to back, but at times I was interrupted at home, process took ~4hrs. AIDA64 wasn't picked as it was only thing that shows gains from FCLK, it was just the easiest and quickest to run in my opinion. When have time will try other benchmarks were I have seen gains from FCLK. Kahru RAM Test you can see test speed improve as FCLK is increased.
ASUS Core Tuning Configuration For Gaming (see link) was set to Legacy for all runs. Legacy = All advanced prefetchers and cache retention polices disabled.
When I get time I will create some charts/graphs. For now I'd say just launch in MS Photos, full screen and use left/right keys to scroll through them.
All runs were with SVM: On, at the end I did 2000MHz and 2233MHz with it off and saw no big difference between the runs with it on. In task manager Virtualisation: Disabled = SVM Off. CPU was stock for all runs.
I did wait after OS load, to make sure benchmark was done once OS had completed it's initial background processes. The OS is not stripped, but not bloated. It just has current latest updates/drivers, apps for stability testing and benchmarks, it is pretty much a test system. Here are photos of it.
The memory profile used has passed Kahru RAM Test ~33k, a data ZIP for that is near end of DDR5 Tuning Information section. That ZIP also has a LinpackXtreme test run screenshot. This is to check FCLK stability, you want to see low deviation between results, some does occur. Unstable FCLK may just error out from what I saw. Run test >8 iterations, 10GB options, all CPU threads. LinpackXtreme is also linked in links section of OP.
This ZIP contains Kahru RAM Test runs to show effect of FCLK increases on test speed.
This ZIP contains some PyPrime/AIDA64 runs with GDM: Off, Swap APU, Nitro 1 2 1.
I got AM5/DDR5 end of DEC 24, so am new to it. To get myself running I thought as platform has been out a while just read to see what insights are about. I noticed posts recommending setting FCLK based on what MEMCLK you are using. This to me seemed odd, as how I saw it was FCLK is a bottle neck on AM5 as we can't run it as high as MEMCLK/UCLK.
Pretty soon in my own testing and comparing it with others shares. It was best to run FCLK as high as stable. Any one wishing to know what this ratio setup is please read this post, but also see this post.
Now this ZIP contains 30 runs of AIDA64 memory benchmark, 3 runs per FCLK. Each run was a full run ie I did not just click the text memory to run only memory test.
The runs were done back to back, but at times I was interrupted at home, process took ~4hrs. AIDA64 wasn't picked as it was only thing that shows gains from FCLK, it was just the easiest and quickest to run in my opinion. When have time will try other benchmarks were I have seen gains from FCLK. Kahru RAM Test you can see test speed improve as FCLK is increased.
ASUS Core Tuning Configuration For Gaming (see link) was set to Legacy for all runs. Legacy = All advanced prefetchers and cache retention polices disabled.
When I get time I will create some charts/graphs. For now I'd say just launch in MS Photos, full screen and use left/right keys to scroll through them.
All runs were with SVM: On, at the end I did 2000MHz and 2233MHz with it off and saw no big difference between the runs with it on. In task manager Virtualisation: Disabled = SVM Off. CPU was stock for all runs.
I did wait after OS load, to make sure benchmark was done once OS had completed it's initial background processes. The OS is not stripped, but not bloated. It just has current latest updates/drivers, apps for stability testing and benchmarks, it is pretty much a test system. Here are photos of it.
The memory profile used has passed Kahru RAM Test ~33k, a data ZIP for that is near end of DDR5 Tuning Information section. That ZIP also has a LinpackXtreme test run screenshot. This is to check FCLK stability, you want to see low deviation between results, some does occur. Unstable FCLK may just error out from what I saw. Run test >8 iterations, 10GB options, all CPU threads. LinpackXtreme is also linked in links section of OP.
This ZIP contains Kahru RAM Test runs to show effect of FCLK increases on test speed.
This ZIP contains some PyPrime/AIDA64 runs with GDM: Off, Swap APU, Nitro 1 2 1.
Useful Links
HWINFO, download page link.
Generic Log Viewer, thread/download link.
SMU Debug Tool, releases link, main GitHub repository link.
Kahru RAM Test KGuiX, releases link, main GitHub repository link.
TM5 fixed and improved by Veii, link.
Statuscore, homepage/download link.
CoreCycler, thread/download, link.
LinpackXtreme v1.1.8, thread/download link.
RopBench v1.82, link.
Articles Links
Raphael Overclocking: What’s New, link.
Granite Ridge Overclocking: Curve Shaper, link.
Precision Boost HTFmax limiter, link.
Overclocking Technologies, link.
AVX512 throttling, clock stretching or something else entirely?!, link.
Zen 5's AVX-512 Frequency Behavior, link.
AMD Zen 5 Technical Deep Dive, link.
