# CoreCycler - tool for testing Curve Optimizer settings



## sp00n82

Over the last couple of days resp. weeks I've been working with the Curve Optimizer for Ryzen processors a bit more, but I hadn't found a good way to test the settings for stability. CineBench single threaded almost always worked fine, and getting Prime95 stable with load on all cores was also relatively quick. Waiting for crashes while idling or while playing a game wasn't so appealing either, and on Reddit someone even suggested using the Windows Repair as some kind of stability test... that didn't seem like a good idea to me.

So this sparked the idea for this tool. It's a PowerShell script which starts up an instance of Prime95 with only a single worker thread, stressing only a single physical CPU core. And it cycles through all the available cores after an adjustable time, so that you can run this tool e.g. over night, and then the next day you can check which cores have run fine and which ones have thrown an error in Prime95.

By now it looks polished enough for a release, however so far I'm the only one who has tested it, so additional reports are welcome.

You can find it here:








Releases · sp00n/corecycler


Stability test script for PBO & Curve Optimizer stability testing on AMD Ryzen processors - sp00n/corecycler




github.com






To execute it, simply double click the "Run CoreCycler.bat".
And be sure to read the included readme.txt as well as the config.ini (resp. config.default.ini) to get a grasp of what settings you can change.
(Note: the config.ini will be auto-generated on the first start from the config.default.ini)


Screenshots of the script in action:














And here's an example for a summary, this is how the testing went for me during development. As you can see, this still takes quite some time to get stable. (And no, the summary will not be generated automatically, you'll still have to do this yourself ):









Here's an excerpt from the readme.txt

This little script will run Prime95 with only one worker thread and sets the affinity of the Prime95 process alternating to each physical core, cycling through all of them. This way you can test the stability of your Curve Optimizer setting for each core individually, much more thoroughly than e.g. with Cinebench or the Windows Repair, and much easier than manually setting the affinity of the process via the Task Manager.
It will still need a lot of time though. If for example you're after a 12h "prime-stable" setup which is common for regular overvlocks, you'd need to run this script for 12x12 = 144 hours on a 5900X with 12 physical cores, because each core is tested individually, and so each core also needs to complete this 12 hour test individually. Respectively, on a 5600X with its 6 physical cores this would be "only" 6x12 = 72 hours.
Unfortunately such an all-core stress test with Prime95 is not effective for testing Curve Optimizer settings, because the cores cannot boost as high if all of them are stres tested, and therefore you won't be able to detect instabilities that occur at a higher clock speed. For example, with my CPU I was able to run a Prime95 all-core stress test for 24 hours with an additional Boost Override of +75 MHz and a Curve Optimizer setting of -30 on all cores. However, when using this script, and with +0 MHz Boost Override, I needed to go down to -9 on one core to have it run stable (on the other hand, another core was still happy with a -30 setting even in this case).

When you start the script for the first time, it will copy the included config.default.ini to config.ini, in which you then can change various settings, e.g. which mode Prime95 should run in (SSE, AVX, AVX2, CUSTOM, where SSE causes the highest boost clock, because it's the lightest load on the processor of all the settings), how long an individual core should be stressed for before it cycles to the next one, if certain cores should be ignored, etc. For each setting there's also a description in the config.ini file.

As a starting point you could set the Curve Optimizer to e.g. -15 or -20 for each core and then wait and see which core runs through fine and which throws an error. Then you could increase the setting for those that have thrown an error by e.g. 2 or 3 points (e.g. from -15 to -13) and decrease those that were fine by 2 or 3 further into the negative (-15 to -17). Once you've crossed a certain point however there is no way around modifying the value by a single point up/down and letting the script run for a long time to find the very last instabilities.

By the way, it is intended that only one thread is stressed for each core if Hyperthreading / SMT is enabled, as the boost clock is higher this way, compared to if both (virtual) threads would be stressed. However, there is a setting in the config.ini to enable two threads as well.


----------



## thigobr

After testing hours of y-cruncher/TM5 memory test and even Prime95 AVX multi thread without issues I tried your script without any modifications... To my surprise I got rounding errors at stock, after a clear CMOS + load defaults!

I was thinking my CPU was stable but it seems it's actually not!

Regarding the script it works well, thanks for sharing and keep the good work!


----------



## Dasa

Already been done.
*Single core Prime95 test script for Zen 3 curve offset tuning*
But that one focuses on a single FTT size with some reporting there CPU error quicker with different FTT which could be one advantage to your version of the test even if it takes a bit longer to run.

I find that after passing that single threaded prime95 test and y-cruncher it will still quickly blue screen with much lower curves when using AIDA64 cache benchmark on my 5800X so I will give your test a try and see what it finds thanks.


----------



## sp00n82

Dasa said:


> Already been done.
> *Single core Prime95 test script for Zen 3 curve offset tuning*
> But that one focuses on a single FTT size with some reporting there CPU error quicker with different FTT which could be one advantage to your version of the test even if it takes a bit longer to run.
> 
> I find that after passing that single threaded prime95 test and y-cruncher it will still quickly blue screen with much lower curves when using AIDA64 cache benchmark on my 5800X so I will give your test a try and see what it finds thanks.


Interesting, haven't seen that one before. And it's even a PowerShell script as well.
Two idiots with the same idea. 😅


----------



## halcyonon

This doesn't help you detect core problems at non peak frequency/voltages though.. so at best it only helps with a small range of the space of where undervolting can cause crashes. It seems like we'd really need AMD to provide us a way to "lock" a core at an arbitrary point on it's boost curve so we could test the whole range.


----------



## Dasa

Gave it a run for two passes of your prime but then today I gave AIDA64 cache bench another go and the system rebooted so I dropped the offset for all cores 1 notch below these values.
This 5800X seems to allow decent curves up to 4875MHz but at 4900MHz they plummet but that is what is required to hit the max WHEA free IF on this CPU.

101x48.5=4898.5MHz max and distance below max during per core prime95 single thread.
3x scaler LLC off
CORE #0 13 CPPC=150, Curve-11 =1304mV max 15.510W
CORE #1 9 CPPC=146, Curve+1 =1384mV -50MHz 18.136W
CORE #2 6 CPPC=139, Curve-5 =1385mV -10MHz 18.814W
CORE #3 0 CPPC=127, Curve-5 =1374mV -40MHz 18.276W
CORE #4 3 CPPC=135, Curve-6 =1386mV -20MHz 17.573W
CORE #5 5 CPPC=143, Curve-3 =1384mV -20MHz 17.499W
CORE #6 5 CPPC=131, Curve-2 =1364mV -100MHz 16.470W
CORE #7 12 CPPC=150, Curve-17 =1271mV max 15.179W

For comparison this is what was stable with just 50MHz less where prime95 stability testing was good enough as AIDA64 doesn't crash from tweaking curves till it goes over 4850MHz.
Core #1 seems to be the only one that errors in prime before crashing AIDA64 at higher frequency.
CORE #0 13 CPPC 150 -14 =1262mV
CORE #1 9 CPPC 146 -9 =1323mV
CORE #2 6 CPPC 139 -22 =1245mV
CORE #3 0 CPPC 127 -22 =1263mV
CORE #4 3 CPPC 135 -17 =1286mV
CORE #5 5 CPPC 143 -23 =1238mV
CORE #6 5 CPPC 131 -22 =1275mV
CORE #7 12 CPPC 150 -23 =1220mV
With these curves all cores were able to maintain 4850MHz during the single threaded prime95 test unlike at 4900MHz


----------



## blu3dragon

spoonium said:


> Interesting, haven't seen that one before. And it's even a PowerShell script as well.
> Two idiots with the same idea. 😅


That must make it a good idea no?
:-D


----------



## jvidia

spoonium said:


> Over the last couple of days resp. weeks I've been working with the Curve Optimizer for Ryzen processors a bit more, but I hadn't found a good way to test the settings for stability. CineBench single threaded almost always worked fine, and getting Prime95 stable with load on all cores was also relatively quick. Waiting for crashes while idling or while playing a game wasn't so appealing either, and on Reddit someone even suggested using the Windows Repair as some kind of stability test... that didn't seem like a good idea to me.
> 
> So this sparked the idea for this tool. It's a PowerShell script which starts up an instance of Prime95 with only a single worker thread, stressing only a single physical CPU core. And it cycles through all the available cores after an adjustable time, so that you can run this tool e.g. over night, and then the next day you can check which cores have run fine and which ones have thrown an error in Prime95.
> 
> By now it looks polished enough for a release, however so far I'm the only one who has tested it, so additional reports are welcome.
> 
> You can find it here:
> 
> 
> 
> 
> 
> 
> 
> 
> Releases · sp00n/corecycler
> 
> 
> Stability test script for PBO & Curve Optimizer stability testing on AMD Ryzen processors - sp00n/corecycler
> 
> 
> 
> 
> github.com
> 
> 
> 
> 
> 
> 
> To execute it, simply double click the "Run CoreCycler.bat".
> And be sure to read the included readme.txt as well as the config.ini (resp. config.default.ini) to get a grasp of what settings you can change.
> (Note: the config.ini will be auto-generated on the first start from the config.default.ini)
> 
> 
> Screenshots of the script in action:
> View attachment 2481473
> View attachment 2481474
> 
> 
> And here's an example for a summary, this is how the testing went for me during development. As you can see, this still takes quite some time to get stable. (And no, the summary will not be generated automatically, you'll still have to do this yourself ):
> View attachment 2481475
> 
> 
> 
> Here's an excerpt from the readme.txt
> 
> This little script will run Prime95 with only one worker thread and sets the affinity of the Prime95 process alternating to each physical core, cycling through all of them. This way you can test the stability of your Curve Optimizer setting for each core individually, much more thoroughly than e.g. with Cinebench or the Windows Repair, and much easier than manually setting the affinity of the process via the Task Manager.
> It will still need a lot of time though. If for example you're after a 12h "prime-stable" setup which is common for regular overvlocks, you'd need to run this script for 12x12 = 144 hours on a 5900X with 12 physical cores, because each core is tested individually, and so each core also needs to complete this 12 hour test individually. Respectively, on a 5600X with its 6 physical cores this would be "only" 6x12 = 72 hours.
> Unfortunately such an all-core stress test with Prime95 is not effective for testing Curve Optimizer settings, because the cores cannot boost as high if all of them are stres tested, and therefore you won't be able to detect instabilities that occur at a higher clock speed. For example, with my CPU I was able to run a Prime95 all-core stress test for 24 hours with an additional Boost Override of +75 MHz and a Curve Optimizer setting of -30 on all cores. However, when using this script, and with +0 MHz Boost Override, I needed to go down to -9 on one core to have it run stable (on the other hand, another core was still happy with a -30 setting even in this case).
> 
> When you start the script for the first time, it will copy the included config.default.ini to config.ini, in which you then can change various settings, e.g. which mode Prime95 should run in (SSE, AVX, AVX2, CUSTOM, where SSE causes the highest boost clock, because it's the lightest load on the processor of all the settings), how long an individual core should be stressed for before it cycles to the next one, if certain cores should be ignored, etc. For each setting there's also a description in the config.ini file.
> 
> As a starting point you could set the Curve Optimizer to e.g. -15 or -20 for each core and then wait and see which core runs through fine and which throws an error. Then you could increase the setting for those that have thrown an error by e.g. 2 or 3 points (e.g. from -15 to -13) and decrease those that were fine by 2 or 3 further into the negative (-15 to -17). Once you've crossed a certain point however there is no way around modifying the value by a single point up/down and letting the script run for a long time to find the very last instabilities.
> 
> By the way, it is intended that only one thread is stressed for each core if Hyperthreading / SMT is enabled, as the boost clock is higher this way, compared to if both (virtual) threads would be stressed. However, there is a setting in the config.ini to enable two threads as well.


I'm using it !
Thank you!


----------



## lmfodor

I ran core cycler several times in the last week. What’s found is that after one night passing all the test.. I canceled the script.. so I was on idle and then I ran CB20.. an then.. it reboot. No BSOD and nothing else. I don’t know but I guess core cycler would be fine to find some extreme values conflict but it doesn’t help to fix the reboot on idle issue. Has something similar happened to anyone?


Sent from my iPhone using Tapatalk Pro


----------



## jvidia

lmfodor said:


> I ran core cycler several times in the last week. What’s found is that after one night passing all the test.. I canceled the script.. so I was on idle and then I ran CB20.. an then.. it reboot. No BSOD and nothing else. I don’t know but I guess core cycler would be fine to find some extreme values conflict but it doesn’t help to fix the reboot on idle issue. Has something similar happened to anyone?
> 
> 
> Sent from my iPhone using Tapatalk Pro


Yes Core Cycler does not find that kind of instability.
It works on single core load scenarios.

That reboot you experienced originated any WHEA in the windows event log?


----------



## jvidia

Dasa said:


> Gave it a run for two passes of your prime but then today I gave AIDA64 cache bench another go and the system rebooted so I dropped the offset for all cores 1 notch below these values.
> This 5800X seems to allow decent curves up to 4875MHz but at 4900MHz they plummet but that is what is required to hit the max WHEA free IF on this CPU.
> 
> 101x48.5=4898.5MHz max and distance below max during per core prime95 single thread.
> 3x scaler LLC off
> CORE #0 13 CPPC=150, Curve-11 =1304mV max 15.510W
> CORE #1 9 CPPC=146, Curve+1 =1384mV -50MHz 18.136W
> CORE #2 6 CPPC=139, Curve-5 =1385mV -10MHz 18.814W
> CORE #3 0 CPPC=127, Curve-5 =1374mV -40MHz 18.276W
> CORE #4 3 CPPC=135, Curve-6 =1386mV -20MHz 17.573W
> CORE #5 5 CPPC=143, Curve-3 =1384mV -20MHz 17.499W
> CORE #6 5 CPPC=131, Curve-2 =1364mV -100MHz 16.470W
> CORE #7 12 CPPC=150, Curve-17 =1271mV max 15.179W
> 
> For comparison this is what was stable with just 50MHz less where prime95 stability testing was good enough as AIDA64 doesn't crash from tweaking curves till it goes over 4850MHz.
> Core #1 seems to be the only one that errors in prime before crashing AIDA64 at higher frequency.
> CORE #0 13 CPPC 150 -14 =1262mV
> CORE #1 9 CPPC 146 -9 =1323mV
> CORE #2 6 CPPC 139 -22 =1245mV
> CORE #3 0 CPPC 127 -22 =1263mV
> CORE #4 3 CPPC 135 -17 =1286mV
> CORE #5 5 CPPC 143 -23 =1238mV
> CORE #6 5 CPPC 131 -22 =1275mV
> CORE #7 12 CPPC 150 -23 =1220mV
> With these curves all cores were able to maintain 4850MHz during the single threaded prime95 test unlike at 4900MHz


My 5800X with the curve optimized/tested with Core Cycler is also able to maintain 4850MHz during the single core tests with Core Cycle/CB R20.

Single core at 4850Mhz seems to be a pattern with decent 5800X CPU's when not using PBO Boost Offset.

I can't squeeze any more MHz with the PBO Boost Offset (not even 25Mhz) without having to drop all curve values that leads to multi core performance loss.

In multi core running CB R20 I'm getting 4750 Mhz all core.

I prefer to leave it this way ( 4750 Mhz all core with zero PBO offset ) than having to lower all cores to get more 25/50MHz in single core.
It does not worth it.
Multi core scenarios are 90% of the use case scenarios this days.


----------



## sp00n82

With version 0.8 CoreCycler will support Aida64 and Y-Cruncher as additional stress tests. Although for Aida64 you'll need to manually download and extract the Portable Engineer version due to its license (I don't think I can include it).
There's also a new config switch which if set (which it is by default) will periodically suspend and restart the stress test, with which I hope to emulate the load change scenarios and therefore catch more instabilities. Also the test order can be changed, by default it's now alternating between core 1 on CCD1, core 1 on CCD2, core 2 on CCD1, etc for processors with more than 8 cores, or random for anything up to 8 cores. With that I hope to squeeze out some more MHz because the hot spots are distributed more evenly, which could lead to slightly higher boost clock as well.

It should be ready soon and I'm looking for beta testers for this version, so if you're interested, let me know. 🙃


----------



## lmfodor

spoonium said:


> With version 0.8 CoreCycler will support Aida64 and Y-Cruncher as additional stress tests. Although for Aida64 you'll need to manually download and extract the Portable Engineer version due to its license (I don't think I can include it).
> There's also a new config switch which if set (which it is by default) will periodically suspend and restart the stress test, with which I hope to emulate the load change scenarios and therefore catch more instabilities. Also the test order can be changed, by default it's now alternating between core 1 on CCD1, core 1 on CCD2, core 2 on CCD1, etc for processors with more than 8 cores, or random for anything up to 8 cores. With that I hope to squeeze out some more MHz because the hot spots are distributed more evenly, which could lead to slightly higher boost clock as well.
> 
> It should be ready soon and I'm looking for beta testers for this version, so if you're interested, let me know.


Yes! I’m definitely want to try the new version. Again, the y-cruncher helps me to find errors in the curve very easy. I think is by far better than P95 because I could run hours of P95 alone or even with the core cycler without any errors.. but there are errors.. and after having canceled the test I had a reboot on idle. So.. y-cruncher is very good but I think it put in consideration other factors like memory.. so if the new CC version stop and then start again it would be great. The other thing is to have some schedule .. you now, running a test for 144hs straight is almost impossible.. maybe if it can run for 12 hours.stop and continue .. would be fine, perhaps only test 1 core and then stop.. 


Sent from my iPhone using Tapatalk Pro


----------



## sp00n82

lmfodor said:


> The other thing is to have some schedule .. you now, running a test for 144hs straight is almost impossible.. maybe if it can run for 12 hours.stop and continue .. would be fine, perhaps only test 1 core and then stop..


I didn't necessarily mean you need to run it 144 hours non stop. I agree that's impracticable. But you can easily run it for 8+ hours over multiple nights, which then can sum up to this amount of stress test hours. After all, after a certain amount of time the test algorithms repeat anyway, so there's nothing really gained by running it for 144 hours in one session.
It's only a problem if your stress test session are so short that you don't encounter all possible test scenarios. Which is also why I suggest you not only run the default settings, but switch between SSE/AVX/AVX2 and the various FFT sizes (and Y-Cruncher & Aida64 beginning with v0.8).


----------



## jcpq

If we restart how do we know the core that failed?


----------



## sp00n82

jcpq said:


> If we restart how do we know the core that failed?


Take a look in the generated log file.


----------



## jcpq

spoonium said:


> Take a look in the generated log file.


Thanks


----------



## Theo164

Thanks for sharing!
y-cruncher seems to be the best and faster option for error detection
After 2 iterations 10m per core for each stress test y-cruncher both times failed on core 6, aida64 and prime95 no errors.
Changing core 6 curve from -23 to -22 and test with y cruncher again for 2 iterations 10m per core no errors



Spoiler: y-cruncher error



+ 22:00:10 - ...checking CPU usage: 4.17%
+ ...current CPU frequency: ~4815 MHz (130.1%)
+ Suspending the stress test process
+ Suspended: True
+ Resuming the stress test process
+ Resumed: True
+ 22:00:22 - ...checking CPU usage: 0%
+ 22:00:22 - ...the CPU usage was too low, waiting 2000ms for another check...
+ Process Id: 1368
+ 22:00:22 - ...checking CPU usage again: 0%
+ ...still not enough usage, throw an error
+ There has been an error with the stress test program!
ERROR: 22:00:28
ERROR: Y-Cruncher seems to have stopped with an error!
ERROR: At Core 6 (CPU 12)
ERROR MESSAGE: The Y-Cruncher process doesn't use enough CPU power anymore (only 0% instead of the expected 4.17%)
+ The stress test program is Y-Cruncher, no detailed error detection available
+ There has been some error in Test-ProcessUsage, checking
+ Trying to close the stress test program to re-start it
+ Trying to close the stress test program
+ Trying to close Y-Cruncher
+ Trying to gracefully close Y-Cruncher
+ Y-Cruncher closed
+ restartTestProgramForEachCore is not set, restarting the test program right away
22:00:28 - Trying to restart Y-Cruncher
+ Starting the stress test program
+ Starting Y-Cruncher
+ Trying to get the stress test program window handler
+ Looking for these window names:
+ ^.*00-x86\.exe$
+ 22:00:28 - Window found
+ Found the following window(s) with these names:
+ - WinTitle: Y-Cruncher - 00-x86.exe
+ ProcessId: 3820
+ Process Path: C:\Users\User\Desktop\CoreCycler-v0.8.0.0-RC3\test_programs\y-cruncher\Binaries\00-x86.exe
+ Filtering the windows for ".*00-x86.exe$":
+ - WinTitle: Y-Cruncher - 00-x86.exe
+ ProcessId: 3820
+ Process Path: C:\Users\User\Desktop\CoreCycler-v0.8.0.0-RC3\test_programs\y-cruncher\Binaries\00-x86.exe
+ Stress test window handler: 459910
+ Stress test window process ID: 3820
+ Stress test process: 00-x86
+ Stress test process ID: 3820
+ The Performance Process Counter Path for the ID:
+ \\desktop-nuhesut\process(00-x86)\id process
+ The Performance Process Counter Path for the Time:
+ \\desktop-nuhesut\process(00-x86)\% Processor Time
+ Y-Cruncher seems to have stopped with an error at Core 6 (CPU 12)
+ Alternating test order selected, getting the core to test...
+ Previous core: 6
+ The selected core to test: 1
22:00:30 - Set to Core 1 (CPU 2)





Spoiler: AIDA Notice



23:47:12 - Iteration 1
----------------------------------
+ Alternating test order selected, getting the core to test...
+ Previous core: 
+ The selected core to test: 0
Notice!
Apparently Aida64 doesn't like running the stress test on the first thread of Core 0.
Setting it to thread 2 of Core 0 instead (Core 0 CPU 1).
23:47:12 - Set to Core 0 (CPU 1)
+ Setting the affinity to 2
+ Successfully set the affinity to 2


Additional stress tests for higher frequencies may improve error detection, y-cryncher 00-x86 test is one of the best option available compared to aida64 and prime95 but can't reach peak frequencies.

e.g.
5900x +150mhz


----------



## TheInvincible2111

spoonium said:


> With version 0.8 CoreCycler will support Aida64 and Y-Cruncher as additional stress tests. Although for Aida64 you'll need to manually download and extract the Portable Engineer version due to its license (I don't think I can include it).
> There's also a new config switch which if set (which it is by default) will periodically suspend and restart the stress test, with which I hope to emulate the load change scenarios and therefore catch more instabilities. Also the test order can be changed, by default it's now alternating between core 1 on CCD1, core 1 on CCD2, core 2 on CCD1, etc for processors with more than 8 cores, or random for anything up to 8 cores. With that I hope to squeeze out some more MHz because the hot spots are distributed more evenly, which could lead to slightly higher boost clock as well.
> 
> It should be ready soon and I'm looking for beta testers for this version, so if you're interested, let me know. 🙃


If possible, I would like to beta test the tool too. I've been using core cycler for a week and it's highly convenient. I'd be obliged if I can play any part in its further development.
Thanks and Regards.


----------



## TheInvincible2111

Theo164 said:


> Thanks for sharing!
> y-cruncher seems to be the best and faster option for error detection
> After 2 iterations 10m per core for each stress test y-cruncher both times failed on core 6, aida64 and prime95 no errors.
> Changing core 6 curve from -23 to -22 and test with y cruncher again for 2 iterations 10m per core no errors
> 
> 
> 
> Spoiler: y-cruncher error
> 
> 
> 
> + 22:00:10 - ...checking CPU usage: 4.17%
> + ...current CPU frequency: ~4815 MHz (130.1%)
> + Suspending the stress test process
> + Suspended: True
> + Resuming the stress test process
> + Resumed: True
> + 22:00:22 - ...checking CPU usage: 0%
> + 22:00:22 - ...the CPU usage was too low, waiting 2000ms for another check...
> + Process Id: 1368
> + 22:00:22 - ...checking CPU usage again: 0%
> + ...still not enough usage, throw an error
> + There has been an error with the stress test program!
> ERROR: 22:00:28
> ERROR: Y-Cruncher seems to have stopped with an error!
> ERROR: At Core 6 (CPU 12)
> ERROR MESSAGE: The Y-Cruncher process doesn't use enough CPU power anymore (only 0% instead of the expected 4.17%)
> + The stress test program is Y-Cruncher, no detailed error detection available
> + There has been some error in Test-ProcessUsage, checking
> + Trying to close the stress test program to re-start it
> + Trying to close the stress test program
> + Trying to close Y-Cruncher
> + Trying to gracefully close Y-Cruncher
> + Y-Cruncher closed
> + restartTestProgramForEachCore is not set, restarting the test program right away
> 22:00:28 - Trying to restart Y-Cruncher
> + Starting the stress test program
> + Starting Y-Cruncher
> + Trying to get the stress test program window handler
> + Looking for these window names:
> + ^.*00-x86\.exe$
> + 22:00:28 - Window found
> + Found the following window(s) with these names:
> + - WinTitle: Y-Cruncher - 00-x86.exe
> + ProcessId: 3820
> + Process Path: C:\Users\User\Desktop\CoreCycler-v0.8.0.0-RC3\test_programs\y-cruncher\Binaries\00-x86.exe
> + Filtering the windows for ".*00-x86.exe$":
> + - WinTitle: Y-Cruncher - 00-x86.exe
> + ProcessId: 3820
> + Process Path: C:\Users\User\Desktop\CoreCycler-v0.8.0.0-RC3\test_programs\y-cruncher\Binaries\00-x86.exe
> + Stress test window handler: 459910
> + Stress test window process ID: 3820
> + Stress test process: 00-x86
> + Stress test process ID: 3820
> + The Performance Process Counter Path for the ID:
> + \\desktop-nuhesut\process(00-x86)\id process
> + The Performance Process Counter Path for the Time:
> + \\desktop-nuhesut\process(00-x86)\% Processor Time
> + Y-Cruncher seems to have stopped with an error at Core 6 (CPU 12)
> + Alternating test order selected, getting the core to test...
> + Previous core: 6
> + The selected core to test: 1
> 22:00:30 - Set to Core 1 (CPU 2)
> 
> 
> 
> 
> 
> Spoiler: AIDA Notice
> 
> 
> 
> 23:47:12 - Iteration 1
> ----------------------------------
> + Alternating test order selected, getting the core to test...
> + Previous core:
> + The selected core to test: 0
> Notice!
> Apparently Aida64 doesn't like running the stress test on the first thread of Core 0.
> Setting it to thread 2 of Core 0 instead (Core 0 CPU 1).
> 23:47:12 - Set to Core 0 (CPU 1)
> + Setting the affinity to 2
> + Successfully set the affinity to 2
> 
> 
> Additional stress tests for higher frequencies may improve error detection, y-cryncher 00-x86 test is one of the best option available compared to aida64 and prime95 but can't reach peak frequencies.
> 
> e.g.
> 5900x +150mhz
> 
> View attachment 2484266
> 
> 
> View attachment 2484267


Which exact tests did you use? Can you please share a screenshot of your y-cruncher settings? 
Thanks


----------



## sp00n82

Here's v0.8.0.0 RC4, only use it if you're willing to beta test. 👆








Release v0.8.0.0 RC4 · sp00n/corecycler


Still intended only for beta testing. Some more bug fixes and improvements, hopefully without introducing new bugs. You can now define your own custom testing order by providing a comma separated l...




github.com






@Theo164
It's interesting, I've never been able to have Y-Cruncher actually fail a stress test. It's either passing for me or rebooting the whole system. 🤷‍♂️
And regarding BoostTester, I've looked at it as well, and its source code, and unfortunately I don't see a way how I could use this for error testing. There's no error checking involved, all it seems to do is to assign a large array and then randomly accesses these entries. Or to quote the developer: _"The goal of this function is to create a "100%" load at extremely low IPC. The best way I can think of to do this is by constantly stalling waiting for data from RAM."_

I'm open for suggestions for other programs that I could use as a stress test. They'd need to be controllable from the command line though and give some sort of feedback if an error occurs (either just stop or preferably also generate a log file I could parse).


----------



## TheInvincible2111

Now this is odd, my Core 5 managed to fail in safe mode within 4 iterations of prime95, 10minute per core.
While with y-cruncher, it's managed to survive an hour in both regular Windows as well as Safe Mode. Could it be the fact that other cores were being tested in the prime95 test that core 5 crashed? Even though the total stress time of the core is same in both cases?
Edit: Before stress testing it in prime95 along with other cores, I had also had it run stable for around 1.5 hours in the same test while having added the other cores to the ignored list.


----------



## sp00n82

Once you passed a certain stability threshold, I've found that errors happen only infrequently. Which is the whole reason why for all-core overclocks you'd generally do a 12 hour stress test over night (or even longer), to catch such infrequent errors. The problem with single core boost behaviour and therefore single core stress tests is that for the same level of confidence you would need to run the stress test for 12 hours for _every single core_, so it's much more time consuming than an all-core overclock. Basically, 1.5 hours of total test time per core is nothing if you're looking for a rock-stable overclock.

I've had cores fail after 14 nights of running fine without an error.


----------



## sp00n82

RC5 is now out, this is hopefully the last RC before I can push out the final version 0.8.
Again, only use this if you're willing to beta test.









Release v0.8.0.0 RC5 · sp00n/corecycler


Still intended for beta testing only. Updated Prime95 to 30.5 build 2 The analyze log file script now autodetects if one or two threads were used Fixed a bug where Aida64 did not close correctly F...




github.com


----------



## sp00n82

Happy Easter!

*Version 0.8.0.0 is now available.*
It includes support for Aida64 and Y-Cruncher!

*Download:*
Releases · sp00n/corecycler


*Changelog:*

Updated Prime95 to 30.5 build 2
Support for Aida64 and Y-Cruncher! You can now define which stress test program to use (Note: see the readme.txt for more infos on Aida64)
Restructured the config file to support Aida64 and Y-Cruncher. Old config files will not work!
Added a new "suspendPeriodically" setting, which is activated by default. This setting tries to simulate load changes by periodically suspending and resuming the stress test program
Added a new "coreTestOrder" setting, which defaults to "Alternate" (for more than 8 cores/2 CCDs) or "Random" (max 8 cores/1 CCD). You can also define a custom order for the sequence in which the cores should be tested (e.g. "5, 7, 5, 1, 0, 7, 4")
Added more presets for Prime95: "Moderate", "Heavy" & "HeavyShort". See the config file for additional explanation about these presets
The priority of the stress test process is now set to "High" to prevent other processes from "stealing" processing power and produce false alarms due to low CPU usage
Starting a stress test program will not steal the focus anymore (or give it back immediately to the last opened window)
The script will now try to close the stress test program after pressing CTRL+C, if it is still running and using CPU processing power
The title of the terminal window is now set to "CoreCycler"
The approximate CPU frequency is now visible in the verbose output (but unfortunately it's not as accurate as e.g. HWInfo64 or Ryzen Master, which is why it's not in the main output)
All logs are now in the /logs directory
Added an "analyze_prime95_logfile.ps1" script to the /tools directoy, which can be used to determine the time it took for all FFT sizes to appear at least once for each iteration within a Prime95 log file
Added "CoreTunerX" to the /tools directory. See CXWorld/CoreTunerX of what it can do


----------



## lmfodor

spoonium said:


> Happy Easter!
> 
> *Version 0.8.0.0 is now available.*
> It includes support for Aida64 and Y-Cruncher!
> 
> *Download:*
> Releases · sp00n/corecycler
> 
> 
> *Changelog:*
> 
> Updated Prime95 to 30.5 build 2
> Support for Aida64 and Y-Cruncher! You can now define which stress test program to
> Added more presets for Prime95: "Moderate", "Heavy" & "HeavyShort". See the config file for additional explanation about these presets


Hi, I’m trying this last version and it’s really good to find core instabilities. I say that the new presets for P95 indicates that are for Rayzen 5000, why is that? What changes regarding the previous presets SSE, AVX..
I found that I pass the test with SSE but I couldn’t pass with the same settings with moderate or Heavy presets. I’m using the last both preset to stabilize my curve

Thanks! 



Sent from my iPhone using Tapatalk Pro


----------



## sp00n82

lmfodor said:


> I say that the new presets for P95 indicates that are for Rayzen 5000, why is that? What changes regarding the previous presets SSE, AVX..


Not quite, it says that the presets "Moderate", "Heavy" and "HeavyShort" are recommended in the "Curve Optimizer Guide Ryzen 5000" for stress testing. It's a guide written to help users with setting up the Curve Optimizer on Ryzen 5000 CPUs, available here: Leserartikel - Curve Optimizer Guide Ryzen 5000 & Guide Curve Optimizer Ryzen 5000.pdf

It's currently only available in German, but the author (not me) does plan to release an English version as well.


----------



## lmfodor

Hi, I read the German site with the overclocking guide. I could pass several heavy and heavy short cycles, however in the moderate test I found instabilities after several iterations. At first I thought that I hadn’t estimated the right the time for the core iteration. Then I set 20 minutes per core and after reading the German thread the author of the guide clarifies that this test would be affected by memory overclocked .. so that’s would be my case. I already have a memory oclked and even is stable maybe it can be conflicting with the test 

Regarding y-cruncher, I read here in OCN that the best test to find fast instabilities are the 15 and 16. Maybe they are for multi core .: do you think you can add to Core Cycler?

It is good AIDA for this kind of testing? I have the extreme version and I could buy the engineer. But I don’t know if it worth it for this specific test. What is the benefit of Aida vs P95 and Y-C?

Thanks!


Sent from my iPhone using Tapatalk Pro


----------



## sp00n82

Yes, every memory overclock can also have an effect on CPU stress testing. Therefore the best approach is to separately test memory and CPU overclocks, and only if both proved to be stable, combine them together. Otherwise you cannot really be sure if an error happened due to an unstable CPU or an unstable memory overclock. Eliminate the number of variables.
And even a thoroughly tested memory overclock could have an impact on CPU overclocking, as the IMC gets stressed more when the memory is overclocked, which could in turn reduce the OC capabilities of the CPU, as more heat & more voltage for the IMC could potentially affect the cores themselves as well.

Tests 15 and 16 on y-Cruncher are N32 and N64, both are already part of the preconfigured tests there.

And regarding Aida64, the main advantages of it are that a) it's simploy another stress test with another instructions and b) that with e.g. the CACHE stress test, you can achieve boost clocks on your cores compared to Prime95 and y-Cruncher, which could show even more of the edge case instabilities.
Also you don't necessarily have to buy the Engineer version for stress testing, you can use the portable Trial version for free for 30 days. Which should be enough to determine if you overclock is stable or not.


----------



## WhiskyKemp

Im probably being stupid.
But when I run the BAT I see loads of errors.
What am I doing wrong?

Add-Content : Could not find a part of the path 'C:\corecycler-0.8.0.0\corecycler-0.8.0.0\logs\CoreCycler_2021-04-18_12-24-05_PRIME95_SSE.log'.
At C:\corecycler-0.8.0.0\corecycler-0.8.0.0\script-corecycler.ps1:455 char:9

Add-Content $logFileFullPath (''.PadLeft(11, ' ') + ' + ...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 + CategoryInfo : ObjectNotFound: (C:\corecycler-0...PRIME95_SSE.log:String) [Add-Content], DirectoryNotFoundException
+ FullyQualifiedErrorId : GetContentWriterDirectoryNotFoundError,Microsoft.PowerShell.Commands.AddContentCommand


----------



## GribblyStick

sp00n82 said:


> Not quite, it says that the presets "Moderate", "Heavy" and "HeavyShort" are recommended in the "Curve Optimizer Guide Ryzen 5000" for stress testing. It's a guide written to help users with setting up the Curve Optimizer on Ryzen 5000 CPUs, available here: Leserartikel - Curve Optimizer Guide Ryzen 5000 & Guide Curve Optimizer Ryzen 5000.pdf
> 
> It's currently only available in German, but the author (not me) does plan to release an English version as well.


@sp00n82 
Hello sp00n82,
I spoke to Verangry over at computerbase to get his permission and went ahead and translated the pdf, trying to stick as close as possible to the original.
I'll add the link here to my google drive for the english version since you already mentioned them here.
That said, I would like to create a separate thread as well with updates maybe from the ryzen stability thread.

I would like to check with @Veii first though to see how/if that makes sense. I believe he is already working on something of his own?

For now, here is the link to the english version.
*I want to make it clear again to everybody, I DID NOT CREATE THIS GUIDE.
I merely translated it from the links provided by sp00n82. As such, the german version by Verangry / Darkearth27 should always be considered the originals and most up to date.*


----------



## sp00n82

WhiskyKemp said:


> Im probably being stupid.
> But when I run the BAT I see loads of errors.
> What am I doing wrong?
> 
> Add-Content : Could not find a part of the path 'C:\corecycler-0.8.0.0\corecycler-0.8.0.0\logs\CoreCycler_2021-04-18_12-24-05_PRIME95_SSE.log'.
> At C:\corecycler-0.8.0.0\corecycler-0.8.0.0\script-corecycler.ps1:455 char:9
> 
> Add-Content $logFileFullPath (''.PadLeft(11, ' ') + ' + ...
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> + CategoryInfo : ObjectNotFound: (C:\corecycler-0...PRIME95_SSE.log:String) [Add-Content], DirectoryNotFoundException
> + FullyQualifiedErrorId : GetContentWriterDirectoryNotFoundError,Microsoft.PowerShell.Commands.AddContentCommand


Does the /logs directory actually exist?


----------



## Veii

GribblyStick said:


> I spoke to Verangry over at computerbase to get his permission and went ahead and translated the pdf, trying to stick as close as possible to the original.
> I'll add the link here to my google drive for the english version since you already mentioned them here.
> That said, I would like to create a separate thread as well with updates maybe from the ryzen stability thread.
> 
> I would like to check with @Veii first though to see how/if that makes sense. I believe he is already working on something of his own?


I don't work on anything Curve Optimizer related
Decided to go my own way and keep AMD's limits up (for now) ~ with an added positive vcore to compensate for the negative allcore CO

But when it comes to the guide, i see flaws
The listed limits are wrong. I try to decipher how the writer got up with them through which testing.
But they are absolutely not identical to Matisse. Alone by running PBO Disabled i get vastly different values.
Soo there can't be "motherboard faking" in place.

Also am not sure if we should speak "stock" limits , when it's not a thing but arbitrary applied values
_(where SOC and any type of memOC will cut into these arbitrary stock limits)_
Real "limits" are FUSE limits, which are on:
5600X 122A
5800X 140A (5800X bypasses it's limits up to thermal headroom, but only the 5800X)
5900X 200A
5950X 200A

MSI boards in specific, get it down?, up to 210A ~ likely via telemetry faking
These limits existed since SMU 56.27 and keep existing till today (at least till 1201 = SMU 56.50)
I can go and figure the "stock" limits out if anybody wants ~ don't have them fully in my head right now
But these limits listed are not correct or only AVX1 correct.
There are stock programmed limits, but they are higher than the listed one
5800X again is a special unit, and only the 5900X & 5950X share the same "silicon" EDC limit ~ nearly identical PPT
Nothing comparable to Matisse at all 



GribblyStick said:


> I believe he is already working on something of his own?


I do have in backtrack a powerplan project, and a "unlock dual CCD units" project.
(Both of these have another active developer, where on the first one you already know the person here)
My focus atm still is 24/7 FCLK pushing and personal setup-creation
MemOC is slightly on hold, and powerplan is on hold till i get access to 1202 AGESA to confirm the changes/fixes
There are other small little projects, but i don't want to talk about them yet


----------



## Verangry

@Veii

Als Österreicher solltest du des deutschen ja mächtig sein, dann lies mal die Originale. (vielleicht ist die Übersetzung nicht korrekt)

Wenn ich TDP Klassen Limits schreibe, dann meine ich die Limits die AMD vorgibt und das sind eben 142 / 95 / 140 z.B. bei einer 105W TDP CPU (Standardwerte von AMD bestätigt)
Ich empfehle deswegen nichts höheres, weil es den Leuten selbst überlassen sein soll was sie da eingeben.

Ich verstehe nur nicht, wie du behaupten kannst, dass die Limits falsch seien, denn alle deutschen Reviewer haben die selben Limits angegeben (bei 105w TDP) also liegen alle falsch?

Was die MB Hersteller bei "Auto" machen ist eine andere Geschichte, aktuell hat MSI mit dem 1202er sogar ein neuen Powertable hinzugefügt, der mal greift, mal nicht, jenachdem ob man im CBS- oder OC Menü Einstellungen vornimmt (welches genau es war habe ich nicht herausfinden können, könnte aber sogar sein, dass es durch das einstellen verschiedener Settings in beiden Menüs gleichzeitig ausgelöst wird).

Ich würde dennoch gerne wissen, welche Limits deiner Ansicht nach korrekt sind.


----------



## Veii

Verangry said:


> @Veii
> 
> Als Österreicher solltest du des deutschen ja mächtig sein, dann lies mal die Originale. (vielleicht ist die Übersetzung nicht korrekt)
> 
> Wenn ich TDP Klassen Limits schreibe, dann meine ich die Limits die AMD vorgibt und das sind eben 142 / 95 / 140 z.B. bei einer 105W TDP CPU (Standardwerte von AMD bestätigt)
> Ich empfehle deswegen nichts höheres, weil es den Leuten selbst überlassen sein soll was sie da eingeben.
> 
> Ich verstehe nur nicht, wie du behaupten kannst, dass die Limits falsch seien, denn alle deutschen Reviewer haben die selben Limits angegeben (bei 105w TDP) also liegen alle falsch?
> 
> Was die MB Hersteller bei "Auto" machen ist eine andere Geschichte, aktuell hat MSI mit dem 1202er sogar ein neuen Powertable hinzugefügt, der mal greift, mal nicht, jenachdem ob man im CBS- oder OC Menü Einstellungen vornimmt (welches genau es war habe ich nicht herausfinden können, könnte aber sogar sein, dass es durch das einstellen verschiedener Settings in beiden Menüs gleichzeitig ausgelöst wird).
> 
> Ich würde dennoch gerne wissen, welche Limits deiner Ansicht nach korrekt sind.





Spoiler: German



Das Problem bei der ganzen Geschichte mit AMD ist, dass verschiedene Quellen verschiedene Informationen erhalten
Und sobald man die wirklichen Werte (nicht die sicheren Werte) anfrage, müsse man unter NDA stehen.
Ich selber habe nicht die exakten maximum Werte, den NDA und OCer passen nicht zusammen.

Was ich allerdings rauslesen kann, sind die Stock Werte welches die CPU vorprogramiert bekaam
Jedoch sind es "Arbitrary" (Platzhalter) Werte und keine Limits.
Von den FUSE Limits (hard-limits) möchte keiner sprechen. Weder Mr. Hallock noch andere Engineers

Über die Powertable Änderungen, die 4 neuen Sensoren und das umschriebene dLDO + FIT Q-Table verhalten, weiß ich allerdings ein wenig Bescheid
(CTR Berücksichtige es)

Der 5800X ist besonders, einer seiner haupt-orientierungs Werte ist tDIE sowie tJunction ~ neben FIT-Q Range und +/- dLDO_Injector headroom (voltage injection headroom im FIT-Q Table headroom)
Somit habe dieser keine fixen boost limits, aber ich kann von AVX2 limits ausgehen, welche FIT-Q fasst auf 0.00 erzwinge (y-cruncher bzw p95 ~ aber ich finde y-cruncher schlimmer)
* mehr zu dem später wenn ich ein Sample habe (1-2 Tage)
** wie im oberen post genannt, bypasse er seine fixierten PBO Werte und hällt sich nur ans Thermal Limit von 90°

Getested wird es auf PBO DISABLED @ 1800/3600
~ mit 900-900-940-980-1100 (Realistische Stock Limits)
(CPU VDDP, cLDO_VDDP, VDDG CCD, VDDG IOD, VSOC)

*STOCK*
*5600X*
PPT: 76W
TDC: 60A (ausgerechnet, da ich auf stock das limit nicht erreiche)
EDC: 90A

*5800X*
PPT: 142W
TDC: 95A
EDC: 140A

*5900X*
PPT:
TDC:
EDC:

*5950X*
PPT:
TDC:
EDC:

*EDC FUSE LIMITS:
5600X* - 122A (120A mit peaks auf 122A)
*5800X *- 166A (160A mit peaks auf 166A)
*5900X* - 200A (210A auf MSI Boards mit Telemetry faking)
*5950X *- 200A (die selben wie oben)

*SILICON HARDLIMITS @ Q1 2021
5600X*
PPT: 160W
TDC: 140A
EDC: 185A

*5800X*
PPT: 170W
TDC: 140A
EDC: 195A

*5900X*
PPT:
TDC:
EDC:

*5950X*
PPT: 200W
TDC: 160A
EDC: 250A

Leider sind diese Hard-Cap Limits von AMD immer noch weit entfernt von dem was uns consumern geboten wird. (besonders 5600X Nutzern)
Bevor die CPUs auch nur eine Chance haben die Silicon Limits (dynamic) zu erreichen, hängen wir im EDC FUSE limit

Bitte verwechsel nicht die TDP Werte mit den vorkonfigurierten Werten.
Mir ist klar dass ASUS, MSI & Gigabyte andere Silicon Scalar Werte haben bzw diese durch telemetry faking "erweitern"
ASRock als Vergleich mache dies nicht, aber da PBO von Natur an die V/F curve greift, muss es auf DISABLED sein

AMD's TDP limits sollten eigentlich bei PPT greifen,
Allerdings ist der wirkliche focus auf EDC (A)
Worin memOC sowie SOC state eine große übergreifende Rolle spielen & dementsprechend "das boosting Verhalten" ändern. Im existierenden "Powerbugdet"
Somit mein Tipp,
~ Bleibe im EDC FUSE limit, oder erweitere das Stock Boosting Limit ~ fals man interesse fürs memOC hat
* Genauere Hardlimits dürften nicht genannt werden, den das Silicon Verhalten (FIT) spielt hier eine große Rolle.
** Labor-Testwerte bleiben leider ein Firmengeheimniss. Aber nur die EDC Werte spielen eine Rolle für die Lebensqualität unserer Chips.
PPT sehe als Netzteil Limit an, bzw Cooler Limit. Dies ist ebenso ein limiter in Notebooks ~ worin STAMP noch obendrauf greift.


===============


Spoiler: English



The Dilemma on this whole Question, starts with AMD's limited information sharing. Where each of the Sources get different values.
And in-case you where interested about the actual hard-limits & get permission to ask, it would require you to sign an NDA.
As for myself, i don't stand under any NDA ~ simply as NDA's and OCer don't fit together.
* But there is stuff i should not talk about

What i certainly can read out, are the stock values you requested and talked about.
Although these are indeed Arbitrary values, which do not follow any limits whatsoever 
About the actual FUSE Limits (closer to hardlimits) nobody wants to talk about and denies their existance.
Neither Mr. Hallock nor other Engineers

On the question about the new changes on >1.2.0.1, including the 4 new active sensors & rewritten dLDO + FIT Q-Table, i do have some information *
(CTR's functionality does take them into account)

About the 5800X mentioned earlier,
Like mentioned above, it is by AMD a "Gaming CPU" and bypasses it's limit on SSE and AVX1 loads
It's orientation is tDIE and tJunction ~ aside from FIT-Q range within +/- dLDO_Injector range/headroom
Soo in short ~ It doesn't have stock limits like the remain lineup and defines them dynamicly up to FIT
But i can go from the sillicon health limits under harsh AVX2 loads, which should max out FIT-Q and let no dLDO_Injection range left (voltage injection)
(for example with y-cruncher or p95, but i find y-cruncher to be more aggresive)
* more infromation on this topic when i get a sample infront of me (1-2 days) ~ got a sample
** like mentioned on my post earlier, it bypasses it's set PBO limits and only focuses on a Thermal limit of 90°

Everything is tested under PBO DISABLED @ 1800 FCLK / 3600MT/s
~ with 900-900-900-940-980-1100 (using realistic stock voltages)
(CPU VDDP, cLDO_VDDP, VDDG CCD, VDDG IOD, VSOC)

*STOCK*
*5600X*
PPT: 76W
TDC: 60A (calculated as my sample doesn't reach max TDC on stock without boost overrides)
EDC: 90A

*5800X*
PPT: 142W
TDC: 95A
EDC: 140A

*5900X*
PPT:
TDC:
EDC:

*5950X*
PPT:
TDC:
EDC:

*EDC FUSE LIMITS:
5600X* - 122A (120A with peaks to 122A)
*5800X *- 166A (160A with peaks to 166A)
*5900X* - 200A (210A with telemetry faking on MSI)
*5950X *- 200A (same thing as above)

*SILICON HARDLIMITS @ Q1 2021
5600X*
PPT: 160W
TDC: 140A
EDC: 185A

*5800X*
PPT: 170W
TDC: 140A
EDC: 195A

*5900X*
PPT:
TDC:
EDC:

*5950X*
PPT: 200W
TDC: 160A
EDC: 250A

Sadly there is a big difference between Silicon Limits and EDC Fuse limits defined by FIT. (especially 5600X users)
We consumers still are artificially limited. Before our units can ever reach Silicon FIT limits (dynamic), they hang on the EDC FUSE limit.

Please don't cross-compare AMD Specified TDP Values, with actually on stock configured Precision Boost values.
I am in clear that MSI, Gigabye & ASUS do telemetry faking, and have different predefined Auto values for the Scalar & "Motherboard Limits"
ASRock in comparison doesn't do telemetry faking & the bios is quite barebones. But because PBO on it's nature modifies the V/F curve, it has to be explicitly DISABLED
* Motherboard limits do not bypass EDC FUSE limits

AMDs Paper TDP Limits should in theory trigger on PPT,
But in reality they do focus on EDC (A)
Where memOC including V-SOC do have a big influence on our "boosting powerbudget" , simply as they go into this EDC limit.
Soo my advice,
~ Stay within the EDC Fuse Limit, or manually extend the stock boosting limit ~ if you want to care about memOC without eating away the CPU Boosting budget
* As for more accurate (higher) Hardlimits, i'm sorry but i should not speak about it ~ also because FIT dynamic limits depend on the silicon quality 
** When it comes to Labor-Values, these remain a Company-Secret. Just for us only the EDC Values matter, when it comes to silicon health and integrity of it.
PPT you can see as simple PSU Hard-Limiter, or Cooler Capability Limit. It also is a limit on Notebooks ~ just that STAMP integrity, is also included into the limiting.


There are still things i should not talk about
Be it because of the respect for the supportive people who helped me, or because the information is not 100% clear
I don't have any active NDA right now, but in order to keep up respect to the people who have one and still helped me ~ i prefer not to share everything 

But overall, i want to thank you @Verangry - for all the work you do and support towards the german community.
The powerplan for Matisse who YOU, L3tum & masterleros ~ designed, was one of the most valuable resources and inspiration for an upcomming powerplan for Vermeer 
I did end up rewriting it fully and it's current state is nearly 100% compatible with CTR and dLDO modifications, but it needs a bit more work and finally a non broken 1202 update ~ to confirm stability on it

I've seen you helped on many other projects on ComputerBase and i think HWLuxx too ?
Just want to say Thank You !, now that i could catch you~

But to stay on this Thread Topic:
I personally don't think, any user should be worried about their stock limits and voltage overriding's when using PBO + CO
They should be worried about the boost override, which does modify once more the V/F curve
But they can be free to run 175-145-400A , like i do. With lifted cTDP and Package Power Limits of 400W (CBS, SMU)
You won't be able to bypass the FUSE limit anyways, just for OC_Mode and CTR ~ move inside these limits or just poor LN2 on it 

PBO does add up a slight bit of allcore-voltage and it's good to keep a balance between higher input VID and lower VID by negative CO
I do also prefer to keep up AMDs CO limits (which could be figured out by CTR) and just change the positive and negative magnitude on all of them together (allcore CO does not wipe the predefined CO values by AMD)
But that's just "a different method of handling"
Redoing and bettering up AMDs CO values, can still lead to better results ~ soo i do support this project here fully 

I will be finishing up this post in the next 24h & edit it 
My supporters need to have more time, to run these tests for me
Sadly only have a 5600X here 
Don't want to let you wait that much @Verangry  but give me at least 24h more. 
Would like to doubleconfirm some values before the rest is public


----------



## Veii

Double post, site bugged out...
Please erase


----------



## Sam64

Thanks for this great tool @sp00n82, it helps a lot finding a stable curve setting.

"The listed limits are wrong" Well, this is funny. You are only mentioning EDC, Veii. What about PPT and TDC? Verangry mentiones TDP Limits, which is not only about EDC. And of course, 142/95/140 ARE the stock limits of 5900/5950X. How you handle these limits, is your choice of course. Maybe you should add a reclaimer "for high risk users only" on your statments...


----------



## Veii

Sam64 said:


> Thanks for this great tool @sp00n82, it helps a lot finding a stable curve setting.
> 
> "The listed limits are wrong" Well, this is funny. You are only mentioning EDC, Veii. What about PPT and TDC? Verangry mentiones TDP Limits, which is not only about EDC. And of course, 142/95/140 ARE the stock limits of 5900/5950X. How you handle these limits, is your choice of course. Maybe you should add a reclaimer "for high risk users only" on your statments...


I don't understand what you mean
The first approach was "they looked wrong"
The 2nd approach after manual testing, where i mentioned "i can retest it if needed" ~ where surprisingly similar, but still slightly bit off

The 5900X and 5950X values are work in progress , and the post will update it with the correct values
There is no space for personal flavor on the post above
It's the proconfigured arbitrary values how the bioses are on the current state ~ where the real silicon limits are much higher, but on the current date of writing "limited" for us enthusiasts

Although limited , the stock arbitrary values end up not mattering at all (if you read the whole post ~ which you could in two languages)
Simply "as everything will fall back to the EDC-FUSE limit, which you can not bypass by any methods, unless going to OC-MODE = CTR or Allcore"

But i give you a point that it might have been too confusing for non trusting people, soo i want to attach this little post here too:








NEW!!! DRAM Calculator for Ryzen™ 1.7.3 (overclocking...


Nope, not stable at all. I don't get it man, seems like there is some kind of incompatibilitie issie with my new RAM and system. No matter what speed, voltage or whatever its not stable anymore and it triggers WHE errors...




www.overclock.net




However you turn it,
The endresult is ~ "it doesn't matter what you set" 

Stock values are arbitrary and do not follow neither AMDs paper-written limits (TDP on paper ≠ PPT, but should be)
You can not exceed the EDC FUSE limit by any chance under Precision Boost, and that's where everything ends up at / if we speak degradation, danger or anything range wise
If you do indeed want to know the nearly highest limits a user "should orient", then it's to follow the Hardlimits posted at the current state. * They are in reality a bit higher, but that's trade-secret.
* following them in-case ASUS users want to utilize dynamic OC mode switching, which should have at least some TDC limit in place.

That's about it,
I don't know what you missunderstood, but "Limits doesn't matter"
Not on Vermeer at-least.
"It doesn't matter", as there is a huge list of protectors and auto adjusters + cache boosters in place
Limiting them lower only gifts performance and limits Cache access time + L3 performance. A limit without reason , purely because of FUD (Fear under denial) 

Please at least let me finish the remain samples, before you judge on it
and maybe re-read it, to get my point
It really doesn't matter and Pre-1202 , post 1.1.0.0*D* a higher EDC limit of 400A for example, is needed in order to lift one of the limits and let cache boost up ~ to the limit of what FIT allows
Also NO, the CPU won't overvolt itself that way and degrade. It's "impossible" on Precision Boost mode to exceed the FUSE limits with FIT in place. Damage-Overvolting is not possible

EDIT:
I really don't know how to bring it over with other words

They are slightly bit off for "stock arbitrary values" ~ but nearly correct
They have no weight as "limits to follow" and will change in the bios update future. Ampere pushed to silicon = FUSE limits are to follow, or HardLimits if you want to go madman mode and bypass FIT
At the end, the listed "limits" by Verangry are slightly bit off, and are no "limits"
It's a good orientation point every user can test for themself, yes ~ but they still are a tiny bit off & that was the main intention of my post

The "HardLimits" to the extend i can share & the explanation, is just a little bonus 
All ends up at the FUSE limit on the current date, and the Hardlimit on the silicon living-date.
They are a bit different than the listed ones, but it is a changing optimization topic ~ on which i shall not speak more


----------



## Sam64

Again, it's ok to make your personal conclusion based on your findings, Veii. But i would never recommend "limits doesn't matter" for normal users as a general rule. Even AMD does not recommend to exceed these limits: You lose you guarantee, if you do it, right?. For me it's also useless ignoring these limits when it comes to find the best balance between performace and efficicency. You are playing around these limits by yourself, right? So it doesn't matter? Again: I understand your approach and it's absolutely ok to play around these limits to find whatever you like, but you cannot claim this as a general rule.


----------



## Veii

Sam64 said:


> Again, it's ok to make your personal conclusion based on your findings, Veii. But i would never recommend "limits doesn't matter" for normal users as a general rule. Even AMD does not recommend to exceed these limits: You lose you guarantee, if you do it, right?. For me it's also useless ignoring these limits when it comes to find the best balance between performace and efficicency. You are playing around these limits by yourself, right? So it doesn't matter? Again: I understand your approach and it's absolutely ok to play around these limits to find whatever you like, but you cannot claim this as a general rule.


Ehm, no
What you quote is also not what i wrote, and not the conclusion i took


Veii said:


> There is no space for personal flavor on the post above


No personal flavor or personal taste of secureness

Thought i should add a bit more information,
The arbitrary limits set in place on stock - are predefined to meet:

at 1800 FCLK with 1.1v SOC as limit , like tested above
under the CPUs capability within maximum rated boost (4.65 for a 5600X, 4.95 for a 5900X)
predefined V/F curve with the intention to hit 100% up to specific workloads, soo supplied voltage lowers and score increases
all like 1.) within SOC powerdraw

They remain arbitrary, however you want to turn it
Like on Matisse, also on Vermeer the performance increases if you hit the limits and let it lower voltage. (optimally peaking 98% TDC and 100% EDC on Cinebench R20)
I think we do know at this point, that undervolting not only helps stay within the powerbudget but also helps increase the remain boosting powerreserves

If you push FCLK higher, your reserves get smaller and smaller
If you increase V-SOC , your reserves on the predefined arbitrary values (not limits) diminishes further and further
These arbitrary limits are there for normal consumers at 1800 FCLK to hit the best efficiency to boosting result
They are not there as any type of safety limits, but as giving bonus for the users ~ to have better results. And a bit as a safety net within the range of +30 CO.
If it wasn't designed that way, the RMA rate would be higher. As provided voltage chokes, soo provided frequency throttles if it doesn't fake it. User sees a chip not meeting boosting targets. User returns the unit.

If you work with CO , the whole story changes.
First of all, every CPU has predefined own CO values. Which are gettting up to date by FIT. They and FIT-Q + CPPC rating will change up to user influenced vcore , user influenced scalar, and user influenced allcore-CO
Alone by changing and playing with CO, you technically already do Telemetry Faking.
The arbitrary limits that are set on stock, do not matter here as you "fake" them and go around them
... soo much about "secureness to the user" ... 

They end up arbitrary and not optimal even if you as a consumer run 1900 FCLK. But for example the FUSE limit, is designed more loose to meet the 1900 FCLK target.
I can remind you about the 1900 FCLK lock attempt on AGESA 1.1.0.0 *C* , before the Patch *D* ABL patch
(which doubled cache bandwidth and allowed dynamic boosting to function upon EDC and other limits)
I should also remind you the overboost spike issues which hit 50ghz and higher , because of the "not so optimal" , "too early" dynamic boosting, which was unlocked to users.
It's a too big book to try and read from, but again the values that you try to follow where never ment for anyone who uses CO (VID faking) or any user who tries to run 1900 FCLK and higher
They have a reason to exist, but are "not limits"
Please understand that.
Users appear to have control over their CPUs , but their control is nearly also "only arbitrary" 
Which i personally find very sad, and continue with #FreeRyzen demanding higher FUSE limits and no FCLK locks
Someday you'll understand what i mean. Can't force you to accept what i try to tell you, and can't put a viewpoint on you when your reality is different
Ty for the talk & read, tho. I'm happy that you took your time to read my little lesson


----------



## WhiskyKemp

sp00n82 said:


> Does the /logs directory actually exist?


No, all I’ve done is unzipped the file direct from GITHub, I didn’t realise I had to manually create it. 
will give that a try. Thanks


----------



## sp00n82

WhiskyKemp said:


> No, all I’ve done is unzipped the file direct from GITHub, I didn’t realise I had to manually create it.
> will give that a try. Thanks


Normally you shouldn't need to, the (empty) directory is included in the zip file.

// Edit
I see, after cloning directly from GitHub there will be no /logs directory, only in the release files.
I'll probably have to add a check for it.


----------



## wuttman

Love the tool. I personally use it with 2x scalar to push silicon a bit higher and when testing is complete I will step my curve down by 1, just in case. Also I've added some extra heat, to keep cpu temperature around 75C, where fit throttling starts to kick in.


----------



## wuttman

But it would be nice to be able to run 2 cores at once, it still stays at the max boost clock for me, if I run prime manually, but sadly it doesn't switch cores at all, according to hwinfo64.


----------



## sp00n82

wuttman said:


> But it would be nice to be able to run 2 cores at once, it still stays at the max boost clock for me, if I run prime manually, but sadly it doesn't switch cores at all, according to hwinfo64.


At least in all my tests the faster core clocked down to the speed of the slower core.
Not sure what you mean that it doesn't switch cores.


----------



## wuttman

sp00n82 said:


> Not sure what you mean that it doesn't switch cores.


I launch prime manually and effective clocks are stuck high on first two cores it randomly picked, according to HWinfo.


----------



## sp00n82

wuttman said:


> I launch prime manually and effective clocks are stuck high on first two cores it randomly picked, according to HWinfo.


Ah. Yes of course. You'd have to manually switch the core affinity via the Task Manager, which is the whole reason I started writing this script. 😁


----------



## wuttman

Looks like prime avx with two threads is more demanding than default config. I managed to keep cores around 75C, so it boosting to the max most the time and high temperature brings additional strain to stability.


----------



## KedarWolf

With Prime95 I run this. Temps stay under 80C and pretty good at finding unstable cores. 

On my 5950x.



Code:


Log Level set to: ......... 2 [Writing debug messages to log file]
Stress test program: ...... PRIME95
Selected test mode: ....... SSE
Logical/Physical cores: ... 32 logical / 16 physical cores
Hyperthreading / SMT is: .. ON
Selected number of threads: 2
Runtime per core: ......... 6 MINUTES
Suspend periodically: ..... ENABLED
Restart for each core: .... OFF
Test order of cores: ...... DEFAULT (ALTERNATE)
Number of iterations: ..... 10000
Selected FFT size: ........ 128-128 (128K - 128K)


----------



## sp00n82

I've updated the script to 0.8.1.0.
For the script there's no real difference to 0.8.1.0 RC5 though except the version bump.









Releases · sp00n/corecycler


Stability test script for PBO & Curve Optimizer stability testing on AMD Ryzen processors - sp00n/corecycler




github.com






 Added an auto option for the runtimePerCore setting. With this option, for Prime95 all FFT sizes of the selected preset will be tested for one core before it continues to the next core, where it will also test all the FFT sizes, etc.
For y-Cruncher and Aida64 the "auto" mode uses a fixed runtime of 10 minutes per core due to the lack of detectable progress.
 You can now also enter a custom FFT range for the FFTSize setting in the Prime95 section, e.g. something like 36-1344. This eliminates the need to use the CUSTOM mode to define a custom FFT range (although you can still use the CUSTOM mode of course).
 The verbosityMode setting has been renamed to logLevel
 The script should now also work if started as an administrator
 Fixed a couple of bugs with case sensitivity and trailing spaces in the config file
 Rewrote the error detection for Prime95 log files, hopefully with more accurate detection
 Improved error detection when CPU usage was too low


----------



## gamevicio

sp00n82 said:


> I've updated the script to 0.8.1.0.
> For the script there's no real difference to 0.8.1.0 RC5 though except the version bump.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Releases · sp00n/corecycler
> 
> 
> Stability test script for PBO & Curve Optimizer stability testing on AMD Ryzen processors - sp00n/corecycler
> 
> 
> 
> 
> github.com
> 
> 
> 
> 
> 
> 
> Added an auto option for the runtimePerCore setting. With this option, for Prime95 all FFT sizes of the selected preset will be tested for one core before it continues to the next core, where it will also test all the FFT sizes, etc.
> For y-Cruncher and Aida64 the "auto" mode uses a fixed runtime of 10 minutes per core due to the lack of detectable progress.
> You can now also enter a custom FFT range for the FFTSize setting in the Prime95 section, e.g. something like 36-1344. This eliminates the need to use the CUSTOM mode to define a custom FFT range (although you can still use the CUSTOM mode of course).
> The verbosityMode setting has been renamed to logLevel
> The script should now also work if started as an administrator
> Fixed a couple of bugs with case sensitivity and trailing spaces in the config file
> Rewrote the error detection for Prime95 log files, hopefully with more accurate detection
> Improved error detection when CPU usage was too low


The runtimePerCore auto feature is perfect, before I had to set 20min always to process each core, sure this will help a lot. Thanks for all this work for the community.


----------



## gamevicio

thigobr said:


> After testing hours of y-cruncher/TM5 memory test and even Prime95 AVX multi thread without issues I tried your script without any modifications... To my surprise I got rounding errors at stock, after a clear CMOS + load defaults!
> 
> I was thinking my CPU was stable but it seems it's actually not!
> 
> Regarding the script it works well, thanks for sharing and keep the good work!


Same here, i found out that one of my best cores needed +9 to run without errors (5800x), i really do not know if should send it to RMA, because the core that was having the problem was my prefered software and hardware core and i noticed that most of the time, it has receiving way less voltage than what i think the "main core" should receive.


----------



## thigobr

@gamevicio You should ask for RMA... The CPU should be stable on any software at stock settings. You will find out at some point some real life software that triggers crashes or reboots like I did... For me one of my old games triggered reboots consistently: Need For Speeed Payback. After RMA my new CPU works out of the box without any issues using the exact the same config as before.


----------



## gamevicio

thigobr said:


> @gamevicio You should ask for RMA... The CPU should be stable on any software at stock settings. You will find out at some point some real life software that triggers crashes or reboots like I did... For me one of my old games triggered reboots consistently: Need For Speeed Payback. After RMA my new CPU works out of the box without any issues using the exact the same config as before.


You're probably right, the sad thing is that at least on ClockTuner ranking, my sample is gold and have an high efficience until it gets to the max boost clock (4850Mhz), after that is hard to do any boost override. Probably my chip has some kind of frenquency falloff (I dont remember if this is the correct term). I've also seen you on another thread having the same problem with the 5950x, so I imagine it's a recurrent problem on 8 cores per CCX zen 3.

So I will try to contact RMA this week, thanks man (vlw mano kkk). I hope that I get a good sample next time...


----------



## sp00n82

I just released version 0.8.2.0.

*HEADS UP:*
Apparently there was a bug in the included versions of Prime95 (30.4 resp. 30.5) that could have led to incorrect Fatal Errors in Prime95 itself. In the now included Prime95 version 30.6 build 4 this bug should now be fixed according to the developer (see here: mersenneforum.org - View Single Post - Prime95 v30.4/30.5/30.6)

Anybody that previously has experienced inexplicable error messages even in stock settings should therefore update to this version!


*Download:*








Releases · sp00n/corecycler


Stability test script for PBO & Curve Optimizer stability testing on AMD Ryzen processors - sp00n/corecycler




github.com






*Changelog:*

 Apparently there was a bug in Prime v30.4 & 30.5 that could lead to incorrect fatal errors. Updated to Prime 30.6 build 4, which should have fixed this issue according to the developer (see here: mersenneforum.org - View Single Post - Prime95 v30.4/30.5/30.6)
 Added a final summary when terminating the script
 The script now prevents sleep/hibernate/standby while it is running


----------



## sp00n82

Bugfix release 0.8.2.1:

Fixed a problem when the script was inside a directory path that contained a space
Also fixed errors when the logs directory didn't exist (it is now automatically created)









Releases · sp00n/corecycler


Stability test script for PBO & Curve Optimizer stability testing on AMD Ryzen processors - sp00n/corecycler




github.com


----------



## FightCat

Hello @sp00n82 any idea why I'm getting this with my R9 5900x?


----------



## sp00n82

FightCat said:


> Hello @sp00n82 any idea why I'm getting this with my R9 5900x?
> 
> View attachment 2489944


It seems you entered a string for the stressTestProgram setting that's not supported by the script, and additionally the check for that wasn't working correctly.
I just fixed this, you can try the new 0.8.2.3 version, it should now correctly complain if the stress test program isn't supported.

Additionally you could attach your config.ini file.









Releases · sp00n/corecycler


Stability test script for PBO & Curve Optimizer stability testing on AMD Ryzen processors - sp00n/corecycler




github.com


----------



## KedarWolf

sp00n82 said:


> It seems you entered a string for the stressTestProgram setting that's not supported by the script, and additionally the check for that wasn't working correctly.
> I just fixed this, you can try the new 0.8.2.3 version, it should now correctly complain if the stress test program isn't supported.
> 
> Additionally you could attach your config.ini file.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Releases · sp00n/corecycler
> 
> 
> Stability test script for PBO & Curve Optimizer stability testing on AMD Ryzen processors - sp00n/corecycler
> 
> 
> 
> 
> github.com


CoreCycler-v0.8.2.3

Starting the CoreCycler...
FATAL ERROR: The selected stress test program "prime95" could not be found!


You can find more information in the log file:
D:\CoreCycler-v0.8.2.3\CoreCycler-v0.8.2.3\logs\CoreCycler_2021-05-10_19-30-35.log
When reporting this error, please provide this log file.
Press Enter to exit:

CoreCycler-v0.8.2.2 works though.


----------



## FightCat

sp00n82 said:


> It seems you entered a string for the stressTestProgram setting that's not supported by the script, and additionally the check for that wasn't working correctly.
> I just fixed this, you can try the new 0.8.2.3 version, it should now correctly complain if the stress test program isn't supported.
> 
> Additionally you could attach your config.ini file.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Releases · sp00n/corecycler
> 
> 
> Stability test script for PBO & Curve Optimizer stability testing on AMD Ryzen processors - sp00n/corecycler
> 
> 
> 
> 
> github.com





Code:


Starting the CoreCycler...
FATAL ERROR: The selected stress test program "prime95" could not be found!


You can find more information in the log file:
C:\CoreCycler\logs\CoreCycler_2021-05-11_02-32-03.log
When reporting this error, please provide this log file.
Press Enter to exit:


----------



## sp00n82

Ah great, I destroyed the whole check, fixing...


----------



## FightCat

Hello,

With 0.8.2.2. I got it running by editing config.ini line:

"*stressTestProgram = prime95*" instead of it being all caps as in *PRIME95*.

It might have to do with my language being Turkish and we got lower-case "I" in our alphabet as a seperate-sounding letter.


----------



## sp00n82

FightCat said:


> Hello,
> 
> With 0.8.2.2. I got it running by editing config.ini line:
> 
> "*stressTestProgram = prime95*" instead of it being all caps as in *PRIME95*.
> 
> It might have to do with my language being Turkish and we got lower-case "I" in our alphabet as a seperate-sounding letter.


No, I broke the check, it should recognize upper or lower case just fine.
And it should now in 0.8.2.4









Releases · sp00n/corecycler


Stability test script for PBO & Curve Optimizer stability testing on AMD Ryzen processors - sp00n/corecycler




github.com





It may still be the case that it will break if your lower case "i" has a different code than the ASCII "i", but the lower/upper case should now really work.

// Edit
For example, "prіme95" is not the same as "prime95". The former one uses a cyrillic "i" letter (U+0456) instead of the ASCII "i" (U+0069).


----------



## FightCat

sp00n82 said:


> No, I broke the check, it should recognize upper or lower case just fine.
> And it should now in 0.8.2.4
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Releases · sp00n/corecycler
> 
> 
> Stability test script for PBO & Curve Optimizer stability testing on AMD Ryzen processors - sp00n/corecycler
> 
> 
> 
> 
> github.com
> 
> 
> 
> 
> 
> It may still be the case that it will break if your lower case "i" has a different code than the ASCII "i", but the lower/upper case should now really work.
> 
> // Edit
> For example, "prіme95" is not the same as "prime95". The former one uses a cyrillic "i" letter (U+0456) instead of the ASCII "i" (U+0069).


Same with this. I had to manually lowercase "PRIME95" in the .ini to "prime95" so it could find the test and run.


----------



## sp00n82

FightCat said:


> Same with this. I had to manually lowercase "PRIME95" in the .ini to "prime95" so it could find the test and run.


Still with 0.8.2.4? I can even enter stressTestProgram = pRimE95 there and it's working for me. 

Can you send me the (non working) config.ini and the log file?


----------



## ManniX-ITA

Just a bit of advice, Prime95 SSE is still randomly failing with my 5950x on the Unify-X with AGESA 1.2.0.1
Spent days calibrating, found perfect settings passing OCCT 10 hours and 6 cycles of CoreCycler.
Then after 2 days I've ran it again and 3 cores failed always in 1 second.
Today they can all pass.


----------



## garbage914

Hello, I ran this test and got the following error. Could you please help with any recommendation? I'm on a Gigabyte 550B Vision D-P with a 5950x and an EKWB Water Loop. I'm overclocking my 3200 mHz memory to 3600 Mhz.








My PBO settings are currently these:


----------



## sp00n82

garbage914 said:


> Hello, I ran this test and got the following error. Could you please help with any recommendation? I'm on a Gigabyte 550B Vision D-P with a 5950x and an EKWB Water Loop. I'm overclocking my 3200 mHz memory to 3600 Mhz.
> View attachment 2511996
> 
> My PBO settings are currently these:
> View attachment 2511997


Yes. Your settings are unstable. End.

Also it's to separately test CPU and RAM overclock unless you're sure one of them is 100% (or near that) stable. Otherwise you can never be sure if the error actually came from the overclock of your CPU or your RAM. Eliminate the variables.


----------



## Sleepycat

garbage914 said:


> Hello, I ran this test and got the following error. Could you please help with any recommendation? I'm on a Gigabyte 550B Vision D-P with a 5950x and an EKWB Water Loop. I'm overclocking my 3200 mHz memory to 3600 Mhz.
> View attachment 2511996
> 
> My PBO settings are currently these:
> View attachment 2511997


It's Core 0, if the other cores are not erroring out. You have to set Curve Optimiser to per core, give Core 0 a zero CO magnitude and retest.


----------



## garbage914

sp00n82 said:


> Yes. Your settings are unstable. End.
> 
> Also it's to separately test CPU and RAM overclock unless you're sure one of them is 100% (or near that) stable. Otherwise you can never be sure if the error actually came from the overclock of your CPU or your RAM. Eliminate the variables.


Makes a lot of sense (I now saw you posted that a few pages back). Thank you. Testing again with no memory overlocking. Do you think 6 minutes per core is the minimum you would do? In terms of getting ballpark estimates, is say 4 minutes per core ok?


----------



## garbage914

Sleepycat said:


> It's Core 0, if the other cores are not erroring out. You see to set Curve Optimiser to per core, give Core 0 a zero CO magnitude and retest.


That's helpful. Thank you.


----------



## ManniX-ITA

garbage914 said:


> In terms of getting ballpark estimates, is say 4 minutes per core ok?


6 minutes is already a bit too less.
If you can, use 10 or 16 minutes.
It's an enormity for a 5950x but provides much more reliable results.

In the meantime I confirmed again that using P95 my cores are crashing randomly.
Switched CoreCycler to use y-cruncher and I get same results as OCCT.


----------



## sp00n82

Random errors for me mean that the setting is still unstable. You may see this differently of course. Earlier versions of the 30.x branch of Prime95 seemed to be plagued by a bug that produced random errors, but that should be fixed by now according to the developer. If you'd like to, you can also go back to e.g. version 29.8 by copying it in the test_programs/p95 folder (29.8 is also the version that OCCT uses internally).

I've said it before, I've had cores error out after 10, 14 nights of stress testing.
And also repeating myself, if in the "good old days" you considered a 12 hour Prime95 stress test as stable enough for your all core overclock, you'd now need to test every single core for these 12 hours to be able to have the same amount of confidence in the stability of your overclock, as you simply cannot test more than one core simultaneously for a PBO overclock.

12 hours per core in one session is pretty impractical of course, so you can split these 12 hours per core into shorter sessions over multiple nights.
And you should absolutely test other settings as well, e.g. AVX and AVX2 and other FFT sizes. Do not rely on only the default settings and consider your overclock to be stable just by these!  
While they are good to catch obvious errors rather quickly, in no way they guarantee a stable overclock just yet. You need to test so much more for this. The "auto" mode for the runtimePerCore setting comes in pretty handy here, as it will guarantee that all of the FFT sizes will be tested for each core before continuing to the next one.

Also, y-Cruncher may be a viable alternative, although it either had rebooted my system or ran through fine during my testing. Prime95 showed more errors for me quicker, but your mileage may vary of course.


----------



## ManniX-ITA

sp00n82 said:


> Random errors for me mean that the setting is still unstable. You may see this differently of course. Earlier versions of the 30.x branch of Prime95 seemed to be plagued by a bug that produced random errors, but that should be fixed by now according to the developer. If you'd like to, you can also go back to e.g. version 29.8 by copying it in the test_programs/p95 folder (29.8 is also the version that OCCT uses internally).


Thanks didn't know OCCT was using P95 code.

This randomness is very peculiar; some cores are crashing immediately.
It's not like they crash after 5 minutes or 1 hour.
P95 starts and crashes at the first FFT with Large or Huge.
Small lasts a few minutes.
And it's doing the same every single time.
If I power off and restart maybe they pass for a whole night for a couple of days.
Then they randomly start again failing in 1 second...
Running OCCT or y-cruncher they never fail a single time.

I'm checking Core 1 now that was crashing due to the telemetry too aggressive.
Passed 1h OCCT.
Once I've found a new telemetry setup, if I can, I'll try with P95 for 1 hour.
But this core was not one of those crashing in 1 second.


----------



## ManniX-ITA

I passed 1h40m OCCT hammering Core 1.
Now it crashes immediately with P95.
I've tested almost all versions till the oldest...
Wonder if there's any setting in the BIOS that could cause this weird behavior.
Will try to find out.


----------



## sp00n82

Yeah, OCCT uses a "headless" version of Prime95, i.e. it's custom modified to not produce any output window.
The renamed .exe file is placed as %TEMP%\OCCT\CPUOCCT\CpuOcct64.exe. You can still find the strings inside it indicating that it is indeed Prime95, and also the version number, which is 29.8. There may be other changes as well, although I doubt any changes to the actual stress test algorithms were made.
Also be aware that the suspendPeriodically setting is enabled by default in CoreCycler, which tries to simulate load changes by, well, periodically suspending and resuming the stress test (who would have thought!), which _should_ help in finding errors quicker than just running a "plain" stress test.

If you want I could take a look at your CoreCycler log file(s) and see if I can find something peculiar about these errors you're getting.
Maybe there's even some kind of bug still lurking around somewhere.


----------



## k4sh

Hey there,
I have tried your tool as it seems to be a good one to reveal cores undervolt failure.
I have tried different settings using the Prime95 test like 6mins default FFT, 20 mins default FFT and up to auto for the runtimepercor settings with Curves optimizer that i know it would fail while gaming.
Problem is that the test never showed any error, nor my computer crashed or rebooted.
Could someone tell me what would be a good test (settings) with this tool to behave like if my computer was in gaming mode ?


----------



## Art385

ManniX-ITA said:


> I passed 1h40m OCCT hammering Core 1.
> Now it crashes immediately with P95.
> I've tested almost all versions till the oldest...
> Wonder if there's any setting in the BIOS that could cause this weird behavior.
> Will try to find out.


Got same behavior. Core 1 and Core 2 will sometimes work for hours on CC - no errors. I think the crash is triggered randomly when script is suspending load on tested core and then restart. I think problem is with how motherboard behaves in this situation as sometimes it will let me run way lower offset then it should. Script is working fine but because of that using it takes way more time then it should. On other hand OCCT per core SSE found me proper offset after three cycles ~12 minutes then some retesting and I was on same offset that CC found after countless hours off testing.


----------



## sp00n82

Art385 said:


> Got same behavior. Core 1 and Core 2 will sometimes work for hours on CC - no errors. I think the crash is triggered randomly when script is suspending load on tested core and then restart. I think problem is with how motherboard behaves in this situation as sometimes it will let me run way lower offset then it should. Script is working fine but because of that using it takes way more time then it should. On other hand OCCT per core SSE found me proper offset after three cycles ~12 minutes then some retesting and I was on same offset that CC found after countless hours off testing.


You can easily disable the suspend and resume behavior in the config file if you believe it isn't helpful.


----------



## ManniX-ITA

Art385 said:


> Got same behavior. Core 1 and Core 2 will sometimes work for hours on CC - no errors. I think the crash is triggered randomly when script is suspending load on tested core and then restart.


When mines are failing with P95 they crash almost always at 448K FFT and at the very beginning of Large.
Doesn't have to run via CC, is doing the same when launched manually.

It's weird they all have passed in the past this count and still pass it sometimes.
The only way I found is to reduce the count dramatically, at least they don't crash immediately.

They are not the same kind of quality cores.
Core 1 is the best and Core 9 one of the worst.
They both always run around the negative count, so it would make sense.
But Core 7 and 8 are a good quality one in CCD1 an the best of CCD2.
I have validated them down to -28, doesn't make sense they need -10 or -5.

If OCCT is using P95 looks really unlikely that I can always pass over 1h per core and insta-fail using P95 directly.
I'll have to test for longer with OCCT to see if I can at least replicate once a fail in these cores.
Unfortunately OCCT is not flexible as much as CC on cycling options.


----------



## BoredErica

Interesting tool, nice work.


----------



## sp00n82

ManniX-ITA said:


> When mines are failing with P95 they crash almost always at 448K FFT and at the very beginning of Large.
> Doesn't have to run via CC, is doing the same when launched manually.
> 
> It's weird they all have passed in the past this count and still pass it sometimes.
> The only way I found is to reduce the count dramatically, at least they don't crash immediately.
> 
> They are not the same kind of quality cores.
> Core 1 is the best and Core 9 one of the worst.
> They both always run around the negative count, so it would make sense.
> But Core 7 and 8 are a good quality one in CCD1 an the best of CCD2.
> I have validated them down to -28, doesn't make sense they need -10 or -5.
> 
> If OCCT is using P95 looks really unlikely that I can always pass over 1h per core and insta-fail using P95 directly.
> I'll have to test for longer with OCCT to see if I can at least replicate once a fail in these cores.
> Unfortunately OCCT is not flexible as much as CC on cycling options.


There have been changes in the FFT algorithms between 29.8 and 30.x in Prime95, otherwise there wouldn't have been a bug in the earlier branches of 30.x. So a difference in the behavior between OCCT and the current version of Prime95 is to be expected.

You could manually test with v29.8. You could also use 29.8 with CoreCycler if you really wanted by replacing the files in the test_programs/p95 folder.

Unfortunately for OCCT you cannot easily force it to use another version, as it deletes and writes the files in the temp directory on every start of the benchmark.


----------



## ManniX-ITA

sp00n82 said:


> There have been changes in the FFT algorithms between 29.8 and 30.x in Prime95, otherwise there wouldn't have been a bug in the earlier branches of 30.x. So a difference in the behavior between OCCT and the current version of Prime95 is to be expected.
> 
> You could manually test with v29.8. You could also use 29.8 with CoreCycler if you really wanted by replacing the files in the test_programs/p95 folder.
> 
> Unfortunately for OCCT you cannot easily force it to use another version, as it deletes and writes the files in the temp directory on every start of the benchmark.


I've sent you the logs in a PM.
Tested almost all the versions of Prime95 from the oldest available and they all do the same.


----------



## sp00n82

ManniX-ITA said:


> I've sent you the logs in a PM.
> Tested almost all the versions of Prime95 from the oldest available and they all do the same.


The logs don't include the Prime95 version, so unfortunately it's impossible to tell from the logs which version of Prime95 was used.
I can tell however that you were using CoreCycler version 0.8.2.1, which is not the most recent one (that would be 0.8.2.4). However, the switch from the buggy version of Prime to the allegedly fixed one happened in 0.8.2.0, so at least this shouldn't be the problem.
Regarding switching to different Prime95 version, be aware that the last official version is 30.3 build 6. To download version 30.6 build 4, which is also used in CoreCycler by default, you need to go to their forum.


----------



## Sleepycat

I ran stability testing using an older version of CoreCycler (0.8.0.1) a while back and found stable settings with it. How much improvement would I see if I re-tested with 0.8.2.4? Would the testing with 0.8.2.4 allow lower voltages for the same clock speed compared to 0.8.0.1? Or does the old bug not work in that way?


----------



## ManniX-ITA

sp00n82 said:


> The logs don't include the Prime95 version, so unfortunately it's impossible to tell from the logs which version of Prime95 was used.


The logs I've sent I think were all with the included version.



sp00n82 said:


> I can tell however that you were using CoreCycler version 0.8.2.1, which is not the most recent one (that would be 0.8.2.4). However, the switch from the buggy version of Prime to the allegedly fixed one happened in 0.8.2.0, so at least this shouldn't be the problem.


Yes, I'm lazy 
Added a lot of comments in the ini so I didn't switch yet.



sp00n82 said:


> Regarding switching to different Prime95 version, be aware that the last official version is 30.3 build 6. To download version 30.6 build 4, which is also used in CoreCycler by default, you need to go to their forum.


You can download all the released versions here:



www.mersenne.org - /ftp_root/gimps/



I've tested a dozen and they all do the same, even version 29.1

ERROR: 15:54:32
ERROR: Prime95 seems to have stopped with an error!
ERROR: At Core 1 (CPU 2)
ERROR MESSAGE: FATAL ERROR: Final result was 8F543F24, expected: 6E92CE47.
ERROR: The error likely happened at FFT size 448K

Always failing in record time at 448K.

Tested again with OCCT the worst core for 2 hours and didn't fail.
But I know that a more aggressive count will make fail OCCT; error detection works.

My theory so far is that the AGESA throttling of Prime95 fails. It happened already once in the past.
But it's not doing it regularly, I'll have to set a blank profile and hunt if there's a specific option triggering it.
OCCT P95 is probably different enough to not be recognized as P95 and therefore not triggering the evil throttling.

About OCCT, I know how it starts.
There's an exported function "start" that accepts an integer as input.
But I have no idea how it's communicating the options for the run and how is getting back the results.
Which is a pity as using it in CoreCycler would be interesting.

I'm trying to compile my own version of P95 but it's a gigantic mess... clearly the intention is that you don't 
If I can succeed maybe I can create a version different enough to prove that AMD's throttling is messing up with it.


----------



## sp00n82

Sleepycat said:


> I had run stability testing using an older version of CoreCycler (0.8.0.1). I have found stable settings with that. How much improvement would I see if I re-tested with 0.8.2.4? Would the testing with 0.8.2.4 allow lower voltages for the same clock speed compared to 0.8.0.1? Or does the old bug not work in that way?


I have never experienced the Prime95 bug myself, so I cannot really comment on that. As far as I have understood the issue, it would have eventually produced errors even if running with stock settings, i.e. no overlocking/PBO at all.
So I'd say no, if you were able to find a stable setting with CoreCycler that was using an earlier Prime95 version, the new version will not allow for lower voltages. But I'm not 100% certain.




ManniX-ITA said:


> Added a lot of comments in the ini so I didn't switch yet.


I don't think there was a change in the config syntax between these version, so you could easily re-use your config file.



> My theory so far is that the AGESA throttling of Prime95 fails. It happened already once in the past.
> But it's not doing it regularly, I'll have to set a blank profile and hunt if there's a specific option triggering it.
> OCCT P95 is probably different enough to not be recognized as P95 and therefore not triggering the evil throttling.


That's interesting, I haven't heard of that before. Is there more info available regarding this AGESA throttling for certain programs?



> About OCCT, I know how it starts.
> There's an exported function "start" that accepts an integer as input.
> But I have no idea how it's communicating the options for the run and how is getting back the results.
> Which is a pity as using it in CoreCycler would be interesting.


I could also only find out that the string "CPUOCCTShMem" is passed to the .exe when being started, but it's the same for every option (I think). The file itself is also stored as a zip file within the main program and extracted on demand, so the main program is probably sending some messages to the generated .exe file, maybe with SendMessage() or PostMessage() (I use this to control Aida64). It also seems to access UIAutomationCore.dll, which seems to be another way to control other applications. I haven't messed with it yet though.


----------



## BarrettDotFifty

Anyone getting similar results? I've been trying to find a stable PBO+CO setup for my 5900X and it appears that the "best" core (core 2, #4/5) throws errors even at -1 offset. The "second best" seems more stable though, while all the other cores never throw an error. Also, the benchmark performance does seem to increase rather linearly down to as much as -30.

PPT: 165W
TDC: 125A
EDC: 130A

scalar: auto
freq boost: +50 MHz


----------



## ManniX-ITA

sp00n82 said:


> That's interesting, I haven't heard of that before. Is there more info available regarding this AGESA throttling for certain programs?


It happened a lot of time ago when a specific AGESA was messing with Prime95.
AMD explained they were throttling heavy workloads, targeting specifically P95 as was used for stress testing.
It's usually circumvented by the boards by some kind of "Boost" options.

MSI is doing something very peculiar and very wrong.
Throttling for Cinebench and Prime95 is disabled using LLC in Auto.
Any other manual setting and the throttling kicks back in.
It's annoying cause I have to adapt all the rest to CPU LLC Auto...
Prime Small runs at 4250 MHz instead of 4150 and Large at 4525 instead of 4400 MHz.
The Aorus Master has an option for that and doesn't mess with the LLC.

Anyway I was able to compile my own P95 and that was not the problem.
I've run OCCT Medium with 20 minutes cycle and found out the Core 11 was erroring.
Never failed with P95 or OCCT Small/Large but was unstable.
Once I fixed that, all the immediate crashes from Core 1, 7, 8, 9 immediately disappeared.

Then the results finally made sense and I started fixing the other issues.
More and more core needed fixing and found out the telemetry settings where also causing instabilitiy.



BarrettDotFifty said:


> Anyone getting similar results? I've been trying to find a stable PBO+CO setup for my 5900X and it appears that the "best" core (core 2, #4/5) throws errors even at -1 offset. The "second best" seems more stable though, while all the other cores never throw an error. Also, the benchmark performance does seem to increase rather linearly down to as much as -30.


Could be it can't go below that.

Did you try setting all the others eg at -10 or all at -5?
If you have a single core that is unstable can mess up with the others.

Also you need to test with Small and Large FFT not only Huge.
If you still don't find anything raise the cycle length; I've found unstable cores even after 41 minutes.


----------



## sp00n82

BarrettDotFifty said:


> Anyone getting similar results? I've been trying to find a stable PBO+CO setup for my 5900X and it appears that the "best" core (core 2, #4/5) throws errors even at -1 offset. The "second best" seems more stable though, while all the other cores never throw an error. Also, the benchmark performance does seem to increase rather linearly down to as much as -30.
> 
> PPT: 165W
> TDC: 125A
> EDC: 130A
> 
> scalar: auto
> freq boost: +50 MHz
> 
> View attachment 2512369


Also, you're at +50 MHz additional boost, this setting can heavily influence the amount you can go into negative values.
And try to run CoreCycler over night if you can. The errors you're seeing now are just the most obvious ones, I'm pretty sure you'll find that the other cores alwo won't all run on -30. I have only one single core left that can run at -30, the others vary from -9 to -21.

Here's an excerpt from my list. Where you can also see that some cores ran fine for a pretty long time before eventually throwing an error. This is what I mean with that you'd need 12+ hours of stress testing _per core_ to be somewhat sure of its stability.


----------



## BarrettDotFifty

sp00n82 said:


> Also, you're at +50 MHz additional boost, this setting can heavily influence the amount you can go into negative values


What PBO settings have you used for the tests other than curve optimizer?
Also, I think we'd have to eventually settle at something that we "consider" stable. Otherwise, we'd be testing forever with so many cores, programs and instruction sets. But I guess for what it's worth I'd be willing call it stable at 12 hours per core with a random choice of programs/modes uniformly distributed within those 144 hours.


----------



## Sleepycat

BarrettDotFifty said:


> Anyone getting similar results? I've been trying to find a stable PBO+CO setup for my 5900X and it appears that the "best" core (core 2, #4/5) throws errors even at -1 offset. The "second best" seems more stable though, while all the other cores never throw an error. Also, the benchmark performance does seem to increase rather linearly down to as much as -30.
> 
> PPT: 165W
> TDC: 125A
> EDC: 130A
> 
> scalar: auto
> freq boost: +50 MHz
> 
> View attachment 2512369


Interestingly, my best core requires a +10 offset to pass corecycler in AVX mode. My worst cores in CCX2 actually pass with -30. Leads me to wonder what type of tests AMD used to determine which were the best cores.


----------



## sp00n82

BarrettDotFifty said:


> What PBO settings have you used for the tests other than curve optimizer?


I've basically maxed out the PPT, EDC & TDC values and didn't give them much attention afterwards. Scalar I left on auto, and obviously the boost is 0 at this point (I eventually went up to +100, with +125 I started to quickly see errors on previously stable cores).



Sleepycat said:


> Interestingly, my best core requires a +10 offset to pass corecycler in AVX mode. My worst cores in CCX2 actually pass with -30. Leads me to wonder what type of tests AMD used to determine which were the best cores.


Probably only some quick tests. They can't do crazy amount of stress tests like we do, otherwise the shortage of CPUs would be even higher. 🤪


----------



## ManniX-ITA

sp00n82 said:


> I've basically maxed out the PPT, EDC & TDC values and didn't give them much attention afterwards. Scalar I left on auto, and obviously the boost is 0 at this point (I eventually went up to +100, with +125 I started to quickly see errors on previously stable cores).


I don't think it's a good strategy... Limits maxed out are costing me up to 5 counts.
Plus in general much worse performances and unstable boost clock.

You should try some some crafted limits; I'm using 200/220/215 on my 5950x and seems to give the better overall SC/MC scores and best stability.
Boost clock at that point can be pushed up to 100 MHz without any issue for me.

In general that's what I found with my setup:

Scalar depends; if you have a decent cooling you can raise it, gain stability and performances plus lower CO counts.
I'm at FCLK 2000 so it's a bit on the edge but I can use Scalar 2x.
At IF 1900 it was easier, could run up to 10x but it's scaling much less with AGESA 1.2.x so it's probably better to stay at 4x-6x.

What really matters is to find the right VDDG IOD & CCD, VSOC, PLL, LLC & PWM.

Use Linpack Extreme 1.1.5 to test, is the easiest way to tune these parameters.

I can say about my 5950x which is a dual CCD, single CCD usually are less needy.
IOD scales up performances and provides stability.
IF 1900 was fine at 1060-1080mV, IF 2000 needs 1120-1130mV.
If it's not enough cores will crash with CC and system will BSOD or reboot with P95 Small all-core and Linkpack.

Low CCD will error on CC, mostly scoring low.
Use Linpack score to find the right value.
Confirm it with Geekench5 AES-XTS scores, especially single core.

VSOC check with AIDA64 the performances, keep it at least 50-60mV above IOD.
FCLK 2000 needs at least 1.18-1.20V; scores with Geekbench 5 MT will fluctuate and get inconsistent if not enough.

LLC and PWM are more tricky.
Low PWM Switching for me usually means Windows can't even boot or BSOD or reboots at idle.
Below 900 kHz I see at least unstable GB5 scores.
I keep it at 900 kHz at FCLK 2000 otherwise there's a small performance drop, FCLK 1900 doesn't seem to mind if it's at 1000 kHz.
SOC PWM same as CPU.

LLC must be strong on SOC or it will crash on CC and/or reboot under load in GB5 SC & MC.
SOC runs always at the same speed/state so it doesn't mind a strong LLC unless you run Stock at IF 1600.

CPU LLC depends, the Unify-X has this nice feature where LLC Auto is the only level really usable.
If you set it low it will crash under load or booting into Windows. High at 2-3 is required for stability but it's much slower than Auto.
So everything needs to be adapted to LLC Auto.
On the Aorus Master High was required, Medium would already show instabilities from reboots, BSODs to idle reboots.

Another important setting is OVP/OCP.
Depends on the board/BIOS.
The Master was unstable with anything below 400mV and anything else than Auto.
With the Unify-X seems to be better, not much difference but all Auto seems the more stable.
Not yet sure.

There is also CPU PLL or 1P8 voltage.
Test with Linpack, setting to 1.810 instead of Auto gave a boost and more stability for me.


----------



## lmfodor

ManniX-ITA said:


> I don't think it's a good strategy... Limits maxed out are costing me up to 5 counts.
> Plus in general much worse performances and unstable boost clock.
> 
> You should try some some crafted limits; I'm using 200/220/215 on my 5950x and seems to give the better overall SC/MC scores and best stability.
> Boost clock at that point can be pushed up to 100 MHz without any issue for me.
> 
> In general that's what I found with my setup:
> 
> Scalar depends; if you have a decent cooling you can raise it, gain stability and performances plus lower CO counts.
> I'm at FCLK 2000 so it's a bit on the edge but I can use Scalar 2x.
> At IF 1900 it was easier, could run up to 10x but it's scaling much less with AGESA 1.2.x so it's probably better to stay at 4x-6x.
> 
> What really matters is to find the right VDDG IOD & CCD, VSOC, PLL, LLC & PWM.
> 
> Use Linpack Extreme 1.1.5 to test, is the easiest way to tune these parameters.
> 
> I can say about my 5950x which is a dual CCD, single CCD usually are less needy.
> IOD scales up performances and provides stability.
> IF 1900 was fine at 1060-1080mV, IF 2000 needs 1120-1130mV.
> If it's not enough cores will crash with CC and system will BSOD or reboot with P95 Small all-core and Linkpack.
> 
> Low CCD will error on CC, mostly scoring low.
> Use Linpack score to find the right value.
> Confirm it with Geekench5 AES-XTS scores, especially single core.
> 
> VSOC check with AIDA64 the performances, keep it at least 50-60mV above IOD.
> FCLK 2000 needs at least 1.18-1.20V; scores with Geekbench 5 MT will fluctuate and get inconsistent if not enough.
> 
> LLC and PWM are more tricky.
> Low PWM Switching for me usually means Windows can't even boot or BSOD or reboots at idle.
> Below 900 kHz I see at least unstable GB5 scores.
> I keep it at 900 kHz at FCLK 2000 otherwise there's a small performance drop, FCLK 1900 doesn't seem to mind if it's at 1000 kHz.
> SOC PWM same as CPU.
> 
> LLC must be strong on SOC or it will crash on CC and/or reboot under load in GB5 SC & MC.
> SOC runs always at the same speed/state so it doesn't mind a strong LLC unless you run Stock at IF 1600.
> 
> CPU LLC depends, the Unify-X has this nice feature where LLC Auto is the only level really usable.
> If you set it low it will crash under load or booting into Windows. High at 2-3 is required for stability but it's much slower than Auto.
> So everything needs to be adapted to LLC Auto.
> On the Aorus Master High was required, Medium would already show instabilities from reboots, BSODs to idle reboots.
> 
> Another important setting is OVP/OCP.
> Depends on the board/BIOS.
> The Master was unstable with anything below 400mV and anything else than Auto.
> With the Unify-X seems to be better, not much difference but all Auto seems the more stable.
> Not yet sure.
> 
> There is also CPU PLL or 1P8 voltage.
> Test with Linpack, setting to 1.810 instead of Auto gave a boost and more stability for me.


Hey @ManniX-ITA!

I've always been lost trying to figure out what the correct voltages values are. I had an infinity of BDOD, and it was testing values but as a reference, until now no test has helped me to identify a method to know if the values of VDDP, IOD, CCD and VSOC are correct. I am currently with IF 1900 with which it should be easy, but it is not, I have read that the VDDP should be between 0.9 and 0.8V and the CCD according to Veii sometimes just below 0.95 and others in 1V, then IOD 0.5 / 0.75V below the vSOC, and about the vSOC you have told me that it is convenient to raise it a bit from the "standard" of 1.1V for 1900MT (to gain stability with tight timings), in fact I am running VDOC at 1.14V.. but I can run 1.2 or 1.1, or even a VDIMM lower than 1.5V. 

Regarding LLCs, I know that on the CPU it has an impact, it can cause reboots. for the Vdroop, but I don't know how sensitive the voltage is on the memories, I mean if some kind of spike can generate a BSOD. I run the maximum that Asus allows me in Switching freq, which are 500 CPU and 600 vSOC, unlike the MSI that are at 1000Mhz. Are the values I say for 1900 correct? because no matter how much it varies a little, I haven’t always achieved immediate crashes, they always occur randomly and it is difficult for me to diagnose them. 

How does the Linpack compare to Y-Cruncher? It’s an stability tool? You know that I follow your advice a lot, so I would appreciate a lot if you guide me on these values to have a stable base in 1900 ... you already know my timings! I never managed to lower the tRCRD of 16 in a stable way, and the rest are adjusted and with the "truck" of the cadbus setup 56-0-12, tCKE 16 for 1T and low latency in two CCDs 

What is the OVP / OCP? 

About the PLL I know that it is always at 1.8v. How does an increase affect stability?

Thanks as always for your great support 


Sent from my iPhone using Tapatalk Pro


----------



## ManniX-ITA

lmfodor said:


> I have read that the VDDP should be between 0.9 and 0.8V


Keep it at 900mV, don't go below or above



lmfodor said:


> CCD according to Veii sometimes just below 0.95 and others in 1V


This is very dependent on the specific CPU sample (quality) and if it's dual or single CCD.
New AGESAs likes more CCD; even Veii is running it above 1000mV now.
Use Linpack, Benchmark 8GB, 5 runs and check the scores to find the right one.
Then validate with Geekbench 5 AES-XTS.



lmfodor said:


> then IOD 0.5 / 0.75V below the vSOC,


IOD should be at least 50mV from VSOC but I had sporadic stability issues if it was dropping below 60mV.
Higher IOD means more stability and performances, especially at IF 1900 and above.
But if it's too much starts doing the opposite. Audio crackling and stutter as well if it's too less or too much.
In general at IF 1900 you should not need more than 1060mV.
Then VSOC should be at least 1.12V with strong LLC or 1.14V with weak LLC.



lmfodor said:


> I run the maximum that Asus allows me in Switching freq, which are 500 CPU and 600 vSOC, unlike the MSI that are at 1000Mhz. Are the values I say for 1900 correct?


Yes it should be right but test also a bit lower if it helps.
I'm not 100% sure but the low PWM frequency should be linked to the phases; ASUS is not using true phases but dual.
From what I've seen doesn't change much, 500 should be same as 1000 with true phases.



lmfodor said:


> How does the Linpack look like a Y-Cruncher? is it stability? do you calculate?


As above it gives you a max and average for 5 runs benchmark.
You can also use it for stability but I fancy more y-cruncher as it's testing more stuff at the same time.



lmfodor said:


> you already know my timings! I never managed to lower the tRCRD of 16 in a stable way, and the rest are adjusted and with the "truck" of the cadbus setup 56-0-12, tCKE 16 for 1T and low latency in two CCDs


Did you try running with the XMP profile for a while to see if the BSODs & co are due to the memory timings.
Even 25 cycles TM5 can miss something wrong with timings, especially related to RTT/CAD.



lmfodor said:


> What is the OVP / OCP?


Over Current and Over Voltage Protection.
I don't think the Dark Hero is exposing these settings.



lmfodor said:


> About the PLL I know that it is always at 1.8v. How does an increase affect stability?


It can help or not.
Was helping me at FCLK 2000 on the Master set to 1.760V.
On the Unify-X it doesn't, gets worse going down and above 1.810V.
Test the score with Linpack if it's increasing good otherwise will go down.
You really need to test every single step.


----------



## lmfodor

You are a great Mannix! Thanks for your answer and help. I will try it with linpack. Actually, I left all the y-cruncher tests running and it's been 6 hours without errors. 

Sometimes I think about the processor degradation from running so many stress tests! My 5900 ran more stress test hours than playing games 

Going back to the curve optimizer, the C-states and the random reboots that continue to appear when I activate the CS, I wonder if it would not be better to use the DOS of the Dark Hero and test if the C-States work better in that way, I think that by not having undervolting at least I suppress the hibernation reboots, am I correct or would it affect that too? I want to enable the c-states but I always have random reboots, on idle or under load …

Sent from my iPhone using Tapatalk Pro


----------



## lmfodor

ManniX-ITA said:


> Keep it at 900mV, don't go below or above
> 
> 
> 
> This is very dependent on the specific CPU sample (quality) and if it's dual or single CCD.
> New AGESAs likes more CCD; even Veii is running it above 1000mV now.
> Use Linpack, Benchmark 8GB, 5 runs and check the scores to find the right one.
> Then validate with Geekbench 5 AES-XTS.
> 
> 
> 
> IOD should be at least 50mV from VSOC but I had sporadic stability issues if it was dropping below 60mV.
> Higher IOD means more stability and performances, especially at IF 1900 and above.
> But if it's too much starts doing the opposite. Audio crackling and stutter as well if it's too less or too much.
> In general at IF 1900 you should not need more than 1060mV.
> Then VSOC should be at least 1.12V with strong LLC or 1.14V with weak LLC.
> 
> 
> 
> Yes it should be right but test also a bit lower if it helps.
> I'm not 100% sure but the low PWM frequency should be linked to the phases; ASUS is not using true phases but dual.
> From what I've seen doesn't change much, 500 should be same as 1000 with true phases.
> 
> 
> 
> As above it gives you a max and average for 5 runs benchmark.
> You can also use it for stability but I fancy more y-cruncher as it's testing more stuff at the same time.
> 
> 
> 
> Did you try running with the XMP profile for a while to see if the BSODs & co are due to the memory timings.
> Even 25 cycles TM5 can miss something wrong with timings, especially related to RTT/CAD.
> 
> 
> 
> Over Current and Over Voltage Protection.
> I don't think the Dark Hero is exposing these settings.
> 
> 
> 
> It can help or not.
> Was helping me at FCLK 2000 on the Master set to 1.760V.
> On the Unify-X it doesn't, gets worse going down and above 1.810V.
> Test the score with Linpack if it's increasing good otherwise will go down.
> You really need to test every single step.


Hi @ManniX-ITA , look at this, finally I guess I have an stable config. I didn't so much, just upgrade the BIOS to Agesa 1.2.0.3 and increase 1 point in the Curve Optimizer (increasing one point for each core, so that the curve is not as tight)

I guess I could take your suggestion of rise CCD to 1V, lower vSOC to 1.12V with LLC3, keeping Sw Freq 500Mhz, and IOD 1.075V right?

I actually have a 235/175/300 of PBO Limits. So I wonder if your values would be perform better than mine ( 200/220/215) and my core boos override a Lowered to +75, for that reason my single core score is lower now

Regarding setting *1.933 FCLK*, could I keep my same timings right? It's a little change from 1900 to 1933 so I don't think I need to change the timings, am I good with that? Else, what are you findings about voltages to reduce WHEAs? I noticed much less errors in that last BIOS, and the ACPI error makes me think about to disable some device, ie, NIC, which I also disabled from BIOS but not in Windows. What do you think? What should I try as a little step up keeping the stability?









 Thanks!


----------



## ManniX-ITA

lmfodor said:


> I guess I could take your suggestion of rise CCD to 1V, lower vSOC to 1.12V with LLC3, keeping Sw Freq 500Mhz, and IOD 1.075V right?


Test it carefully.
Run an extensive number of benchmarks and compare it, if it works then stress test as much as possible with y-cruncher and CoreCycler.



lmfodor said:


> I actually have a 235/175/300 of PBO Limits. So I wonder if your values would be perform better than mine ( 200/220/215) and my core boos override a Lowered to +75, for that reason my single core score is lower now


Pretty heavy for a 5900x.
As above, make a lot of benchmarks and compare.
They work well for my 5950x on the Unify-X but consider they didn't work as well on another 5950x on a X570 Unify.
You really need to find your sweet spot; limits from another system with Vermeer must be considered only an hint.
Those limits are meant to keep high EDC but without TDC constraint and with PPT constraint.
I was using before 280/165/215 but these seems to work a tad better with MC.



lmfodor said:


> Regarding setting 1.933 FCLK, could I keep my same timings right? It's a little change from 1900 to 1933 so I don't think I need to change the timings, am I good with that?


Usually yes but 25 cycles with TM5 are mandatory anyway.



lmfodor said:


> Else, what are you findings about voltages to reduce WHEAs? I noticed much less errors in that last BIOS, and the ACPI error makes me think about to disable some device, ie, NIC, which I also disabled from BIOS but not in Windows. What do you think? What should I try as a little step up keeping the stability?


Not much yet, in some cases this latest AGESA helps a bit but not much, in others doesn't help at all.
Disabling the NIC in bios or Windows is probably not going to help.
It's initialized in any case at boot, if that's the problem this workaround doesn't help.

As a little step up try to lower by one count the Core 0 as it's pretty slow.
Maybe better limits can help, 10.4ns in L3 latency means it doesn't keep sustained boost at 4.9 GHz.
Try to go down as much as possible.



lmfodor said:


> the ACPI error makes me think about to disable some device


The ACPI error is probably more a bug in the beta bios.
I wouldn't worry unless is creating specific problems.


----------



## ManniX-ITA

Yes I knew it could cause instabilities but I'm greedy and enabled it anyway...
I'm a sinner and fell into temptation 
Paid the price of my mistake.










If I set the Prefetcher Enable instead of Auto the cores are randomly crashing.

After all these days of testing I can say that a 6 minutes cycle, except for a first gross run to see what happens, it's a total waste of time.
Running a single 20m cycle catches more errors than a 6m cycle x 8 iterations = 48 minutes


----------



## lmfodor

ManniX-ITA said:


> As a little step up try to lower by one count the Core 0 as it's pretty slow.
> Maybe better limits can help, 10.4ns in L3 latency means it doesn't keep sustained boost at 4.9 GHz.
> Try to go down as much as possible.


Hi Mannix, I didn’t understand that part. Do you mean that if I have set the core 0 in -28 should I lower (increase volts) one count? Why is pretty slow. In my case core 0 it have a strange behavior, because it support a great undervault (-28) instead of my best core (4) that can go above -24, and both have a great overboost of 5000mhz. I’m still don’t get how windows managed the cores when I run a single core test. It switch between my 1at best (4), my 2nd best (5) and the core 0! That’s weird 

So recapping, when you said try to go down as much as possible is only for the core 0 and how lower should I go? Just to test.. 

About the 10.04ns in L3, yew, since 1.2.0.2 the L3 and its boots seems to be broken. I usually got 10.02.. but is changing always when clicking on AIDA a new stress test. Go from 50,5x to 50 to 49.5. 

Thanks!




Sent from my iPhone using Tapatalk Pro


----------



## ManniX-ITA

lmfodor said:


> So recapping, when you said try to go down as much as possible is only for the core 0 and how lower should I go? Just to test..


Yes only for Core 0.
-28 is already a lot.
If the the latency issue is because the AGESA you can keep it as it is.
The scheduler will distribute load across the best cores is normal.
But some programs, like AIDA, and some critical processes will always run on Core 0 no matter what.
That's why is important the runs fast and is stable.
Very long cycles on Core 0 and the best cores with CoreCycler are really an helping hand to ensure stability.


----------



## sp00n82

ManniX-ITA said:


> I don't think it's a good strategy... Limits maxed out are costing me up to 5 counts.
> Plus in general much worse performances and unstable boost clock.
> 
> You should try some some crafted limits; I'm using 200/220/215 on my 5950x and seems to give the better overall SC/MC scores and best stability.
> Boost clock at that point can be pushed up to 100 MHz without any issue for me.


Yeah, it's the lazy approach. The whole reason I started writing this script is because I was too lazy to manually switch cores all the time during testing. 




ManniX-ITA said:


> After all these days of testing I can say that a 6 minutes cycle, except for a first gross run to see what happens, it's a total waste of time.
> Running a single 20m cycle catches more errors than a 6m cycle x 8 iterations = 48 minutes


I really don't know how that is supposed to work. A single 20m run will always only catch errors on one single core, whereas the 6 minutes one will cycle through multiple cores and therefore also has a chance to catch errors on multiple ones.
On the other hand I'm not sure how you meant it anyway, as to land on 48 minutes with 8 iterations and 6 minute per core, you would need to have it set up to only test a single core for 6 minutes x 8. And if you're only testing a single core, there's virtually zero difference between one longer cycle and multiple shorter ones, as Prime95 just keeps going in the background and nothing is changed in the affinity.
*Unless* of course you've set the restartTestProgramForEachCore setting to 1 (which is 0 by default), in which case Prime95 is being restarted during the cycles/iterations, so the FFT sizes start again from the beginning. This indeed can be a huge difference for certain FFT presets, as in 6 minutes only the Smallest and Small FFT size presets should run through 100%, all the other ones should not and therefore in a 20 minutes per core run more of these FFT sizes can be tested and potentially catch errors.

Over longer test durations this will eventually even out, which is another reason why I recommend multiple test runs over night.
The alternative is always the auto setting for runtimePerCore, so you don't have to fiddle around with the minutes at all and just let CoreCycler handle this for you (i.e. switch to the next core only if all FFT sizes have been tested for the current core).


----------



## craxton

so, how long does one run a "test" for ???? considering i can run anything atm 
while nothing is failing other than 
which ill attach screenshots.. as logs im unsure where to post if its allowed to ask for advise with such 
a log thats near all day 20min cycles



















this has got me worrying, as now ive upped curve to positive on these two cores. 
lowered the testing to 5 min per cycle and its ran for well ALONG TIME NOW
but im unsure if 5 min just to check as before within 5 min would fail...
anyhow, 
is what im showing here the bug that manna speaks of? 
WHEA 18 (curve is my root cause) 
so far no crash while running 3 cores with positive curve...
to which one is near 20???


----------



## ManniX-ITA

sp00n82 said:


> Yeah, it's the lazy approach. The whole reason I started writing this script is because I was too lazy to manually switch cores all the time during testing.


Well good for us you took the time to release it for general use. It's an amazing gift.
Testing these days with OCCT made me appreciate even more of course. It's so limiting that you can't decide which cores and in which order to test.



sp00n82 said:


> I really don't know how that is supposed to work. A single 20m run will always only catch errors on one single core, whereas the 6 minutes one will cycle through multiple cores and therefore also has a chance to catch errors on multiple ones.
> On the other hand I'm not sure how you meant it anyway, as to land on 48 minutes with 8 iterations and 6 minute per core, you would need to have it set up to only test a single core for 6 minutes x 8. And if you're only testing a single core, there's virtually zero difference between one longer cycle and multiple shorter ones, as Prime95 just keeps going in the background and nothing is changed in the affinity.


Sorry maybe I wasn't clear 
I mean cycling over all or a selection of cores, not over a single one.

These days I've been running CC day and night.
Previously I was lazy, used mostly 6 minutes, and a 10-16 minutes just as a final check.
But this time I didn't trust to run only with 6 minutes since I had that error at over 40m.
So after running a couple of full and partial runs with 6m cycle, I've did the same but with 20 minutes.

It's a bit like testing memory with TM5 where you really need to run 25 cycles cause some errors will pop out only after the 19th.
A full run 6m cycle x 16 cores x 8 iterations is 768 minutes.
A single run 20m cycle x 16 cores x 1 iteration is 320 minutes.
The single iteration with a 20m cycle is much more likely to uncover instabilities.
The 6m cycles runs, even repeated up to 8 times, can miss stuff.
I had 3 cores which were failing between 10-15 minutes and always missed by the 6 minutes runs.

At the end, run a single iteration 6 minutes to get an overview and fix the counts, then run at 20 minutes since then.
Already in the first iteration at 20 minutes you can fix 99% of the errors without even having to finish a single iteration.
Every time a core is erroring, you can fix it and restart from there.
With 6m cycle the error comes up, if it does, maybe after 6-8 iterations and then you start again and another one comes up after 6-8 iterations...
I have validated with a single core run over 1 hour those 3 cores which failed after 10 minutes and they all passed.

I hope it's clear now; for me the best strategy is only 1 run 6m cycle and afterwards only 20 minutes cycle.
Should be effective in error detection and efficient in time management.



sp00n82 said:


> The alternative is always the auto setting for runtimePerCore, so you don't have to fiddle around with the minutes at all and just let CoreCycler handle this for you (i.e. switch to the next core only if all FFT sizes have been tested for the current core).


I didn't have the courage to test with Auto yet...
One day I'll run Auto with All but I don't feel like I'm ready for it


----------



## ManniX-ITA

craxton said:


> anyhow,
> is what im showing here the bug that manna speaks of?
> WHEA 18 (curve is my root cause)
> so far no crash while running 3 cores with positive curve...
> to which one is near 20???


First you need to be 100% sure the memory is working fine.
Did you run TM5 for 25 cycles?

2nd test with an all core count of -1.
If it passes there's another core unstable which is messing up with the others.


----------



## sp00n82

ManniX-ITA said:


> A full run 6m cycle x 16 cores x 8 iterations is 768 minutes.
> A single run 20m cycle x 16 cores x 1 iteration is 320 minutes.
> The single iteration with a 20m cycle is much more likely to uncover instabilities.
> The 6m cycles runs, even repeated up to 8 times, can miss stuff.
> I had 3 cores which were failing between 10-15 minutes and always missed by the 6 minutes runs.


Well, as explained, the only instance where this would make any difference at all is for FFT sizes beyond Small. CoreCycler tries to give you an educated guess where the error might have happened (I'm still waiting for the developer of Prime95 to add the actual FFT size where the error happened to the log file, so that I can refer to this instead), which might help you in narrowing down a specific FFT range that is throwing errors for you.

While made for lazy people like me, CoreCycler is not necessarily a "fire and forget" type of software, you still have to invest a lot of time, although much of this time can be spent over night while you're sleeping.

My usual process was to run CC over night and check which cores had thrown errors in the morning, then reboot and adjust these cores, keep on doing stuff with my computer, and then fire up CC again for the next night, etc. (or start sooner/reboot later, when I could bare the noise of the fans).
Of course you can stop and adjust as soon as you've found an error, but this does require even more time & attention.


----------



## Kabuboru

My 5800X is failing on its “best” core at optimised defaults (PBO is on I think (Auto)) with no curve set… should I RMA? Seems to pass at least a couple of iterations with a +1 offset on that specific core and 0 on the second best.


----------



## sp00n82

Kabuboru said:


> My 5800X is failing on its “best” core at optimised defaults (PBO is on I think (Auto)) with no curve set… should I RMA? Seems to pass at least a couple of iterations with a +1 offset on that specific core and 0 on the second best.
> 
> Also passes fine if I set PBO to disabled. Should I just suck it up and live with my +1 offset?
> 
> update:
> Interestingly I just flashed an older BIOS with an older AGESA version (1.2.0.2 instead of 1.2.0.3) and it’s passing where it failed immediately previously.


I'm not sure you're actually able to RMA if it only fails when PBO is activated. You're even officially loosing your warranty when using PBO, so it's probably not covered. This then may depend on the goodwill of AMD / your seller.


----------



## Kabuboru

sp00n82 said:


> I'm not sure you're actually able to RMA if it only fails when PBO is activated. You're even officially loosing your warranty when using PBO, so it's probably not covered. This then may depend on the goodwill of AMD / your seller.


It’s hilarious that the optimised defaults turn PBO on - Warranty void at POST in that case…

Im not particularly concerned if it’s within specs and I’ve just got a bad bin for overclocking, but if this test failing indicates an issue with the core I might try and RMA.


----------



## craxton

@ManniX-ITA 

this is my stable config on zen timings under craxton...have ran more
tm5 lol (while curve is off) but yes tm5 passes 25 cycles, y, prime smallfft
and occt again while curve isnt being used.


----------



## ManniX-ITA

sp00n82 said:


> Well, as explained, the only instance where this would make any difference at all is for FFT sizes beyond Small.


Do you mean cause the cycle takes less to complete all the Small FFTs?
That's not what I mean.
What I mean is that even with Small makes a difference; the goal is to "roast" for at least 10-20 minutes a core to get it to a sort of thermal balance.


----------



## sp00n82

ManniX-ITA said:


> Do you mean cause the cycle takes less to complete all the Small FFTs?
> That's not what I mean.
> What I mean is that even with Small makes a difference; the goal is to "roast" for at least 10-20 minutes a core to get it to a sort of thermal balance.


I guess this depends on the cooling then as well, with smallest and small FFTs the temperature with air cooling reaches very high values very quickly within these 6 minutes, I suppose for water it will take longer until the thermal equilibrium is reached.


----------



## GribblyStick

** wrong thread - delete **


----------



## Art385

ManniX-ITA said:


> When mines are failing with P95 they crash almost always at 448K FFT and at the very beginning of Large.
> Doesn't have to run via CC, is doing the same when launched manually.
> 
> It's weird they all have passed in the past this count and still pass it sometimes.
> The only way I found is to reduce the count dramatically, at least they don't crash immediately.
> 
> They are not the same kind of quality cores.
> Core 1 is the best and Core 9 one of the worst.
> They both always run around the negative count, so it would make sense.
> But Core 7 and 8 are a good quality one in CCD1 an the best of CCD2.
> I have validated them down to -28, doesn't make sense they need -10 or -5.
> 
> If OCCT is using P95 looks really unlikely that I can always pass over 1h per core and insta-fail using P95 directly.
> I'll have to test for longer with OCCT to see if I can at least replicate once a fail in these cores.
> Unfortunately OCCT is not flexible as much as CC on cycling options.


For me workaround is to use LLC 6 and +25mv positive global offset + CO on B550 Tomahawk. It seriously looks like problem with voltages that are supplied when CO is in use and how much core can boost. For me even on OCCT I could see errors on certain cycle - restart only test without switching off occt pufffff no errors for one hour. Sometimes they go back after one pc restart and sometimes I could power cycle pc couple of times. Both my cores looking at index with CTR are good ones for 5800x C#2-150 & C#1-139.
All I've could do is lower how much they boost with voltage. Core 1 should not go above 4725 MHz and Core 2 4775 MHz on SSE load. Both are willing to boost past 4.8 GHz with offset as low as -12 and they fail only with SSE with avx2 they can run 4.8+ all day. Core 1&2 on Core Cycler is validated as 8 & 6 always stable even when I set one core testing and do 20 cycles but core #1 can fail randomly @OCCT at this offset though it can sometime run -14 perfectly stable for 1h in occt - why? don't now.
So as I grow tired of testing I've used on these cores -8 offset + LLC6 +25mv global and it's finally always stable. After weeks of testing I'm quite sure it's motherboard fault. I'm now using Bios A50 as it's most stable though this weird behavior is present on newer bioses as well.
MSI bioses are bad on A60 my fans stops working and shows 0 rpm lol. When flashing A64 beta bios my Mflash just hanged at 50% I needed to switch off PC don't knowing if it finished. Now no matter the bios MFlash do this every time. At this point I'm glad that MSI can at least publish bios that will not brick the board but their bioses are hands down the worst as I've ever saw and I used early X370 Taichi bioses back in Zen 1 times 😆

Sorry for my English I don't use it very often.


----------



## ManniX-ITA

Art385 said:


> So as I grow tired of testing I've used on these cores -8 offset + LLC6 +25mv global and it's finally always stable. After weeks of testing I'm quite sure it's motherboard fault. I'm now using Bios A50 as it's most stable though this weird behavior is present on newer bioses as well.


The latest AGESAs 1.2.x are really bad compared to the previous.
But my randomness was cause by a the L1/L2 prefetcher options in the BIOS and a specific core that was not crashing frequently like the others but was unstable.
I'd try to start from a fresh profile and an all-core count going down a few steps every time.
LLC6 will make them unstable.
Best Auto or strong at LLC2 or 2 with OCP 400mV and Enhanced and maximum PWM.


----------



## ioannis91

Hello and thanks for this great tool!! I want to test the AutoOC on my 5600X, starting from +200ΜΗz. The think is that there may be clock stretching which is something that I must check for, as i've read on multiple guides. How do I do that? Will this tool help on this regard?


----------



## sp00n82

ioannis91 said:


> Hello and thanks for this great tool!! I want to test the AutoOC on my 5600X, starting from +200ΜΗz. The think is that there may be clock stretching which is something that I must check for, as i've read on multiple guides. How do I do that? Will this tool help on this regard?


No, CoreCycler doesn't do any benchmarks. Cinebench does calculate a score though which you can use to compare the baseline without any modifications to overclocked / undervolted settings.

CoreCycler then helps you in determining if the setting is stable or not.


----------



## ManniX-ITA

ioannis91 said:


> Hello and thanks for this great tool!! I want to test the AutoOC on my 5600X, starting from +200ΜΗz. The think is that there may be clock stretching which is something that I must check for, as i've read on multiple guides. How do I do that? Will this tool help on this regard?


Check the speed with CPU-z and note it as a reference for future changes/new bios releases:









[Official] AMD Ryzen DDR4 24/7 Memory Stability Thread


Tried TRCRD 18, system booted. Ran testmem5 got errors with 5 mins. Tried lowering the TRFC to 450, system wouldn’t boot. Tried both settings with 1.37v and SOC 1.1v one really shouldnt use dram calc anymore for 5000 series to gather timings but if your going to use it, then you need...




www.overclock.net





Make another run but with stress test with HWInfo open, let the score stabilize.
Compare the Core Clock (1) with the Effective Clock (2):










If they are very close then there's no clock stretching.

When HWInfo starts set Snapshot CPU Pooling to get accurate readings:


----------



## mongoled

@ManniX-ITA can you share your config please


----------



## ManniX-ITA

mongoled said:


> @ManniX-ITA can you share your config please


Sure, give me some time 

I want to test this new modded 1.2.0.3a... have to take screenshots anyway of all the configs.
Such a pain...


----------



## mongoled

ManniX-ITA said:


> Sure, give me some time
> 
> I want to test this new modded 1.2.0.3a... have to take screenshots anyway of all the configs.
> Such a pain...


😀😀


----------



## KedarWolf

ManniX-ITA said:


> Sure, give me some time
> 
> I want to test this new modded 1.2.0.3a... have to take screenshots anyway of all the configs.
> Such a pain...


Want me to PM you screens of my unlocked A31 BIOS setup?

Says the guy to the guy with likely more tech skill than me. 

Edit: Seriously though, I have all my BIOS settings dialed in and fully memorized, takes me a new minutes on a new BIOS to change them from memory. With maybe a few tweaks from changes in the new BIOS.

Says the 60-year-old guy that needs to look at his ID to remember his name, but can memorize a full BIOS setup. I might be a tad OCD about this PC stuff.

I AM proud I walked into a room today and remembered why I went in there. It was the bathroom, but still.


----------



## ManniX-ITA

KedarWolf said:


> Want me to PM you screens of my unlocked A31 BIOS setup?
> 
> Says the guy to the guy with likely more tech skill than me.


Absolutely yes, always good to have tips


----------



## KedarWolf

ManniX-ITA said:


> Absolutely yes, always good to have tips


I'm at work now, but will PM you a Imgur link with every BIOS setting I use when I get home tonight. If you see any screens missing it means they are on Auto/Default when I do.

Oh, and what are those custom offsets you use for CPU boost. I can't get to the menu right now but had like a .50mv offset and a .20mv offset I recall. I think it was in the Advanced/CPU Configuration menu.


----------



## ManniX-ITA

The CPU offset depends on the other settings; best for me now is 50mV but only after I had to reduce the CO counts and set the CPU VDD scale to 100A.
It's boosting a lot more in single core sustained, you can see it running OCCT Large Extreme on a single core; from 4800 MHz average to 4850 MHz.
Boosting much more often to 4925-5025 MHz; without offset the high boost is very rare.
But could be too much for some cores, you need to test carefully. Before the change was too much and the cores were dropping after a huge boost.
Otherwise still 30mV is a good solution. The sustained boost falls down more frequently, a bit less average about 25 MHz less, still boosting up but not as often with 50mV.
VDD Scale at 100A seems to give a little more headroom for the 50mV offset stability and made me gain something in Cinebench MT scores.
Setting it too low still gives something but doesn't fool enough PBO.
The SOC VDD scale doesn't seem to have a big impact if it's 1A or 10A; it does allow the same 2A gain across the EDC limit with light-threaded workloads (tested with CPU-z threads 12 to 18 scores)


----------



## KedarWolf

ManniX-ITA said:


> The CPU offset depends on the other settings; best for me now is 50mV but only after I had to reduce the CO counts and set the CPU VDD scale to 100A.
> It's boosting a lot more in single core sustained, you can see it running OCCT Large Extreme on a single core; from 4800 MHz average to 4850 MHz.
> Boosting much more often to 4925-5025 MHz; without offset the high boost is very rare.
> But could be too much for some cores, you need to test carefully. Before the change was too much and the cores were dropping after a huge boost.
> Otherwise still 30mV is a good solution. The sustained boost falls down more frequently, a bit less average about 25 MHz less, still boosting up but not as often with 50mV.
> VDD Scale at 100A seems to give a little more headroom for the 50mV offset stability and made me gain something in Cinebench MT scores.
> Setting it too low still gives something but doesn't fool enough PBO.
> The SOC VDD scale doesn't seem to have a big impact if it's 1A or 10A; it does allow the same 2A gain across the EDC limit with light-threaded workloads (tested with CPU-z threads 12 to 18 scores)


Yeah, it's the VDD Scale settings etc. I'm talking about.

Can you post a screenshot just to clarify the settings? It's a bit confusing.


----------



## ManniX-ITA

Confusing? How you dare!
Thought you were fluent in ancient Aramaic 

I've tested many variations of VDD full scale; seems to enjoy more a bit below half EDC.
Therefore consider that 100A is best for EDC 215A.
Since you are using 230A maybe 105-110A could be better.




Spoiler: Telemetry


----------



## mongoled

ManniX-ITA said:


> If they are very close then there's no clock stretching.
> 
> When HWInfo starts set Snapshot CPU Pooling to get accurate readings:


Have you noticed how the values that are relayed when running Prime95 Small FFTs ??

For most benchmarks they are almost identical, but when using Prime95 there is a considerable difference, lookie


----------



## ManniX-ITA

mongoled said:


> For most benchmarks they are almost identical, but when using Prime95 there is a considerable difference, lookie


That's a massive clock stretching 
Makes sense considering is trying to run at 4.5 GHz.
My 3800x could run Small FFT at no more than 4.25 GHz, the 5950x runs at 4.15 GHz.
That it can run at 4.4 GHz is not bad at all.


----------



## mongoled

ManniX-ITA said:


> That's a massive clock stretching
> Makes sense considering is trying to run at 4.5 GHz.
> My 3800x could run Small FFT at no more than 4.25 GHz, the 5950x runs at 4.15 GHz.
> That it can run at 4.4 GHz is not bad at all.


Thats why we should always look at effective clocks



I only unhid the others just to see the difference


----------



## KedarWolf

ManniX-ITA said:


> Confusing? How you dare!
> Thought you were fluent in ancient Aramaic
> 
> I've tested many variations of VDD full scale; seems to enjoy more a bit below half EDC.
> Therefore consider that 100A is best for EDC 215A.
> Since you are using 230A maybe 105-110A could be better.
> 
> 
> 
> 
> Spoiler: Telemetry
> 
> 
> 
> 
> View attachment 2512829


With 110/50/10 I gain like 400 points in R23!!


----------



## KedarWolf

KedarWolf said:


> With 110/50/10 I gain like 400 points in R23!!
> 
> View attachment 2512933


I'd get errors now in Core Cycler but a .025 positive CPU voltage offset fixed it.


----------



## ManniX-ITA

KedarWolf said:


> I'd get errors now in Core Cycler but a .025 positive CPU voltage offset fixed it.


Got an error as well tonight 

Tested .025 and got a weak result in GB5 Camera MT test.
At .0125 much worse, more tests below the reference.
Now I've set .0375, it's fixing also the Camera test.

Noticed also that seems to work -15 on Core1 even with high CCD voltage.
Testing now... speed is the same as before with -10.
If it's working I'll check if I can go lower also on other cores.
In case more than a few cores can keep a lower count I should see an increase in MT scores.


----------



## mongoled

ManniX-ITA said:


> That's a massive clock stretching
> Makes sense considering is trying to run at 4.5 GHz.
> My 3800x could run Small FFT at no more than 4.25 GHz, the 5950x runs at 4.15 GHz.
> That it can run at 4.4 GHz is not bad at all.


Bah, all these hidden "trap doors" left by AMD to protect the CPU

😄😄

Just stumbled upon something ive never tested before.

As I have adequate cooling its helpful in keeping temps in check so that I can see what gets effected by subtle changes here and there, well looks like I just discovered another one (again needs more testing) I played around with the telemetry settings that yourself and KedarWolf were discussing, I didnt see any changes on my setup, but then I decided to raise the "Platform Thermal Throttle Limit" to 120 and guess what, my temps are the same but now Prime Small FFTs is running at 4995mhz rather than just over 4 Ghz

 

Can others test to see

















Will update the above image after an hour, just reset HWInfo64, so will see what the minimum clock frequency reaches after going through the different FFT sets.

** EDIT **
Image updated..


----------



## ManniX-ITA

mongoled said:


> Bah, all these hidden "trap doors" left by AMD to protect the CPU
> 
> 😄😄
> 
> Just stumbled upon something ive never tested before.
> 
> As I have adequate cooling its helpful in keeping temps in check so that I can see what gets effected by subtle changes here and there, well looks like I just discovered another one (again needs more testing) I played around with the telemetry settings that yourself and KedarWolf were discussing, I didnt see any changes on my setup, but then I decided to raise the "Platform Thermal Throttle Limit" to 120 and guess what, my temps are the same but now Prime Small FFTs is running at 4995mhz rather than just over 4 Ghz


Be careful, that can be dangerous 

AMD really sucks sometimes... the throttle limit if you run all-core will still be the fixed 90c.
What is lifted is the limit on the single core or localized.
But AMD despite the thousands of in-die sensors can't really measure reliably the temperature of a single core.
If you go too high it will reach and surpass easily the 110c limit and at that point degradation it'll occur for sure at rocket speed.


----------



## mongoled

ManniX-ITA said:


> Be careful, that can be dangerous
> 
> AMD really sucks sometimes... the throttle limit if you run all-core will still be the fixed 90c.
> What is lifted is the limit on the single core or localized.
> But AMD despite the thousands of in-die sensors can't really measure reliably the temperature of a single core.
> If you go too high it will reach and surpass easily the 110c limit and at that point degradation it'll occur for sure at rocket speed.


Will keep that in mind, thanks


----------



## ManniX-ITA

mongoled said:


> Will keep that in mind, thanks


I've run for a while with 110c limit and for long time at 105c.
At the end always had stability issues from it.
Mostly on light threaded cause a few cores going over 100c was too much 
But maybe on a 5600x could be feasible.

If it's dropping to 4.1 GHz without it you have the MSI Core boost bug.
Are you using LLC Auto on CPU?
Cause that's what happens with a fixed LLC.
Other boards doesn't have this issue. The Aorus Master can tell doesn't.

What did you test with the telemetry?
Did you adapt the CPU VDD scale to a bit higher than half of EDC?
Not sure if on a 5600x should be toward the real max EDC or the EDC limit.
You should check maybe how high you can go running TM5.


----------



## ioannis91

Is this considered clock stretching? Handbrake workload. In blender all readings are the same. [5600X, PBO Limits: 110W, 65A, 120A, curve -15 all core, no autoOC, no scalar]


----------



## mongoled

ManniX-ITA said:


> I've run for a while with 110c limit and for long time at 105c.
> At the end always had stability issues from it.
> Mostly on light threaded cause a few cores going over 100c was too much
> But maybe on a 5600x could be feasible.
> 
> If it's dropping to 4.1 GHz without it you have the MSI Core boost bug.
> Are you using LLC Auto on CPU?
> Cause that's what happens with a fixed LLC.
> Other boards doesn't have this issue. The Aorus Master can tell doesn't.
> 
> What did you test with the telemetry?
> Did you adapt the CPU VDD scale to a bit higher than half of EDC?
> Not sure if on a 5600x should be toward the real max EDC or the EDC limit.
> You should check maybe how high you can go running TM5.


So HWInfo64 is catching the single cores temps, good to know, will keep an eye on it while I am testing "out of limits" thresholds



Nah, dont have such problem with CPU frequency dropping.

I am currently using CPU LLC @6 @5

I wouldnt really call it a "test", seeing as I am using a 105W CPU PPT/TDC settings I simply used KedarWolf settings that he posted recently, didnt see a change then focused on the thermal throttling setting, running full Y-Cruncher suite its almost at 3 hour mark.

Thats useful info how to adapt the telemetry for 5600x, will give it a go later on.

Regards EDC limit, I just set mine to 500, HWInfo64 shows EDC peaking just below 130A.

Before changing the settings TM5 would hold its peak at almost 4900 mhz, will test that as soon as ive finished with Y-Cruncher.

Lastly, also changed CPU switching frequency from 800 to 1000 I am hoping this will help stop the random WHEA 18s without me having to tweak LLC or CO values as I have all cores running at almost identical frequencies ...


----------



## mongoled

ioannis91 said:


> Is this considered clock stretching? Handbrake workload. In blender all readings are the same. [5600X, PBO Limits: 110W, 65A, 120A, curve -15 all core, no autoOC, no scalar]
> View attachment 2513005


Would not be concerned with the slight difference, if you see a difference of over 50 mhz then would be the time to pay attention.

Though I only just found out about the difference being relayed between the two different CPU frequency reading as I have only been using effective frequency for monitoring for quite a while now .....


----------



## ManniX-ITA

mongoled said:


> Regards EDC limit, I just set mine to 500, HWInfo64 shows EDC peaking just below 130A.


You should try with something like 70A for CPU VDD scale then.



ioannis91 said:


> Is this considered clock stretching?


Yes but it's minimal... I wouldn't worry considering is handbrake, though load


----------



## ioannis91

ManniX-ITA said:


> Yes but it's minimal... I wouldn't worry considering is handbrake, though load


I noticed that it happens even with curve optimizer disabled so I guess it's just the nature of the handbrake workload. On every other workload the frequencies match..


----------



## ManniX-ITA

ioannis91 said:


> I noticed that it happens even with curve optimizer disabled so I guess it's just the nature of the handbrake workload. On every other workload the frequencies match..


My guess is throttling; you may be able to verify it lowering the fans of the CPU cooler/AIO and check if the delta is getting bigger.


----------



## dansi

ioannis91 said:


> Is this considered clock stretching? Handbrake workload. In blender all readings are the same. [5600X, PBO Limits: 110W, 65A, 120A, curve -15 all core, no autoOC, no scalar]
> View attachment 2513005


i thought this is normal for hwinfo
the effective clocks are usually lower than the core clock or core ratio.

clockstretching is when you get high readings in core clocks but the app results are lower than expected.
for example, clocks read 4.5ghz all 16 cores but cinebench r23 only returns a 29k scores, when real 4.5ghz gives you around 31k iirc


----------



## ioannis91

ManniX-ITA said:


> My guess is throttling; you may be able to verify it lowering the fans of the CPU cooler/AIO and check if the delta is getting bigger.


In handbrake I get about 78 degrees but in blender about 80 and there the delta is 0..


----------



## ManniX-ITA

ioannis91 said:


> In handbrake I get about 78 degrees but in blender about 80 and there the delta is 0..


Blender is an easier workload than handbrake
But 78c is too early for thermal throttling
Probably something else; are you using a vCore offset?


----------



## ioannis91

ManniX-ITA said:


> Blender is an easier workload than handbrake
> But 78c is too early for thermal throttling
> Probably something else; are you using a vCore offset?


Νο. auto core ratio, auto core voltage, no autoOC, no scalar. This behavior in handbrake happens with curve optimizer disabled too. I will try with PBO off to see if it makes a difference..


----------



## ManniX-ITA

ioannis91 said:


> Νο. auto core ratio, auto core voltage, no autoOC, no scalar. This behavior in handbrake happens with curve optimizer disabled too. I will try with PBO off to see if it makes a difference..


I'll try as well on mine to see if I can reproduce it but I don't remember it.


----------



## ManniX-ITA

ioannis91 said:


> Νο. auto core ratio, auto core voltage, no autoOC, no scalar. This behavior in handbrake happens with curve optimizer disabled too. I will try with PBO off to see if it makes a difference..


Indeed depends on the codec you select.
Some are better at threading, others less.
In all cases on the 5950x no one can fully utilize all the cores.
Check the Core x Tx Usage counters in HWInfo and you'll probably see current usage about 95/98%


----------



## ioannis91

ManniX-ITA said:


> Check the Core x Tx Usage counters in HWInfo and you'll probably see current usage about 95/98%


Exactly!


----------



## Tech12

I have similar errors with standard settings in BIOS. What does this mean?


----------



## sp00n82

Tech12 said:


> I have similar errors with standard settings in BIOS. What does this mean?
> View attachment 2513478


Check first if the default settings in your BIOS enable PBO or not. Errors should not appear on stock settings, but "stock" here means no PBO, since it is not covered by the warranty.
Also make sure there is no (potentially unstable) memory overclock currently applied.

If the errors occur even with PBO disabled, I'd consider to RMA it, because it should work fine with these settings under any circumstances.
But if they only happen with PBO enabled, then you would simply need to feed this core more voltage (silicone lottery).


----------



## PJVol

dansi said:


> when you get high readings in core clocks but the app results are lower than expected.


Actually, that may well mean some other processes (i.e. background, or services) take away CPU resources, so above is correct if suspicious results are reproducable.


----------



## Cl0ak

Hi, apologies in advance for any mistakes, I'm not a native english speaker. Corecycler is reporting instability at Core 1, both at stock settings ( clear cmos and bios stock setting loaded, ddr4 @ 2133 mhz ) and with stable (overnight Karhu ram test and tm5 iusmus v3) overclocked ddr4 ( 3600mhz 14-14-14-34 1.35 v).
Tried LLC 2 instead of AUTO and manually disabling PBO, but it just delays the instability, lower LLC settings make other core unstable too.

Core 1 seems to be stable only if I activate PBO2 and set a positive offset of +8 to the CORE 1 of the 5600x, set limit to MOTHERBOARD, scalar x1, ZERO mhz offset, which seems me too high to just stabilize the cpu at stock.
Before I proceed with a CPU RMA, is there something more that I could try?

Ps: Could it be a power delivery issue? My PSU is a Corsair CX 430, which was mediocre in 2016, and is probably worse now after 6 years of heavy usage.

My specs:

Asrock B550m Pro4 motherboard, Ryzen 5600x.
Bios version is the latest 1.90
System version is Windows 10 Pro 64 bit build 19042.985 (Fresh Install)
AMD chipset drivers are the latest
16 GB ddr4 GSKILL (8x 2 GB)

Thanks


----------



## sp00n82

@Cl0ak
A core should not fail with disabled PBO and stock settings, that should be covered by the warranty.
Make sure you're not using an outdated version of CoreCycler though, older releases included a Prime95 version that could produce false errors, which should not happen anymore in Prime95 v30.6, which is included since a couple of releases in CoreCycler.

Regarding your power supply, while it's not great, I don't think it could cause only a single core to fail. There might be a chance that it causes too much ripple which the VRMs on the motherboard cannot successfully filter out, but I believe this should have an effect on all the other cores as well.


----------



## Cl0ak

sp00n82 said:


> Make sure you're not using an outdated version of CoreCycler though, older releases included a Prime95 version that could produce false errors, which should not happen anymore in Prime95 v30.6, which is included since a couple of releases in CoreCycler.


Hi, thanks a lot for the answer. I'm using Corecycler v0.8.2.4, should be the latest. It's probably better if I start the RMA process then.

Regarding LLC, is it normal that at, stock settings, various LLC settings destabilize also other cores? Auto LLC is pretty much istant Core 1 Fail, LLC2 is Core 1 fail after 12 hours, Overnight (8 hours) LLC 3 made core 1 and 3 fail, LLC 4 made core 1 and 4 fail.


----------



## sp00n82

Hm, so other cores are affected then as well. 🧐
The LLC levels determine the amount of vdroop during load and also the amount of over- and undershoot during load changes, so it's reasonable that cores with different qualities react differently to the various levels. E.g. cores that generally require more vcore for a stable operation should error out sooner with a more massive undershoot. And the ripple from the power supply or insufficient VRMs may even increase this over-/undershoot (the ripple is the actual deviation from the requested voltage, which is just the average of these values, so the actual voltage can be higher or lower at very short time intervals).

So a better power supply and better VRMs will be helpful with overclocking, because the provided voltage is much smoother and more stable with less deviations up or down. For some boards you can also adjust the switching frequency in the BIOS, which also helps with evening out the voltage, but it causes more stress and heat on the VRMs, so depending on your board you might run into cooling issues (or not).
My old AsRock x370 Gaming board didn't cope very well with overclocking my 1800x (very high VRM temperatures), whereas my MSI Tomahawk x570 just shrugs off the 5900x even with the switching frequency set to 800-1000kHz.

So, there might actually be a possibility that your combination of CPU + board + PSU is causing your CPU to fail in certain conditions, but I'd still try to RMA it. And at the same time look out for a new quality PSU.


//Edit
I just looked up the Corsair CX 430, and it's 80+ Bronze specified, so it should be "good enough". Not great and with 430 watts certainly on the lower end nowadays, but not one of these really bad ones.
Depending on the used graphics card and other peripherals you may run it on its edge capacity though, which may also lead to more unstable power supply.


----------



## Cl0ak

*@sp00n82*

Thanks again for the in depht answer! I ordered a Seasonic Focus GX 650, it has been on my radar for a long time. It's tier A on [psucultist] tier list with great reviews, so it should eliminate the bad power delivery possibility.

I'll post a reply as soon it's installed and tested!


----------



## Elric2a

Hi,

I'm trying core cycler to test curve stability on my 5909x
I guess auto settings with 6 minutes test per core isn't enough but how long should i set the test for each cores? 

I'm trying 
Ccx 47/46 @1.3
Dark hero switch 45amp

Also should i leave llc auto? 

Thanks


----------



## braveblades

Hi,
After discovered this amazing program i try to figured out optimal curve for my 5900X + ASUS Dark Hero. Additionally i've Dram - GSKILL 3600CL16 overclocked to 3800CL IF1900 - tested and fully stabilized. LLC is set on 3. 

*@sp00n82* - i have question to you about two strange behaviour using your app. Everything is set to default - 6m/HUGE/alternate

1. On the *second preffered *core (not the star) i have permanently error - even if i set "0" offset. Is something wrong with my 5900 or maybe i can't configure something properly. the rest of cores work on various offsets - from -10 to -30

2. Randomly my computer reboots without logging any errors

Thank you!


----------



## sp00n82

@Elric2a

I'll just quote myself here:



sp00n82 said:


> I've said it before, I've had cores error out after 10, 14 nights of stress testing.
> And also repeating myself, if in the "good old days" you considered a 12 hour Prime95 stress test as stable enough for your all core overclock, you'd now need to test every single core for these 12 hours to be able to have the same amount of confidence in the stability of your overclock, as you simply cannot test more than one core simultaneously for a PBO overclock.
> 
> 12 hours per core in one session is pretty impractical of course, so you can split these 12 hours per core into shorter sessions over multiple nights.
> And you should absolutely test other settings as well, e.g. AVX and AVX2 and other FFT sizes. Do not rely on only the default settings and consider your overclock to be stable just by these!
> While they are good to catch obvious errors rather quickly, in no way they guarantee a stable overclock just yet. You need to test so much more for this. The "auto" mode for the runtimePerCore setting comes in pretty handy here, as it will guarantee that all of the FFT sizes will be tested for each core before continuing to the next one.
> 
> Also, y-Cruncher may be a viable alternative, although it either had rebooted my system or ran through fine during my testing. Prime95 showed more errors for me quicker, but your mileage may vary of course.





@braveblades

Reboots while testing point towards a really unstable setting, i.e. Prime95 didn't even have the chance to throw an error, the voltage was just too low so that the computer simply rebooted (possibly during the load change simulation, where there may be a possible voltage undershoot).
You could check in the logs which core was currently being tested. In the later stages of stability testing only "normal" (rounding, etc) should occur. As long as there are reboots, you probably still have to adjust multiple steps towards positive.








And regarding errors with PBO enabled and the CO setting at 0 or greater: AFAIK there is no guarantee that any core will run PBO at all (since you're officially losing your warranty by using PBO), so it may very well be the case that you'll need to go into positive values.
Also note that an unstable memory overclock will absolutely affect the stability test, especially on "large" and greater FFT sizes. So you need to be 100% sure of the stability of your memory overclock if you want to test it in combination with a CPU overlock (which PBO is). And additionally there may also be negative effects on core stability with a memory overclock, since the IMC is stressed more with a faster RAM clock, so you might reach lower limits for both the CPU and RAM if they're both overclocked at the same time versus when you do stability tests with only one of these components being overclocked. I'd always advise to test them separately first though, otherwise you'll never know if the error actually came from the CPU or the RAM.

So going back to your single core error, as long as it doesn't throw an error while running stock settings and PBO disabled it's probably working as expected. Just bad luck with the silicone lottery for this core.


----------



## Elric2a

sp00n82 said:


> @Elric2a
> Not sure i'll be able to find that much time to do so unfortunately
> 
> Btw, right now i'm using all cores 4.6 @ 1.225, running smootlhy for weeks.
> 
> Am I loosing a LOT of performances by locking the cpu at this frequency and not using PBO?


----------



## braveblades

sp00n82 said:


> @Elric2a
> 
> I'll just quote myself here:
> 
> 
> 
> 
> 
> 
> @braveblades
> 
> Reboots while testing point towards a really unstable setting, i.e. Prime95 didn't even have the chance to throw an error, the voltage was just too low so that the computer simply rebooted (possibly during the load change simulation, where there may be a possible voltage undershoot).
> You could check in the logs which core was currently being tested. In the later stages of stability testing only "normal" (rounding, etc) should occur. As long as there are reboots, you probably still have to adjust multiple steps towards positive.
> View attachment 2513990
> 
> 
> And regarding errors with PBO enabled and the CO setting at 0 or greater: AFAIK there is no guarantee that any core will run PBO at all (since you're officially losing your warranty by using PBO), so it may very well be the case that you'll need to go into positive values.
> Also note that an unstable memory overclock will absolutely affect the stability test, especially on "large" and greater FFT sizes. So you need to be 100% sure of the stability of your memory overclock if you want to test it in combination with a CPU overlock (which PBO is). And additionally there may also be negative effects on core stability with a memory overclock, since the IMC is stressed more with a faster RAM clock, so you might reach lower limits for both the CPU and RAM if they're both overclocked at the same time versus when you do stability tests with only one of these components being overclocked. I'd always advise to test them separately first though, otherwise you'll never know if the error actually came from the CPU or the RAM.
> 
> So going back to your single core error, as long as it doesn't throw an error while running stock settings and PBO disabled it's probably working as expected. Just bad luck with the silicone lottery for this core.


Thank you so much for fast respond. I tested this core with PBO disabled and no error, so im afraid that you have right - probably im no luck with silicon lottery.  when i put +2 on this core there are no errors and when i reset OC of DRAM, have the same error on any offset below +2.. i will try testing rest of cores. thank you for your effort and this great app! 

What would you advice for testing these resets? CPU voltage or DRAM? 

Thank you!


----------



## sp00n82

Elric2a said:


> Not sure i'll be able to find that much time to do so unfortunately
> 
> Btw, right now i'm using all cores 4.6 @ 1.225, running smootlhy for weeks.
> 
> Am I loosing a LOT of performances by locking the cpu at this frequency and not using PBO?


Not a _whole_ lot, but for single core / low load scenarios you're giving up around 300MHz for the boost. [email protected] is already pretty good though, so your multi core performance would probably be worse if you switched to PBO.
But with the Dark Hero I think you can set up some sort of dual setup in the BIOS? Something I wish I could do out of the box, an all core OC with a fixed MHz & vcore and then increased single core performance with PBO (yeah, CTR seems to do something similar with its profiles, but I haven't looked at it for a while).




braveblades said:


> What would you advice for testing these resets? CPU voltage or DRAM?


I don't think I understand what you were trying to say here.


----------



## braveblades

sp00n82 said:


> Not a _whole_ lot, but for single core / low load scenarios you're giving up around 300MHz for the boost. [email protected] is already pretty good though, so your multi core performance would probably be worse if you switched to PBO.
> But with the Dark Hero I think you can set up some sort of dual setup in the BIOS? Something I wish I could do out of the box, an all core OC with a fixed MHz & vcore and then increased single core performance with PBO (yeah, CTR seems to do something similar with its profiles, but I haven't looked at it for a while).
> 
> 
> 
> I don't think I understand what you were trying to say here.


i'm sorry. i mean - what should I check - in terms of voltage, to eliminate these reboots. Maybe it's too low voltage on the DRAM? Since all the CPU voltage components are default - (I haven't changed anything).


----------



## Elric2a

sp00n82 said:


> Not a _whole_ lot, but for single core / low load scenarios you're giving up around 300MHz for the boost. [email protected] is already pretty good though, so your multi core performance would probably be worse if you switched to PBO.
> But with the Dark Hero I think you can set up some sort of dual setup in the BIOS? Something I wish I could do out of the box, an all core OC with a fixed MHz & vcore and then increased single core performance with PBO (yeah, CTR seems to do something similar with its profiles, but I haven't looked at it for a while).


The dark hero switch yes but haven't really managed to make it work as i want.

However i've tried some stuff :

Curve + switch gave me better scores (not by much) but higher temps
CTR gave me same-ish score as my manual oc (cinebench and in gam benchmark)
i've pushed a bit at 1.23 for 4.65 and since stable for now, using LLC3, should I call it a day and be happy with it? Lots of people seems that it's heresy to use a manual locked voltage on a Ryzen


----------



## sp00n82

braveblades said:


> i'm sorry. i mean - what should I check - in terms of voltage, to eliminate these reboots. Maybe it's too low voltage on the DRAM? Since all the CPU voltage components are default - (I haven't changed anything).


The reboots should be vcore resp. PBO+Curve Optimizer related. RAM tends to rather cause a blue screen if there's something wrong.
I understood that there was no difference with PBO enabled and RAM overclock yes/no, the core always throws an error if it's below +2? So to me it seems it simply needs this voltage to operate at the boost frequencies.




Elric2a said:


> The dark hero switch yes but haven't really managed to make it work as i want.
> 
> However i've tried some stuff :
> 
> Curve + switch gave me better scores (not by much) but higher temps
> CTR gave me same-ish score as my manual oc (cinebench and in gam benchmark)
> i've pushed a bit at 1.23 for 4.65 and since stable for now, using LLC3, should I call it a day and be happy with it? Lots of people seems that it's heresy to use a manual locked voltage on a Ryzen


I mean, it's really up to you. For some people it's some sort of game to push their components to the max and they enjoy the process, others are happy with a halfway decent setting.
And then it's also a matter of time, with an all core overclock you can run Prime95 for one night/day and be basically done with stability testing, with PBO+CO you have to invest this night (or day) multiplied by the amount of cores, so it's hugely more time consuming.

Also regarding the fixed voltage, personally I see no problem with that. With all the internal power saving features the cores are still pretty power efficient (if you also disabled the C-states a bit less so), while at the same time "wasting" a bit of single core / low load performance. I myself have switched to an all core resp. per CCD overclock after finding out my personal Curve Optimizer setting.
Yes, single core performance in CineBench has suffered. But my CPU runs now much cooler than with PBO (except during stress testing with Prime95, there it can still reach 90+°C especially with Small FFT) and multicore score has slightly increased (I'm "only" at 4425/[email protected] right now, nothing compared to the 4.6 you're running).


----------



## Cl0ak

@*sp00n82*

Hi, I installed the new Seasonic GX 650, cleared cmos and loaded bios defaults. Unfortunately Core1 still instantly errors, it's probably time to rma 
Thanks again for the help!


----------



## braveblades

sp00n82 said:


> The reboots should be vcore resp. PBO+Curve Optimizer related. RAM tends to rather cause a blue screen if there's something wrong.
> I understood that there was no difference with PBO enabled and RAM overclock yes/no, the core always throws an error if it's below +2? So to me it seems it simply needs this voltage to operate at the boost frequencies.


Yeah. Core 2 throw error only with PBO enabled & with and without OC DRAM, so after i push +2 on this core - everything seems good. passed over 4-5 test on huge x 6 min (for now). When i disabled PBO and enabled OC DRAM, then Core 2 is stable and throw no-error. so its seems like my curve must be so strange, because the rest of Cores are on "-30" offset with +0Hmz boost. 

I try to set up +50Mhz boost and than must lower offset for my best cores to "-25", because random reset. I will push these core little higher but it need more time.  

For the voltage of Core 2 - do i have manually set the voltage for CPU - like in OC DRAM (VSOC, etc)?


----------



## sp00n82

braveblades said:


> For the voltage of Core 2 - do i have manually set the voltage for CPU - like in OC DRAM (VSOC, etc)?


No, the Curve Optimizer does affect the voltage that is provided to each separate core during the PBO boost. AMD gave no exact value, but mentioned that it's around 3-6mV per one point of setting (so a setting of -30 should represent an offset of around -0.090v to -0.180v for a core).
Theoretically you could also set a general vcore offset in the BIOS and then adjust your Curve Optimizer accordingly (i.e. for a positive general vcore offset adjust the Curve Optimizer settings more into the negative), but if you're already on the -30 limit for some cores this might not be an option (and also in some BIOS version _MSI cough cough_ setting a positive or negative offset disables PBO altogether).


----------



## Elric2a

[QUOTE="sp00n82]



I mean, it's really up to you. For some people it's some sort of game to push their components to the max and they enjoy the process, others are happy with a halfway decent setting.
And then it's also a matter of time, with an all core overclock you can run Prime95 for one night/day and be basically done with stability testing, with PBO+CO you have to invest this night (or day) multiplied by the amount of cores, so it's hugely more time consuming.

Also regarding the fixed voltage, personally I see no problem with that. With all the internal power saving features the cores are still pretty power efficient (if you also disabled the C-states a bit less so), while at the same time "wasting" a bit of single core / low load performance. I myself have switched to an all core resp. per CCD overclock after finding out my personal Curve Optimizer setting.
Yes, single core performance in CineBench has suffered. But my CPU runs now much cooler than with PBO (except during stress testing with Prime95, there it can still reach 90+°C especially with Small FFT) and multicore score has slightly increased (I'm "only" at 4425/[email protected] right now, nothing compared to the 4.6 you're running).
[/QUOTE]

Oh ok i've upped to 4.5 @ 1.23, all stable for now. 
Temps in game are around 50c with a EK AIo 360 with unifan 
I guess that at 3840x1600 my 3090 does all the work

if fixed voltage isn't an issue i guess i'll call it a day, for the "non" gaming work it's great at 46,5 and for gaming it doesn't seem to matter that much..


----------



## sp00n82

@Elric2a 
I'd take another look at the dual dynamic OC feature of the Crosshair Dark Hero, maybe it's worth a bit more effort (as far as I understand it's the CTR profiles feature via hardware).


----------



## Elric2a

sp00n82 said:


> @Elric2a
> I'd take another look at the dual dynamic OC feature of the Crosshair Dark Hero, maybe it's worth a bit more effort (as far as I understand it's the CTR profiles feature via hardware).


I've done a profile with it and a curve but it's hard to find time to test it properly

I made
Per ccx 47 /46.5
1,3v
Switch at 45amp
Curve all cores - 30, maybe this is too optimistic lol
I only ran some cinebench, game benchmark scores were higher but not by much


----------



## craxton

quick question, (probably a duh answer) but none the less.
while running core cycler, its "max" boosted state per core if its not hitting 4850 (what ive allowed it to boost to in bios)
then my CO or mv offset isnt quite right? 

(using benchmate with CPUz setting affinity to per thread boosts to 4850, under corecycler load however, its boosting 
to 4800. (so would this indicate that the CO offset is either "to low" or "to high" ?


----------



## wuttman

craxton said:


> quick question, (probably a duh answer) but none the less.
> while running core cycler, its "max" boosted state per core if its not hitting 4850 (what ive allowed it to boost to in bios)
> then my CO or mv offset isnt quite right?


Are you sure it's not thermal/power throttling? Clocks were all over the place for me.


----------



## craxton

wuttman said:


> Are you sure it's not thermal/power throttling? Clocks were all over the place for me.


100% sure its not, never have i hit thermal limit on this chip.
70c max is what i seen in HWiNFO.
lifting EDC value from 1 to well an absurd amount allowed boosting up-to the limit i mentioned.
even tho core-cycler didnt boost to 4850 it didnt fail, just the core i have positive CO applied that is.

pics for reference. turns out killing razer software allowed a little higher boosting.
which i assume killing the other startup tasks i have would allow further. none the less...
(note that this is NOT with 1EDC in bios.

@wuttman (for context i was running 1A EDC triggering a BUG, which allowed my R20 and R23 scores to be higher than they
ever where or had been, i didnt realize what thread i was posting in and figured you knew. but im unsure that you seen me mentioning it before hand.
thus i mentioned the reason i stated lifting EDC in my previous reply. (260, 420, 1 is what i had with 5X scaler, 200auto, which my r20 scores hit 4680s all core
boosting to 4675 (only on main cores, not threads.) while limiting the EDC to 1 all cores hit 4675 but threads were limited HARD. 
to which i dont recall what they hit, but i removed the hard limit of 1 and have given context to why i mentioned the values i previously posted.


----------



## sp00n82

Running Prime95 won't necessarily give you the highest boost clocks. Even after disabling AVX & AVX2 it's still pretty intense on the CPU cores and thus will not allow them to clock to their absolute max. The lighter the load on a core while still having 100% usage, the higher the boost clock will be. With Aida64 in Cache mode you might see higher clocks, and also there are other programs like BoostTester where you will see those.
Unfortunately none of these other ones seem to include an error checking algorithm, so they're not very useful for stability testing.

Aida64 is already supported, but you'll manually have to download it (see the readme), as is y-Cruncher (which might or might not reach higher clocks than Prime95, they seemed about the same for me), but I haven't found any other program so far that could be usable. If you find one with higher boost clocks *and* error checking, let me know, I might be able to integrate it.


----------



## wuttman

craxton said:


> 70c max is what i seen in HWiNFO.


It's high enough to tone the boost down a little. Guess I should've called it FIT throttling. Provide few degrees less on cores and you should see the boost maxed, or adjust scalar to push voltage-power-temperature curve to less healthy region, unless this EDC bug already doing so. Sorry for late reply.


----------



## dansi

anybody running y-Cruncher is able to get 5ghz on effective clocks? 

Mine seems to stuck at 4.94ghz no matter the changes i dont with CO, Scalar, AutoOC and even offset.


----------



## craxton

wuttman said:


> It's high enough to tone the boost down a little. Guess I should've called it FIT throttling. Provide few degrees less on cores and you should see the boost maxed, or adjust scalar to push voltage-power-temperature curve to less healthy region, unless this EDC bug already doing so. Sorry for late reply.


the EDC bug works/doesnt work. as ive already shown in the zen ram overclocking thread,
it makes for GREAT core clocks for benchmarks, but the threads that go along with those cores
dont boost nowhere near the same frequency.

and ive already got the issue figured out, which isnt an issue at all actually. just my fused "best" core
needing +8 minimum CO offset while ALL OTHERS needs -10 to -20 (per core) dont know exact value off hand.
but none the less, all cores boost to 4850 core cycler however hits 4830 ish on core 3 (core 4 in bios)
again best fused core, but WORST core period for needing more voltage than the others.

anything -0 or -1 on core 3 (4 actual) in bios fails the test, using zenstates, to turn off df-states while allowing c6 state to be on (c6 package off)
allowed me to pass core cycler for 12 hour runs. turning this DF-STATES back on in bios (its bugged badly atm)
fails instantly on core 3. dont believe me, download zenstates and turn off df-states in bios, then check C6 package with zen states. lol

anyhow thanks for the reply, no need to adjust anything.
do note im running chrome, and a few other things to show this.
again CC passed a 12 hour run all FFT sizes. (ignore the subtitles which are Vwars on netflix.)











here is a better shot of how much per "vid" core 3 takes which takes nowhere near what cores take.
just goes to show sometimes your "best" capable core, is the "worst" overclocking core. (core 3/5 best cores, granted cores start with 0)
snapshot pooling is turned on.


----------



## Audioboxer

Sorry for asking the noob question, but I'm doing my per-core undervolting on my new 5950x and with this message is it core 5 I should lessen the undervolt or core 10? I know it says core 5 above, but just checking.

Keep getting confused with the way the bios starts at 0 and goes to 15 and Ryzen master starts at 1 and goes to 16 lol. Looks like CoreCycler starts at 0 and goes to 15 like the bios so as it seems to state I should lessen core 5 undervolt in the bios?


----------



## Mach3.2

Audioboxer said:


> Sorry for asking the noob question, but I'm doing my per-core undervolting on my new 5950x and with this message is it core 5 I should lessen the undervolt or core 10? I know it says core 5 above, but just checking.
> 
> Keep getting confused with the way the bios starts at 0 and goes to 15 and Ryzen master starts at 1 and goes to 16 lol. Looks like CoreCycler starts at 0 and goes to 15 like the bios so as it seems to state I should lessen core 5 undervolt in the bios?


Just follow the core number. In your case core 5 failed, just knock back the -ve CO by a notch or two and test again.


----------



## Audioboxer

Mach3.2 said:


> Just follow the core number. In your case core 5 failed, knock back the -ve CO by a notch or two and test again.


Yeah I've done that and I'm testing now 

Core 5 is classed as my second best core on CCD0, so I dropped it from -20 to -15 which the best core is currently on.


----------



## Audioboxer

Let it run for 12 hours, only core still falling was Core 5, again, lol.

Anyone else got a situation like this?

Best cores (1 on CCD0, 1 on CCD1) = -15
2nd best core (on CCD1) = -15
2nd best core (on CCD0) = -5
Everything else = -25

Just seems funny it's one of my 2nd best cores I'm having to reduce whilst the 2 best, and 1 of the 2nd best go fine on -15 lol.

I would have thought the two best would be falling before any below them 

Testing -5 now and so far after only hitting that core for 35 mins it's fine. I guess the good news for me is none of the others fell on their first overnight run so they might even be able to be undervolted a bit more.


----------



## sp00n82

My CO settings range from -9 to -30, so yeah, it can vary quite a bit.

And regarding the enumeration, as @Mach3.2 has mentioned, the core number matches the list in the BIOS. I don't know why Ryzen Master starts the list with 1 instead of 0, probably because they thought that starting a list with 0 would confuse customers, I don't know. Apparently they didn't think it would be an issue if the enumerations are different in Ryzen Master and the BIOS.
I followed the way the BIOS is doing it because it's the more fundamental setting.
Concerning the "CPU" display, this one follows the way the Task Manager in Windows is displaying the affinity. Since with SMT enabled every core has two "virtual" CPUs, the displayed CPU number is basically "core number * 2" (and additionally "(core number * 2) + 1" for 2 threads). The Task Manager also start the list with a 0 by the way, which makes it even less comprehensible why AMD deviated from that in Ryzen Master.


----------



## Audioboxer

sp00n82 said:


> My CO settings range from -9 to -30, so yeah, it can vary quite a bit.
> 
> And regarding the enumeration, as @Mach3.2 has mentioned, the core number matches the list in the BIOS. I don't know why Ryzen Master starts the list with 1 instead of 0, probably because they thought that starting a list with 0 would confuse customers, I don't know. Apparently they didn't think it would be an issue if the enumerations are different in Ryzen Master and the BIOS.
> I followed the way the BIOS is doing it because it's the more fundamental setting.
> Concerning the "CPU" display, this one follows the way the Task Manager in Windows is displaying the affinity. Since with SMT enabled every core has two "virtual" CPUs, the displayed CPU number is basically "core number * 2" (and additionally "(core number * 2) + 1" for 2 threads). The Task Manager also start the list with a 0 by the way, which makes it even less comprehensible why AMD deviated from that in Ryzen Master.


Thanks, yeah it only briefly confused me, all good now and I agree following the BIOS is the smart way to do it.


----------



## cyberloner

been testing curve ortimizer for many days and gain stable 12hours... but with latest bios 1.2.0.3b beta.... my core 3 keep error at negative/positive set at 0 .... is this normal?
i add positve 2 and running test again ......... 

by the way 
gaming intermitent whea error when my weather here hot day with hyper212 but stable when cool day lol
disable curve will stable.... :/


----------



## sp00n82

cyberloner said:


> been testing curve ortimizer for many days and gain stable 12hours... but with latest bios 1.2.0.3b beta.... my core 3 keep error at negative/positive set at 0 .... is this normal?
> i add positve 2 and running test again .........
> 
> by the way
> gaming intermitent whea error when my weather here hot day with hyper212 but stable when cool day lol
> disable curve will stable.... :/


Unfortunately a BIOS update may completely throw over a so far stable overclock, not only for PBO/CO settings, but also for RAM overclocks. You never know what internal settings have changed/shifted with a new BIOS or AGESA version, there might be some voltage changes here and there or "optimizations" that completely break a once stable OC setup.

(And by the way, WHEA errors may also occur due to a bad RAM overclock, and can also be temperature related, especially for Samsung B-die sticks.)


----------



## Vayne4800

Hello sp00n82. First thanks for the great software. Really helping me optimize my OC so far vs OCCT. With that said, I have read a big chunk of this thread and many others and want to know the following:


When you say to have run all loops and configurations for testing. Can you propose a sequence of settings? e.g. Prime95 with Large, then do y-Cruncher, then so on and on? The permutations in the tool are quite many and would like to have a path that will enable to converge to reliability faster in a way.
Doom Eternal resets my PC within minutes with the settings below. What CC settings can I use to mimick the game? So far it has been the most noticable practical instability test that I have and it usually does that within an hour or so.

Thanks,


----------



## sp00n82

Vayne4800 said:


> Hello sp00n82. First thanks for the great software. Really helping me optimize my OC so far vs OCCT. With that said, I have read a big chunk of this thread and many others and want to know the following:
> 
> 
> When you say to have run all loops and configurations for testing. Can you propose a sequence of settings? e.g. Prime95 with Large, then do y-Cruncher, then so on and on? The permutations in the tool are quite many and would like to have a path that will enable to converge to reliability faster in a way.
> Doom Eternal resets my PC within minutes with the settings below. What CC settings can I use to mimick the game? So far it has been the most noticable practical instability test that I have and it usually does that within an hour or so.
> 
> Thanks,


Hm. I developed the tool while testing my own setup, so basically whenever I implemented a new feature I switched to this to check if it's working. So I couldn't really establish a specific order of sequence.

However if I were to run this on a new computer, I would probably first do a couple of runs with the default settings (SSE, huge FFT, 6 minutes) to find a seemingly stable setup that doesn't throw any immediate errors. If this has run successfully for a couple of hours / over night without an error, I would then switch to 2 threads and repeat the test.
When this seems stable, it's time for the real stability test, so I would switch to 1 thread, SSE, All FFT and an automatic runtime and let it run at least one full iteration. Then switch to AVX and repeat. And then switch to AVX2 and repeat. And then repeat this with 2 threads.

I found most of my errors with SSE and 1 thread, but AVX/AVX2 and 2 threads did find some later in the process for me as well, so for a thorough stability test I think it's necessary to include them.
Another alternative for quick stability testing would be Small FFT and 2 minutes per core. I actually found many of my errors with this setting, before I added the more advanced features in CoreCycler.

y-Cruncher and Aida64 were added relatively late in the development process, so I don't have too much experience with these. But y-Cruncher either completely crashed my PC or ran through fine during my somewhat limited testing runs (i.e. when artificially setting the Curve Optimizer to unstable values).

If a game like Doom Eternal brings quick(er) results for you, I would stick to it as much possible. Playing a game for stability testing is undeniably more fun than letting the CoreCycler run, but of course you have to approach it with the mindset of actually wanting to test the stability, and not with the expectiaton of the game running flawlessly.


(On a side note, I don't really understand what the "Auto" entry for the FFT column is supposed to mean. All FFT sizes? Auto runtime?)


----------



## Vayne4800

The issue with Doom Eternal, despite it being really faster with the instability, is my inability to figure out which core caused this reboot. Hence why I am asking if there is away to mimick the behaviour through Core Cycler as that will enable me to find the core (I understand that Doom runs multiple cores at different times and different loads). I will try your suggest on the earlier point.


----------



## Veii

Vayne4800 said:


> The issue with Doom Eternal, despite it being really faster with the instability, is my inability to figure out which core caused this reboot. Hence why I am asking if there is away to mimick the behaviour through Core Cycler as that will enable me to find the core (I understand that Doom runs multiple cores at different times and different loads). I will try your suggest on the earlier point.


Did you by any chance get 3D mark on steam ? ~ currently 82-85% off (whole DLC pack)
The CPU Profile benchmark, is detecting unstable Curve optimizer cores 
(tho more of a benchmark, than really a stress test ~ it's just aggressive & you might be able to force couple of cores onto the benchmark)
OOCT seems also to have gotten a CPU benchmark ~ soo likely running Core Cycler for OCCT / could show quite fast if it's a voltage drop issue, heat issue or whatever causes instability after long gaming sessions

It can also be just ram ~ by the GPU dumping heat into it


----------



## Vayne4800

Veii said:


> Did you by any chance get 3D mark on steam ? ~ currently 82-85% off (whole DLC pack)
> The CPU Profile benchmark, is detecting unstable Curve optimizer cores
> (tho more of a benchmark, than really a stress test ~ it's just aggressive & you might be able to force couple of cores onto the benchmark)
> OOCT seems also to have gotten a CPU benchmark ~ soo likely running Core Cycler for OCCT / could show quite fast if it's a voltage drop issue, heat issue or whatever causes instability after long gaming sessions
> 
> It can also be just ram ~ by the GPU dumping heat into it


I have 3DMark. I did read there is a new CPU benchmark or something but didn't check it out yet. Eitherway, I will need away to find which CPU is causing the issue. I am not getting WHEA errors. Just reboot in Doom Eternal (I did get one once in Iron Harvest). So hence I need to find a way to mimick some sort of game load or behaviour. I have OCCT also but it passes everything.

When you say force Cores in the 3DMark, how?


----------



## sp00n82

@Vayne4800
You could try to enable logging in HWInfo, and then after a crash check the log file which core(s) were currently used.


----------



## Vayne4800

Thanks sp00n82 for answering my questions. One other one is: Is it ok if CoreCycler is running while I do work (remote desktop connection/citrix) or the odd low-medium load game? Or will that negatively impact the outcome of the tests (i.e. They might end up showing no error, when in a none use state it would)?


----------



## cyberloner

Vayne4800 said:


> Thanks sp00n82 for answering my questions. One other one is: Is it ok if CoreCycler is running while I do work (remote desktop connection/citrix) or the odd low-medium load game? Or will that negatively impact the outcome of the tests (i.e. They might end up showing no error, when in a none use state it would)?


if you ask me... i run corecycle and watch youtube


----------



## sp00n82

Vayne4800 said:


> Thanks sp00n82 for answering my questions. One other one is: Is it ok if CoreCycler is running while I do work (remote desktop connection/citrix) or the odd low-medium load game? Or will that negatively impact the outcome of the tests (i.e. They might end up showing no error, when in a none use state it would)?


It might affect the outcome, as it might affect (reduce) the boost clock if more than one core is used at a time.
That being said, I also used my computer while running CoreCycler in the background, although not for gaming, which probably stresses the CPU more than other tasks.
The optimal scenario is certainly running CoreCycler without any additional programs running simultaneously, e.g. over night.


----------



## Vayne4800

sp00n82 said:


> @Vayne4800
> You could try to enable logging in HWInfo, and then after a crash check the log file which core(s) were currently used.


I tried logging but couldn't come up with any information that shows which CPU caused the reboot. It is your regular stats and so on. Here is the log for anyone to check. I am continuing with the regular CoreCycler plan that sp00n82 suggested.


----------



## sp00n82

Vayne4800 said:


> I tried logging but couldn't come up with any information that shows which CPU caused the reboot. It is your regular stats and so on. Here is the log for anyone to check. I am continuing with the regular CoreCycler plan that sp00n82 suggested.


You didn't attach the log file.

From looking at my HWInfo log file, there are fields for "Core x Tn Effective Clock [MHz]" and "Core x Tn Usage [%]", which should give enough information to determine which cores were active.
You might need to active the logging of these in the settings first though, I can't remember exactly.


----------



## Vayne4800

Forums didn't let me upload CSV. So providing a link. Will check your suggestion too.


----------



## craxton

Hmm, unsure whats going on with this but... i can run an "all core -17 on my 5800x (passing iteration 4 now)
no issue? but setting per core to -17 seems to cause me to have a random reboot?

(no offset, just "amd overclocking set on voltage option. but first, i gotta set a +1 offset then boot to windows,
then reboot back to bios and remove it. then set to amd overclocking for "voltage" on the core.

unsure if this is "resetting" what the supplied voltage is supposed to be at.
but just changing to "per-core" -17 causes a crash, so long as i set that +1 offset and do what i mentioned
above im good....(edit) no i dont use the machine, just got up at 6:40 for work)


anyone wanna see if this does the same for them?












Code:


01:29:14 - Iteration 1
----------------------------------
01:29:14 - Set to Core 4 (CPU 8)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
01:41:11 - Set to Core 0 (CPU 0)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
01:55:56 - Set to Core 1 (CPU 2)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
02:07:28 - Set to Core 2 (CPU 4)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
02:22:02 - Set to Core 3 (CPU 6)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
02:33:41 - Set to Core 5 (CPU 10)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
02:48:26 - Set to Core 6 (CPU 12)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
03:00:10 - Set to Core 7 (CPU 14)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one

03:14:55 - Iteration 2
----------------------------------
03:14:55 - Set to Core 4 (CPU 8)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
03:26:52 - Set to Core 0 (CPU 0)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
03:41:37 - Set to Core 1 (CPU 2)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
03:53:17 - Set to Core 2 (CPU 4)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
04:07:38 - Set to Core 3 (CPU 6)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
04:19:22 - Set to Core 5 (CPU 10)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
04:34:06 - Set to Core 6 (CPU 12)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
04:45:51 - Set to Core 7 (CPU 14)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one

05:00:35 - Iteration 3
----------------------------------
05:00:35 - Set to Core 4 (CPU 8)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
05:12:27 - Set to Core 0 (CPU 0)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
05:27:12 - Set to Core 1 (CPU 2)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
05:38:56 - Set to Core 2 (CPU 4)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
05:53:17 - Set to Core 3 (CPU 6)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
06:05:01 - Set to Core 5 (CPU 10)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
06:19:42 - Set to Core 6 (CPU 12)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
06:31:38 - Set to Core 7 (CPU 14)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one

06:46:23 - Iteration 4
----------------------------------
06:46:23 - Set to Core 4 (CPU 8)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
06:58:07 - Set to Core 0 (CPU 0)
           Running until all FFT sizes have been tested...


----------



## sp00n82

Vayne4800 said:


> Forums didn't let me upload CSV. So providing a link. Will check your suggestion too.


And now the link is dead 
You could just rename the .csv file to .txt, which you then should be able to be attached here (if it isn't too big).


@craxton 
No idea about your issue. You could try to monitor the max boost clock and the used voltage, maybe some settings are overridden / applied twice / ignored with the different methods.


----------



## ManniX-ITA

craxton said:


> no issue? but setting per core to -17 seems to cause me to have a random reboot?


per core and all core are not the same, even with the same count

14 mins for all FFT means you are testing only with SSE Small?
it's rebooting cause it's unstable
You need to test also Large and Huge at least
But still to be 100% sure it works you need to test all FFT with SSE/AVX/AVX2...


----------



## KedarWolf

craxton said:


> Hmm, unsure whats going on with this but... i can run an "all core -17 on my 5800x (passing iteration 4 now)
> no issue? but setting per core to -17 seems to cause me to have a random reboot?
> 
> (no offset, just "amd overclocking set on voltage option. but first, i gotta set a +1 offset then boot to windows,
> then reboot back to bios and remove it. then set to amd overclocking for "voltage" on the core.
> 
> unsure if this is "resetting" what the supplied voltage is supposed to be at.
> but just changing to "per-core" -17 causes a crash, so long as i set that +1 offset and do what i mentioned
> above im good....(edit) no i dont use the machine, just got up at 6:40 for work)
> 
> 
> anyone wanna see if this does the same for them?
> View attachment 2516465
> 
> 
> 
> 
> 
> Code:
> 
> 
> 01:29:14 - Iteration 1
> ----------------------------------
> 01:29:14 - Set to Core 4 (CPU 8)
> Running until all FFT sizes have been tested...
> All FFT sizes have been tested for this core, continuing to the next one
> 01:41:11 - Set to Core 0 (CPU 0)
> Running until all FFT sizes have been tested...
> All FFT sizes have been tested for this core, continuing to the next one
> 01:55:56 - Set to Core 1 (CPU 2)
> Running until all FFT sizes have been tested...
> All FFT sizes have been tested for this core, continuing to the next one
> 02:07:28 - Set to Core 2 (CPU 4)
> Running until all FFT sizes have been tested...
> All FFT sizes have been tested for this core, continuing to the next one
> 02:22:02 - Set to Core 3 (CPU 6)
> Running until all FFT sizes have been tested...
> All FFT sizes have been tested for this core, continuing to the next one
> 02:33:41 - Set to Core 5 (CPU 10)
> Running until all FFT sizes have been tested...
> All FFT sizes have been tested for this core, continuing to the next one
> 02:48:26 - Set to Core 6 (CPU 12)
> Running until all FFT sizes have been tested...
> All FFT sizes have been tested for this core, continuing to the next one
> 03:00:10 - Set to Core 7 (CPU 14)
> Running until all FFT sizes have been tested...
> All FFT sizes have been tested for this core, continuing to the next one
> 
> 03:14:55 - Iteration 2
> ----------------------------------
> 03:14:55 - Set to Core 4 (CPU 8)
> Running until all FFT sizes have been tested...
> All FFT sizes have been tested for this core, continuing to the next one
> 03:26:52 - Set to Core 0 (CPU 0)
> Running until all FFT sizes have been tested...
> All FFT sizes have been tested for this core, continuing to the next one
> 03:41:37 - Set to Core 1 (CPU 2)
> Running until all FFT sizes have been tested...
> All FFT sizes have been tested for this core, continuing to the next one
> 03:53:17 - Set to Core 2 (CPU 4)
> Running until all FFT sizes have been tested...
> All FFT sizes have been tested for this core, continuing to the next one
> 04:07:38 - Set to Core 3 (CPU 6)
> Running until all FFT sizes have been tested...
> All FFT sizes have been tested for this core, continuing to the next one
> 04:19:22 - Set to Core 5 (CPU 10)
> Running until all FFT sizes have been tested...
> All FFT sizes have been tested for this core, continuing to the next one
> 04:34:06 - Set to Core 6 (CPU 12)
> Running until all FFT sizes have been tested...
> All FFT sizes have been tested for this core, continuing to the next one
> 04:45:51 - Set to Core 7 (CPU 14)
> Running until all FFT sizes have been tested...
> All FFT sizes have been tested for this core, continuing to the next one
> 
> 05:00:35 - Iteration 3
> ----------------------------------
> 05:00:35 - Set to Core 4 (CPU 8)
> Running until all FFT sizes have been tested...
> All FFT sizes have been tested for this core, continuing to the next one
> 05:12:27 - Set to Core 0 (CPU 0)
> Running until all FFT sizes have been tested...
> All FFT sizes have been tested for this core, continuing to the next one
> 05:27:12 - Set to Core 1 (CPU 2)
> Running until all FFT sizes have been tested...
> All FFT sizes have been tested for this core, continuing to the next one
> 05:38:56 - Set to Core 2 (CPU 4)
> Running until all FFT sizes have been tested...
> All FFT sizes have been tested for this core, continuing to the next one
> 05:53:17 - Set to Core 3 (CPU 6)
> Running until all FFT sizes have been tested...
> All FFT sizes have been tested for this core, continuing to the next one
> 06:05:01 - Set to Core 5 (CPU 10)
> Running until all FFT sizes have been tested...
> All FFT sizes have been tested for this core, continuing to the next one
> 06:19:42 - Set to Core 6 (CPU 12)
> Running until all FFT sizes have been tested...
> All FFT sizes have been tested for this core, continuing to the next one
> 06:31:38 - Set to Core 7 (CPU 14)
> Running until all FFT sizes have been tested...
> All FFT sizes have been tested for this core, continuing to the next one
> 
> 06:46:23 - Iteration 4
> ----------------------------------
> 06:46:23 - Set to Core 4 (CPU 8)
> Running until all FFT sizes have been tested...
> All FFT sizes have been tested for this core, continuing to the next one
> 06:58:07 - Set to Core 0 (CPU 0)
> Running until all FFT sizes have been tested...


Try disabling C-States and have your Idle Power on Normal, not Low or Auto.


----------



## Vayne4800

sp00n82 said:


> And now the link is dead
> You could just rename the .csv file to .txt, which you then should be able to be attached here (if it isn't too big).
> 
> 
> @craxton
> No idea about your issue. You could try to monitor the max boost clock and the used voltage, maybe some settings are overridden / applied twice / ignored with the different methods.


Fixed. Sorry for that.


----------



## craxton

ManniX-ITA said:


> per core and all core are not the same, even with the same count
> 
> 14 mins for all FFT means you are testing only with SSE Small?
> it's rebooting cause it's unstable
> You need to test also Large and Huge at least
> But still to be 100% sure it works you need to test all FFT with SSE/AVX/AVX2...


ok, well this is with "per core" i think, or might be an "all core" -18 if its all core,
per core would be -18 all cores but number 4 which would be -15.

does any of you who know this "test" inside and out see anything i should change?
manna if you could share a screenshot of what i need to configure?
unless you mean no time limit? as in "all FFT sizes?"

the thing is if i geta "crash" then i cant run these values again.
but if i set that +1 offset let windows boot, then restart into the bios,
and remove this +1 offset and swap back to amd overclocking as voltage option
then i can run this no issue (test was running while at work, sure core 1 failed)
but usually it doesnt. pretty sure it failed due to my ol lady trying to get on while i was at work
to watch netflix.

so, if you gotta MSI board, try running an ALL CORE CURVE with a +1 let windows BOOT,
then restart to bios REMOVE that +1 offset, set it to AMD overclocking, reboot to windows and check
on "what you know is not able to run" and see if it crashes or runs?????????
please, would like to know what bug im triggering. "while i do this" sil quality is 125-130
but once i do the +1 boot, restart/remove boot thing im speaking of "sil quality goes up +10-20 points?!??!!?

(i see selected FFT size is set to HUGE (8960k-32768k)
is this what your talking about manna, to turn on? or set it to what exactly????



Code:


Starting the CoreCycler...
--------------------------------------------------------------------------------
-------------- CoreCycler v0.8.2.4 started at 2021-07-05 07:33:22 --------------
--------------------------------------------------------------------------------
Log Level set to: ......... 2 [Writing debug messages to log file]
Stress test program: ...... PRIME95
Selected test mode: ....... SSE
Logical/Physical cores: ... 16 logical / 8 physical cores
Hyperthreading / SMT is: .. ON
Selected number of threads: 1
Runtime per core: ......... AUTOMATIC
Suspend periodically: ..... ENABLED
Restart for each core: .... OFF
Test order of cores: ...... 4, 0, 1, 2, 3, 5, 6, 7
Number of iterations: ..... 10000
Selected FFT size: ........ HUGE (8960K - 32768K)

--------------------------------------------------------------------------------
The log files for this run are stored in:
C:\Users\rhens\Desktop\CoreCycler-v0.8.2.4\CoreCycler-v0.8.2.4\logs\
- CoreCycler:   CoreCycler_2021-07-05_07-33-18_PRIME95_SSE.log
- Prime95:      Prime95_2021-07-05_07-33-18_SSE_HUGE_FFT_8960K-32768K.txt
--------------------------------------------------------------------------------


07:33:24 - Iteration 1
----------------------------------
07:33:24 - Set to Core 4 (CPU 8)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
07:45:35 - Set to Core 0 (CPU 0)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
08:00:33 - Set to Core 1 (CPU 2)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
08:12:07 - Set to Core 2 (CPU 4)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
08:26:41 - Set to Core 3 (CPU 6)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
08:38:26 - Set to Core 5 (CPU 10)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
08:53:20 - Set to Core 6 (CPU 12)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
09:05:18 - Set to Core 7 (CPU 14)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one

09:20:04 - Iteration 2
----------------------------------
09:20:04 - Set to Core 4 (CPU 8)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
09:32:02 - Set to Core 0 (CPU 0)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
09:47:00 - Set to Core 1 (CPU 2)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
09:58:41 - Set to Core 2 (CPU 4)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
10:13:16 - Set to Core 3 (CPU 6)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
10:25:01 - Set to Core 5 (CPU 10)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
10:39:47 - Set to Core 6 (CPU 12)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
10:51:45 - Set to Core 7 (CPU 14)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one

11:06:32 - Iteration 3
----------------------------------
11:06:32 - Set to Core 4 (CPU 8)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
11:18:37 - Set to Core 0 (CPU 0)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
11:33:35 - Set to Core 1 (CPU 2)
           Running until all FFT sizes have been tested...
ERROR: 11:36:36
ERROR: Prime95 seems to have stopped with an error!
ERROR: At Core 1 (CPU 2)
ERROR MESSAGE: FATAL ERROR: Rounding was 0.5, expected less than 0.4
ERROR: The last *passed* FFT size before the error was: 11520K
ERROR: Unfortunately FFT size fail detection only works for Smallest, Small or Large FFT sizes.

11:36:36 - Trying to restart Prime95
11:36:39 - Set to Core 2 (CPU 4)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
11:48:14 - Set to Core 3 (CPU 6)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
12:03:01 - Set to Core 5 (CPU 10)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
12:14:46 - Set to Core 6 (CPU 12)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
12:29:33 - Set to Core 7 (CPU 14)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
The following cores have thrown an error: 1

12:41:26 - Iteration 4
----------------------------------
12:41:26 - Set to Core 4 (CPU 8)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
12:56:25 - Set to Core 0 (CPU 0)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
13:08:23 - Core 1 (CPU 2) has previously thrown an error, skipping
13:08:23 - Set to Core 2 (CPU 4)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
13:22:46 - Set to Core 3 (CPU 6)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
13:34:43 - Set to Core 5 (CPU 10)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
13:49:30 - Set to Core 6 (CPU 12)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
14:01:23 - Set to Core 7 (CPU 14)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
The following cores have thrown an error: 1

14:16:10 - Iteration 5
----------------------------------
14:16:10 - Set to Core 4 (CPU 8)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
14:28:07 - Set to Core 0 (CPU 0)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
14:43:06 - Core 1 (CPU 2) has previously thrown an error, skipping
14:43:06 - Set to Core 2 (CPU 4)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
14:54:51 - Set to Core 3 (CPU 6)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
15:09:26 - Set to Core 5 (CPU 10)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
15:21:31 - Set to Core 6 (CPU 12)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
15:36:18 - Set to Core 7 (CPU 14)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
The following cores have thrown an error: 1

15:48:16 - Iteration 6
----------------------------------
15:48:16 - Set to Core 4 (CPU 8)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
16:03:14 - Set to Core 0 (CPU 0)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
16:15:12 - Core 1 (CPU 2) has previously thrown an error, skipping
16:15:12 - Set to Core 2 (CPU 4)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
16:29:47 - Set to Core 3 (CPU 6)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
16:41:28 - Set to Core 5 (CPU 10)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
16:56:26 - Set to Core 6 (CPU 12)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
17:08:12 - Set to Core 7 (CPU 14)
           Running until all FFT sizes have been tested...
           All FFT sizes have been tested for this core, continuing to the next one
The following cores have thrown an error: 1

17:23:11 - Iteration 7
----------------------------------
17:23:11 - Set to Core 4 (CPU 8)
           Running until all FFT sizes have been tested...

@ManniX-ITA
i have now changed it to
Log Level set to: ......... 2 [Writing debug messages to log file]
Stress test program: ...... PRIME95
Selected test mode: ....... AVX2
Logical/Physical cores: ... 16 logical / 8 physical cores
Hyperthreading / SMT is: .. ON
Selected number of threads: 1
Runtime per core: ......... AUTOMATIC
Suspend periodically: ..... ENABLED
Restart for each core: .... OFF
Test order of cores: ...... 4, 0, 1, 2, 3, 5, 6, 7
Number of iterations: ..... 10000
Selected FFT size: ........ ALL

(i then after a full day) would change "selected test mode" to AVX ?
or can one just select "ALL" there as well?
NOTES: i would like to be able to incorporate AIDA extreme, and y-cruncher as well.
i have a "full" key for aida so thats not the issue, ive copied the files over. but im unsure
what im supposed to change and if "ALL for FFT, and stress test program is a good idea, 
wouldnt the .bat file just run all the tests at one time, to such would crash any pc at ANY stock/modded values?


----------



## craxton

KedarWolf said:


> Try disabling C-States and have your Idle Power on Normal, not Low or Auto.


i have C-states turned off inside the bios, but on WIN 11 it does nothing
as shown when i open ZEN-debug...
i have power supply set to "typical" but again, i seen "torqk" in zen overclocking thread
mention he can get zenstates off by setting powersupply idle control to typical, with C-states turned to auto.

im curruntly on a "LOCKED" bios to which all i have is AMDs default settings, as EDER never responded nor uploaded
the new bios with unlocked settings.


Spoiler



(i tried to PM him) but it did no good)



EDIIIITTTTT

I RETRACT THAT it would SEEM thats what im triggering, is that DF-CSTATES ARE BEING TURNED OFF
by my +1 boot, restart remove/set amd, reboot bug im doing thats turning off DF-Cstates.
going to restart right quick and check to see if it triggers back on again as "im not switching it myself"
do note that the values in zenstates are not what i have set manually, 142-90-180 are what i have. to which EDC doesnt go over 168-170 even with lifted
PPT-TDC values.

(LAST EDIT) i did do ONE THING differently this morning while i know 100% for a FACT DF-Cstates were indeed ON 
even with me saying NO TURN OFF inside the bios, i switched the "scaler" from 1x to 4x as setting 1x inside the "main MSI page for CPU"
shows its on one, but inside AMDs Overclocking section states its on "auto" 

so i manually set it to 4x. but prior to that i was passing core cycler with DF-Cstates being on. 
id just randomly crash out at some point. 
so, if scaler for whatever reason triggers "cstates to turn off" then im all for it as i usually leave it under 4x
mostly to 1x. 








after reboot, still shows DF-Cstates are OFF but im going to "try" to trigger a crash
to which if im able to, DF-Cstates will AUTO turn back on again. with OUT me changing it in the bios.


----------



## narukun

Did anyone experience early degradation using this software? My ryzen 5900x went from -13 from a core to give errors even using a positive curve, same bios same everything


----------



## KedarWolf

narukun said:


> Did anyone experience early degradation using this software? My ryzen 5900x went from -13 from a core to give errors even using a positive curve, same bios same everything


Try resetting your BIOS and manually entering all the settings you use. Clear CMOS button is best if you have one.


----------



## ManniX-ITA

craxton said:


> (i then after a full day) would change "selected test mode" to AVX ?
> or can one just select "ALL" there as well?


I would start with SSE, which gives you the highest clock frequency cause the workload is lighter.
Only when you are sure it's safe, move to AVX and then AVX2.

FFT Size is ok ALL but it's usually best to first run a Small/Large to fix the most obvious issues.

Runtime is ok set to Auto as will cycle all the FFT selected


----------



## sp00n82

craxton said:


> NOTES: i would like to be able to incorporate AIDA extreme, and y-cruncher as well.
> i have a "full" key for aida so thats not the issue, ive copied the files over. but im unsure
> what im supposed to change and if "ALL for FFT, and stress test program is a good idea,
> wouldnt the .bat file just run all the tests at one time, to such would crash any pc at ANY stock/modded values?


The FFTsize setting is only for Prime95, for Aida64 and y-Cruncher there are dedicated sections in the config file.

Aida64 Extreme however will most likely NOT work, as only the Engineer, Network Audit and Business version will support command line switches, at least according to their docs. And without these command line switches you cannot directly jump into a test, which is what CoreCycler tries to do.

There are no such restrictions for y-Cruncher, but it unfortunately doesn't create any log file (and I couldn't force it to either) so it's harder to reconstruct what exactly happened if there was an error/reboot.


----------



## sp00n82

Vayne4800 said:


> I tried logging but couldn't come up with any information that shows which CPU caused the reboot. It is your regular stats and so on. Here is the log for anyone to check. I am continuing with the regular CoreCycler plan that sp00n82 suggested.


Core 0 and 5 seem to have been used the most, although none of them was at max speed. 
Your polling speed to write to the log file is set to 2 seconds though, so you might have missed some information there.


----------



## ManniX-ITA

Vayne4800 said:


> Forums didn't let me upload CSV. So providing a link. Will check your suggestion too.


It would be easier if the CSV export contains a proper date/time and separated by comma.
How it is configured? Which version of HWInfo are you using?


----------



## Vayne4800

sp00n82 said:


> Core 0 and 5 seem to have been used the most, although none of them was at max speed.
> Your polling speed to write to the log file is set to 2 seconds though, so you might have missed some information there.


Yeah, Core 0 and 5 are the ones used most by everything. Doom Eternal isn't a CPU intensive game. Maybe that is why they weren't at Max Speed?



ManniX-ITA said:


> It would be easier if the CSV export contains a proper date/time and separated by comma.
> How it is configured? Which version of HWInfo are you using?


I am using the latest HWInfo but the log uploaded was from the version before the latest. I haven't done any modification to the configuration. Just now I changed the timesteps to log every 1 second instead of 2.


----------



## ManniX-ITA

Vayne4800 said:


> I am using the latest HWInfo but the log uploaded was from the version before the latest. I haven't done any modification to the configuration. Just now I changed the timesteps to log every 1 second instead of 2.


I'd take the log while running CoreCycler, isn't crashing also while running it?

The problem in your log is that the Time is "running time" and not "clock time":



Code:


Date    Time    Vir
3.7.2021    13:38.6
3.7.2021    13:40.6
3.7.2021    13:42.6
3.7.2021    13:44.6

It should be formatted as such:



Code:


Date,Time,"Virtual Mem
6.7.2021,16:13:14.636,
6.7.2021,16:13:15.693,
6.7.2021,16:13:16.734,
6.7.2021,16:13:17.773,
6.7.2021,16:13:18.818,

Otherwise the great Generic Log Viewer, doesn't work:









Generic Log Viewer Download


Generic Log Viewer ermöglicht die grafische Auswertung der Logfiles von Afterburner, AIDA64, GPU-Z und HWiNFO. Freeware, kostenloser Download!




www.computerbase.de





If you can fix the log formatting and take it while running CC then it's easy to spot the failing core.


----------



## dansi

narukun said:


> Did anyone experience early degradation using this software? My ryzen 5900x went from -13 from a core to give errors even using a positive curve, same bios same everything


doubt is degradation. your first time was probably not stable at -13, but you just did not encounter the event to trigger a crash.

the way ryzen work, based on my experience of zen1+, zen2 and zen3, there is some internal firmware FIT controls that auto adjust the parameters which can overrides any bios settings.


----------



## Vayne4800

ManniX-ITA said:


> I'd take the log while running CoreCycler, isn't crashing also while running it?
> 
> The problem in your log is that the Time is "running time" and not "clock time":
> 
> 
> 
> Code:
> 
> 
> Date    Time    Vir
> 3.7.2021    13:38.6
> 3.7.2021    13:40.6
> 3.7.2021    13:42.6
> 3.7.2021    13:44.6
> 
> It should be formatted as such:
> 
> 
> 
> Code:
> 
> 
> Date,Time,"Virtual Mem
> 6.7.2021,16:13:14.636,
> 6.7.2021,16:13:15.693,
> 6.7.2021,16:13:16.734,
> 6.7.2021,16:13:17.773,
> 6.7.2021,16:13:18.818,
> 
> Otherwise the great Generic Log Viewer, doesn't work:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Generic Log Viewer Download
> 
> 
> Generic Log Viewer ermöglicht die grafische Auswertung der Logfiles von Afterburner, AIDA64, GPU-Z und HWiNFO. Freeware, kostenloser Download!
> 
> 
> 
> 
> www.computerbase.de
> 
> 
> 
> 
> 
> If you can fix the log formatting and take it while running CC then it's easy to spot the failing core.


I somehow can't get the time to be in a correct format. It doesn't even report correct time. Not sure why.


----------



## ManniX-ITA

Vayne4800 said:


> I somehow can't get the time to be in a correct format. It doesn't even report correct time. Not sure why.


No idea either  
Has to do for sure how the time/date format is set in Windows
Maybe HWInfo does not understand properly your local settings


----------



## Vayne4800

Here is my progress so far and still unable to find any change needed to prevent Doom Eternal from rebooting:










Do note the following on Doom Eternal:

Stable with completely undoing all OCs (GPU, RAM and CPU).
Stable with GPU OC
Stable with GPU + RAM OC

And as you can see above so far, CPU is pretty solid. Also note that the above is running with a -0.05v offset voltage setting on total core.

What is left as per @sp00n82 suggestion is running all FFTs at 2 threads for SSE, AVX and AVX2.

Let me know if anyone has thoughts to converging to a solution faster. I will also take the feedback on the HWInfo logging approach and see if I get more refined results that could identify the offending core.


----------



## ManniX-ITA

Vayne4800 said:


> Let me know if anyone has thoughts to converging to a solution faster


Puzzling, I did expect you would get at some point an error with CC.



Vayne4800 said:


> Stable with CPU + RAM OC


When you say stable with CPU OC meaning also with the above CO counts?
Only unstable when GPU + CPU + RAM OC together?
Could be an issue with temperatures?

If the RAM is overheating it could cause reboots.
Maybe you can try with very conservative RAM settings what happens or test with OCCT.


----------



## Vayne4800

Sorry on the second quote it is GPU + RAM OC. I fixed the typo.

It is possible that the RAM + CPU being OCed could potentially be a culprit, despite running a RAM stresstest pass with AIDA64 with no issues. I'll do some more testing while continue my CPU testing with CC. Hopefully within a weeks time things will be identified.

Also, here is another Doom Eternal run that didn't last long again. I changed the logging to be every second but still nothing I can see that is unusual.


----------



## sp00n82

Vayne4800 said:


> Sorry on the second quote it is GPU + RAM OC. I fixed the typo.
> 
> It is possible that the RAM + CPU being OCed could potentially be a culprit, despite running a RAM stresstest pass with AIDA64 with no issues. I'll do some more testing while continue my CPU testing with CC. Hopefully within a weeks time things will be identified.
> 
> Also, here is another Doom Eternal run that didn't last long again. I changed the logging to be every second but still nothing I can see that is unusual.


You should also test your RAM overclock with Karhu and/or TM5, not just with Aida64. Karhu is (cheap) paid software, and for TM5 there are multiple available configs, although I don't know which one is the recommended one nowadays (I've mostly used the extreme one, but @Veii seems to have written his error explanations for the default one or something).

Also, what kind of RAM are you running? Samsung B-die can be pretty temperature sensitive above 40, 45° (other brands/types not so much), and I've seen RAM temps of about 55°C in your first log if I remember correctly.

And also remember that a RAM OC can negatively impact the stability of an otherwise stable CPU OC, because it puts more stress on the IMC within the CPU.


----------



## ManniX-ITA

sp00n82 said:


> (I've mostly used the extreme one, but @Veii seems to have written his error explanations for the default one or something).


It's the 1usmus config:





__





TM5 0.12 v3 for desktop - Google Drive







drive.google.com





At least 1h:30m test for thermal equilibrium.
And if you run it together with the GPU stressed by Kombustor or OCCT very likely there's no thermal issue.


----------



## Vayne4800

sp00n82 said:


> You should also test your RAM overclock with Karhu and/or TM5, not just with Aida64. Karhu is (cheap) paid software, and for TM5 there are multiple available configs, although I don't know which one is the recommended one nowadays (I've mostly used the extreme one, but @Veii seems to have written his error explanations for the default one or something).
> 
> Also, what kind of RAM are you running? Samsung B-die can be pretty temperature sensitive above 40, 45° (other brands/types not so much), and I've seen RAM temps of about 55°C in your first log if I remember correctly.
> 
> And also remember that a RAM OC can negatively impact the stability of an otherwise stable CPU OC, because it puts more stress on the IMC within the CPU.


So I have used HCI with up to and exceeding 400% (using paid version to ensure to test as much memory as possible) at these RAM OC settings and a similar CPU OC.

I am running Micron ram chips which can run as high as 50-55C, depending with no issues. Not sure if they can run higher but at this point no way Doom Eternal is pushing the ram to higher than stress test temps. So I firmly, if not definitely, believe that RAM temperature is not an issue.

I do understand that having OCed RAM and CPU makes both run at a higher risk if instability.



ManniX-ITA said:


> It's the 1usmus config:
> 
> 
> 
> 
> 
> __
> 
> 
> 
> 
> 
> TM5 0.12 v3 for desktop - Google Drive
> 
> 
> 
> 
> 
> 
> 
> drive.google.com
> 
> 
> 
> 
> 
> At least 1h:30m test for thermal equilibrium.
> And if you run it together with the GPU stressed by Kombustor or OCCT very likely there's no thermal issue.


I downloaded TM5 with 1usmus config and it ran for 18 minutes without spitting any error. Not sure how I can make it run longer.


----------



## ManniX-ITA

Vayne4800 said:


> I do understand that having OCed RAM and CPU makes both run at a higher risk if instability.


I have a doubt only when GPU and CPU are both under stress.
That's why I was suggesting to use MSI Kombustor stress test while testing the RAM with TM5.



Vayne4800 said:


> I downloaded TM5 with 1usmus config and it ran for 18 minutes without spitting any error. Not sure how I can make it run longer.


Go in the bin directory and delete Cfg.Link file.
Open MT.cfg and set Cycles=25 under [Main Section].


----------



## Vayne4800

Just finished 25 cycles of MT5 without errors. Will try to do Kombustor with MT5.


----------



## sp00n82

Yes, the GPU can add a ton of heat to the system, so if you want to test temperature critical components (or your cooling solution), adding Furmark/Kombustor to the mix is essential.


----------



## Kurt Krampmeier

Hello!

i was playing with curve opt. and core cycler for 2 days now and would like to check in for feedback on my results.



Spoiler: Bios Settings CO



Precision Boost Overdrive [Advanced]
PBO Limits [Manual]
PPT Limit [W] [160]
TDC Limit [A] [150]
EDC Limit [A] [160]
Precision Boost Overdrive Scalar [Manual]
Precision Boost Overdrive Scalar [10X]
Curve Optimizer [Per Core]
Core 0 Curve Optimizer Sign [Negative]
Core 0 Curve Optimizer Magnitude [18]
Core 1 Curve Optimizer Sign [Negative]
Core 1 Curve Optimizer Magnitude [22]
Core 2 Curve Optimizer Sign [Negative]
Core 2 Curve Optimizer Magnitude [24]
Core 3 Curve Optimizer Sign [Negative]
Core 3 Curve Optimizer Magnitude [20]
Core 4 Curve Optimizer Sign [Negative]
Core 4 Curve Optimizer Magnitude [25]
Core 5 Curve Optimizer Sign [Negative]
Core 5 Curve Optimizer Magnitude [23]
Core 6 Curve Optimizer Sign [Negative]
Core 6 Curve Optimizer Magnitude [24]
Core 7 Curve Optimizer Sign [Negative]
Core 7 Curve Optimizer Magnitude [28]
Core 8 Curve Optimizer Sign [Negative]
Core 8 Curve Optimizer Magnitude [30]
Core 9 Curve Optimizer Sign [Negative]
Core 9 Curve Optimizer Magnitude [29]
Core 10 Curve Optimizer Sign [Negative]
Core 10 Curve Optimizer Magnitude [28]
Core 11 Curve Optimizer Sign [Negative]
Core 11 Curve Optimizer Magnitude [27]
Max CPU Boost Clock Override [125MHz]
Platform Thermal Throttle Limit [Auto]





Spoiler: 5900x CPPC 



Core 0 with performance number 180
Core 1 with performance number 175
Core 2 with performance number 167
Core 3 with performance number 180
Core 4 with performance number 163
Core 5 with performance number 171
Core 6 with performance number 146
Core 7 with performance number 155
Core 8 with performance number 142
Core 9 with performance number 159
Core 10 with performance number 138
Core 11 with performance number 150





Spoiler: CTR Boost Test



CTR BOOST TESTER RESULTS (test version)
CORE / FREQUENCY / VID / POWER / TEMP
C01 F 4912 V 1.434 W 16 T 64.68
C02 F 4832 V 1.434 W 16.13 T 66.22
C03 F 4852 V 1.438 W 16.16 T 63.7
C04 F 4906 V 1.42 W 15.92 T 66.33
C05 F 4814 V 1.437 W 16.12 T 65.87
C06 F 4824 V 1.401 W 15.03 T 67.11
C07 F 4774 V 1.49 W 12.54 T 58.59
C08 F 4853 V 1.492 W 12.3 T 58.2
C09 F 4804 V 1.486 W 12.29 T 60.5
C10 F 4870 V 1.492 W 12.38 T 59.86
C11 F 4751 V 1.454 W 11.4 T 59
C12 F 4775 V 1.458 W 12.04 T 60.6



settings ran corecycler at 18min per core Prime95 AVX 1T Moderate

PPT is 160W for environmental protection 
Cinebench R23 ~22.000
VID on CCX2 looks a bit high. is this ok?
also boost would not really go further up with higher override
any suggestions for optimization?


----------



## Sleepycat

Vayne4800 said:


> Here is my progress so far and still unable to find any change needed to prevent Doom Eternal from rebooting:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Do note the following on Doom Eternal:
> 
> Stable with completely undoing all OCs (GPU, RAM and CPU).
> Stable with GPU OC
> Stable with GPU + RAM OC
> 
> And as you can see above so far, CPU is pretty solid. Also note that the above is running with a -0.05v offset voltage setting on total core.
> 
> What is left as per @sp00n82 suggestion is running all FFTs at 2 threads for SSE, AVX and AVX2.
> 
> Let me know if anyone has thoughts to converging to a solution faster. I will also take the feedback on the HWInfo logging approach and see if I get more refined results that could identify the offending core.


I had a stable system, not really OC'd too hard. But I would still get crashing in FS2020. I fixed it by running Corecycler using AVX2, single thread, and adjusting CO based on the core that failed.


----------



## Vayne4800

sp00n82 said:


> Yes, the GPU can add a ton of heat to the system, so if you want to test temperature critical components (or your cooling solution), adding Furmark/Kombustor to the mix is essential.


So I ran TM5 for 1 hour with Kombustor running. Temperatures of Memory reached to 61-63C for a long time (lower than the Doom Eternal crashes which was at ~55C). No other odd behaviour so I stopped it. At this point I can say that temperatures aren't potentially causing issues?



Sleepycat said:


> I had a stable system, not really OC'd too hard. But I would still get crashing in FS2020. I fixed it by running Corecycler using AVX2, single thread, and adjusting CO based on the core that failed.


I have a strong feeling it is a core or multiples of them that is causing this but the identification process is not catching anything yet. I am thinking to try run anything that is at -30 offset to -25 max and see if Doom Eternal behaves funny. Then slowly roll back each core to -30 until reboots happen again. Assuming the initial step solves the issues that is. Keeping in mind I passed AVX2 Single Thread All FFTs without incident.


----------



## Kurt Krampmeier

Vayne4800 said:


> So I ran TM5 for 1 hour with Kombustor running. Temperatures of Memory reached to 61-63C for a long time (lower than the Doom Eternal crashes which was at ~55C). No other odd behaviour so I stopped it. At this point I can say that temperatures aren't potentially causing issues?
> 
> 
> 
> I have a strong feeling it is a core or multiples of them that is causing this but the identification process is not catching anything yet. I am thinking to try run anything that is at -30 offset to -25 max and see if Doom Eternal behaves funny. Then slowly roll back each core to -30 until reboots happen again. Assuming the initial step solves the issues that is. Keeping in mind I passed AVX2 Single Thread All FFTs without incident.


did you try to identfy the failing core by WHEA APIC ID that caused reboot? should be quicker


----------



## Vayne4800

Kurt Krampmeier said:


> did you try to identfy the failing core by WHEA APIC ID that caused reboot? should be quicker


So I got to learn how to parse Event Viewer a bit better and found this:










This was reported about 10 seconds after the reboot yesterday. And roughly around the same timeframe gap after each previous reboot. Does this mean that my Core 0 is the culprit and I should try to reduce it further? It is currently at offset -15. I'll try -10 and see if that does anything.


----------



## Kurt Krampmeier

Vayne4800 said:


> Does this mean that my Core 0 is the culprit and I should try to reduce it further? It is currently at offset -15. I'll try -10 and see if that does anything.


APIC 0/1 is core 0 - 2/3 is core 1 and so on

edit: for example, my core 0 is weaker than its CPPC rating would suggest. with same cppc i have to set it +3 higher than core 3. curve is a pain.


----------



## ManniX-ITA

Vayne4800 said:


> Does this mean that my Core 0 is the culprit and I should try to reduce it further? It is currently at offset -15. I'll try -10 and see if that does anything.


Yes but consider also there are other reasons for a core to be unstable with a negative count.
You could fix it with a little step up in VDDG CCD and/or IOD voltage.
Or you can also try with a higher scalar; it will add a little to VIDs and compensate the loss in performances.


----------



## Vayne4800

ManniX-ITA said:


> Yes but consider also there are other reasons for a core to be unstable with a negative count.
> You could fix it with a little step up in VDDG CCD and/or IOD voltage.
> Or you can also try with a higher scalar; it will add a little to VIDs and compensate the loss in performances.


Ok reducing the offset for Core 0 to -10 stopped Doom Eternal reboots. Now, I want to get it back to -15 and go the route that @ManniX-ITA suggested; VDDG CCD and/or IOD voltage or through the scalar changes (currently on auto). Can someone point me to reading material to get that? In the while I continue to run through Core Cycler tests and will report back with final findings.


----------



## jfim88

Hi!
Thanks for this tool!
Today I ran Corecycler with P95 Custom on my 5800X. After an hour of running I left home and left it running. When I came back the script windows was the same, Iteration 1 and the same core, only when I move the mouse it changed to another core. I saw the P95 log and it was running fine all the time, but the Corecycler windows and script doesn’t show the info. I have the sleep/hibernation off in Windows.
What can be the issue?


----------



## Sleepycat

Vayne4800 said:


> I have a strong feeling it is a core or multiples of them that is causing this but the identification process is not catching anything yet. I am thinking to try run anything that is at -30 offset to -25 max and see if Doom Eternal behaves funny. Then slowly roll back each core to -30 until reboots happen again. Assuming the initial step solves the issues that is. Keeping in mind I passed AVX2 Single Thread All FFTs without incident.


One of my cores in CCX1 actually needed a +10 offset. It didn't affect overclocking ability etc, and because it was just 1 core, the temperature increase was not too noticeable. Don't be afraid to use positive offset if Corecycler still finds AVX2 errors.
Mine are:
CCX1: -25, +10, -15, 0, -25, -25
CCX2: -30, -25, -15, -25, -30, -15

The spread is wide and also CCX1 can reach higher speeds than CCX2, but is also likely to require more voltage than CCX2.


----------



## Audioboxer

Sleepycat said:


> One of my cores in CCX1 actually needed a +10 offset. It didn't affect overclocking ability etc, and because it was just 1 core, the temperature increase was not too noticeable. Don't be afraid to use positive offset if Corecycler still finds AVX2 errors.
> Mine are:
> CCX1: -25, +10, -15, 0, -25, -25
> CCX2: -30, -25, -15, -25, -30, -15
> 
> The spread is wide and also CCX1 can reach higher speeds than CCX2, but is also likely to require more voltage than CCX2.


Have you given your CPU a go on default with CoreCycler (everything on 0)? I really don't think a core should be requiring a positive offset like that.


----------



## sp00n82

jfim88 said:


> Hi!
> Thanks for this tool!
> Today I ran Corecycler with P95 Custom on my 5800X. After an hour of running I left home and left it running. When I came back the script windows was the same, Iteration 1 and the same core, only when I move the mouse it changed to another core. I saw the P95 log and it was running fine all the time, but the Corecycler windows and script doesn’t show the info. I have the sleep/hibernation off in Windows.
> What can be the issue?


You probably clicked inside the terminal window and activated the select mode. Which in turn pauses the execution of any scripts until you press a key. This is a known issue in Windows, I've also mentioned it in the readme.txt.

See e.g. here: https://stackoverflow.com/questions/3204423/long-running-powershell-script-freezes

You can disable this behavior by disabling the Quick Edit Mode, instructions on how to do so are also found in the link above.


----------



## jfim88

sp00n82 said:


> You probably clicked inside the terminal window and activated the select mode. Which in turn pauses the execution of any scripts until you press a key. This is a known issue in Windows, I've also mentioned it in the readme.txt.
> 
> See e.g. here: https://stackoverflow.com/questions/3204423/long-running-powershell-script-freezes
> 
> You can disable this behavior by disabling the Quick Edit Mode, instructions on how to do so are also found in the link above.


Oh! Thanks you! Sorry about not seeing this in Readme.
Also, what settings to test do you recommend to start tuning the curve? P95? SSE or AVX? Maybe ycruncher?


----------



## jfim88

What is this error?


http://imgur.com/a/r178PwO


----------



## ManniX-ITA

jfim88 said:


> What is this error?


It can't write to the log file.
Which usually means either there's no more free space or the disk C: is corrupt.


----------



## jfim88

ManniX-ITA said:


> It can't write to the log file.
> Which usually means either there's no more free space or the disk C: is corrupt.


There are free space. I doubt it’s corrupt. It’s a 860 Evo SSD and a fresh W10 install.

edit: checked logs files and it’s writing


----------



## ManniX-ITA

jfim88 said:


> There are free space. I doubt it’s corrupt. It’s a 860 Evo SSD and a fresh W10 install.


Maybe Onedrive is actively syncing and blocking write to the file sometimes?
Try to move it outside Onedrive's directory.


----------



## sp00n82

jfim88 said:


> What is this error?
> 
> 
> http://imgur.com/a/r178PwO


Yeah, it couldn't write to the log file. It may also be a permission conflict, where another process (OneDrive?) is currently accessing the file and blocking other programs from accessing/writing.


----------



## jfim88

Ah yes. The folder it’s on the desktop and it’s synced with Onedrive.

A question. Now I have CO at All Cores -15. If all core pass tests at Iteration 1, can I stop and increase the CO? Or better test more Iterations?


----------



## Vayne4800

So I returned the negative offset for Core 0 = -15 (where it was causing Doom Eternal reboots). I did some reading around regarding VDDG CCD and IOD and here is what I have (ZenTimings):

Default (auto):
VSOC = 1.075v to 1.0813v
VDDG CCD = 0.9474v
VDDG IOD = 1.0477v

I bumped them up a little to:
VSOC = 1.1000v to 1.1063v
VDDG CCD = 0.9976v
VDDG IOD = 1.0595v

The reboots still happen.

@ManniX-ITA How do you suggest I proceed?

On another note, I apologize that this seems misposting as I am mixing posts/progress of using Core Cycler with trying to achieve stability where Core Cycler is outputting stability so far. Feel free to suggest how I should proceed, post wise.


----------



## ManniX-ITA

Vayne4800 said:


> @ManniX-ITA How do you suggest I proceed?
> 
> On another note, I apologize that this seems misposting as I am mixing posts/progress of using Core Cycler with trying to achieve stability where Core Cycler is outputting stability so far. Feel free to suggest how I should proceed, post wise.


I would investigate the following:

Higher VSOC, try with 1.12V, 1.14V, 1.16V, 1.18V. If it's not helping at 1.18V it's not that
CCD was the primary suspect but at 1000 is already high. Give it a try at 1020, 1040, 1050. Unlikely is that.
IOD as well is already high at 1060. Give a try to 1080 but it's very unlikely.
Test stronger LLC and higher PWM switching frequency. But on some boards setting a fixed value other than Auto is detrimental. Check with benchmarks.
Check the CPU and SOC Over Current and Over Voltage protection settings if you have them, they are often a cause for core instability with aggressive CO counts.
This is the GigaByte Settings for OVP/OCP:










It's almost always helping if set to 400mV from Auto, OCP depends on AGESA/BIOS, could be any of Auto/Normal/Extreme is better. Needs to be tested.

This are the MSI settings:










Here the OVP same 400mV and Current depends, could be Auto or Enhanced. Depends as well from the specific BIOS behavior.


----------



## sp00n82

jfim88 said:


> Ah yes. The folder it’s on the desktop and it’s synced with Onedrive.
> 
> A question. Now I have CO at All Cores -15. If all core pass tests at Iteration 1, can I stop and increase the CO? Or better test more Iterations?


You could try to increase it, e.g. to 20 and then to 25, just to see what's happening (immediate error, reboot, etc). Or let it run over night and see which cores have thrown an error in the morning.
The former can identify the good cores faster. The latter will save you time with the bad cores.


----------



## jfim88

sp00n82 said:


> You could try to increase it, e.g. to 20 and then to 25, just to see what's happening (immediate error, reboot, etc). Or let it run over night and see which cores have thrown an error in the morning.
> The former can identify the good cores faster. The latter will save you time with the bad cores.


Thanks you!
I have my PBO limits at PPT 120 TDC 80 EDC 110 to cut out temps. Was getting 90 degrees with CB23 with default values. No performance loss and 80 degrees now. Does these values affect CO?


----------



## Kurt Krampmeier

Vayne4800 said:


> So I returned the negative offset for Core 0 = -15 (where it was causing Doom Eternal reboots). I did some reading around regarding VDDG CCD and IOD and here is what I have (ZenTimings):
> 
> Default (auto):
> VSOC = 1.075v to 1.0813v
> VDDG CCD = 0.9474v
> VDDG IOD = 1.0477v
> 
> I bumped them up a little to:
> VSOC = 1.1000v to 1.1063v
> VDDG CCD = 0.9976v
> VDDG IOD = 1.0595v
> 
> The reboots still happen.
> 
> @ManniX-ITA How do you suggest I proceed?
> 
> On another note, I apologize that this seems misposting as I am mixing posts/progress of using Core Cycler with trying to achieve stability where Core Cycler is outputting stability so far. Feel free to suggest how I should proceed, post wise.


maybe that core just needs the higher offset. i would try to evaluate it further with corecycler set to just core 0 and let ycruncher run 2-3 times on it. raising those other voltages would only generate unnecessary heat as they dont seem to help. you can possibly get away with -13


----------



## Sleepycat

Vayne4800 said:


> So I returned the negative offset for Core 0 = -15 (where it was causing Doom Eternal reboots). I did some reading around regarding VDDG CCD and IOD and here is what I have (ZenTimings):
> 
> Default (auto):
> VSOC = 1.075v to 1.0813v
> VDDG CCD = 0.9474v
> VDDG IOD = 1.0477v
> 
> I bumped them up a little to:
> VSOC = 1.1000v to 1.1063v
> VDDG CCD = 0.9976v
> VDDG IOD = 1.0595v
> 
> The reboots still happen.
> 
> @ManniX-ITA How do you suggest I proceed?
> 
> On another note, I apologize that this seems misposting as I am mixing posts/progress of using Core Cycler with trying to achieve stability where Core Cycler is outputting stability so far. Feel free to suggest how I should proceed, post wise.


I found the only thing to fix the crash to desktop and spontaneous reboots under heavy AVX2 loads was to use a more positive curve offset. Increasing vSOC, VDDG CCD and VDDG IOD did not do much for me. Why not run -10 which did not crash? You don't gain higher core speeds with -15, just a slightly lower voltage, which increases temperatures only a tiny bit since it is only a -5 difference on a single core.


----------



## Vayne4800

Kurt Krampmeier said:


> maybe that core just needs the higher offset. i would try to evaluate it further with corecycler set to just core 0 and let ycruncher run 2-3 times on it. raising those other voltages would only generate unnecessary heat as they dont seem to help. you can possibly get away with -13





Sleepycat said:


> I found the only thing to fix the crash to desktop and spontaneous reboots under heavy AVX2 loads was to use a more positive curve offset. Increasing vSOC, VDDG CCD and VDDG IOD did not do much for me. Why not run -10 which did not crash? You don't gain higher core speeds with -15, just a slightly lower voltage, which increases temperatures only a tiny bit since it is only a -5 difference on a single core.


Yeah I am fine with my progress but since there were suggestions to try other stuff that could allow me to maintain a higher offset, which passed extensive Core Cycler tests, I can try them. Though -10 is not bad either. It did drop the maximum core clock down to 4975Mhz from 5Ghz (which isn't much).


----------



## Blameless

Sleepycat said:


> You don't gain higher core speeds with -15, just a slightly lower voltage


Generally you do get higher clock speeds, because the curve does not manipulate voltages themselves, it manipulates the frequency curve. Barring other limits, a larger negative value means a higher boost clock.


----------



## jfim88

2 complete iterations passed for all cores with P95 AVX, AVX2 and FMA3 sizes 4-8192.
All Cores -15 CO. Time to test with -20.


----------



## Vayne4800

ManniX-ITA said:


> I would investigate the following:
> 
> Higher VSOC, try with 1.12V, 1.14V, 1.16V, 1.18V. If it's not helping at 1.18V it's not that
> CCD was the primary suspect but at 1000 is already high. Give it a try at 1020, 1040, 1050. Unlikely is that.
> IOD as well is already high at 1060. Give a try to 1080 but it's very unlikely.
> Test stronger LLC and higher PWM switching frequency. But on some boards setting a fixed value other than Auto is detrimental. Check with benchmarks.
> Check the CPU and SOC Over Current and Over Voltage protection settings if you have them, they are often a cause for core instability with aggressive CO counts.
> It's almost always helping if set to 400mV from Auto, OCP depends on AGESA/BIOS, could be any of Auto/Normal/Extreme is better. Needs to be tested.
> 
> Here the OVP same 400mV and Current depends, could be Auto or Enhanced. Depends as well from the specific BIOS behavior.


Alright, I tried VSOC 1.12V and higher CCD. The reboot happened faster. I kept LLC on auto as I didn't know which one to set it on (1-5). Couldn't find any over current and over voltage protection on my Asus Tuf x570. Didn't change the others.

At this point, you are suggesting a number of changes and despite doing overclocking for years, some of the same settings definitions might be different between platforms/CPUs. So went back to previous setting which was mainly defaults and only CO. I did a search around here and it seems most people go through that route with little details and discussions about the settings you recommended me to check. If you have any links for me to do some reading, feel free to share.


----------



## ManniX-ITA

Vayne4800 said:


> I kept LLC on auto as I didn't know which one to set it on (1-5).


ASUS should be 5 the highest, so you should try 3 or 4.



Vayne4800 said:


> If you have any links for me to do some reading, feel free to share.


There are a lot of Youtube videos on these topics, eg.
















If it's crashing faster with higher CCD, try between 950-980mV.
Test with the same VSOC and then also going up.

On ASUS you can try under DIGI+ VRM:

VDDCR CPU/SOC Current Capability to 110-130% (should be the OCP control)
VDDCR CPU/SOC Power Phase Control to Optimized/Extreme
VDDCR CPU/SOC Power Duty Control to Extreme
VDDCR CPU/SOC Switching Frequency to 350


----------



## wuttman

Vayne4800 said:


> Yeah I am fine with my progress but since there were suggestions to try other stuff that could allow me to maintain a higher offset, which passed extensive Core Cycler tests, I can try them. Though -10 is not bad either. It did drop the maximum core clock down to 4975Mhz from 5Ghz (which isn't much).


You need to make sure each core stays at the max boost frequency during the test by lowering temperature. Highest boost is usually most unstable point on the curve.


----------



## Akex

wuttman said:


> You need to make sure each core stays at the max boost frequency during the test by lowering temperature. Highest boost is usually most unstable point on the curve.


I disagree with your statement, the most critical point is when the CPU is idle. It is possible to spend CoreCycler / OCCT all night and eat a reboot in idle.
The SSE is also more of a nuisance than the AVX on the Ryzen 5000 based on tests performed on a big batch of chips.
As it stands, no stress test is totally optimal, all are wobbly at one time or another if we are looking for the perfect optimization of the Curve.
I finished as an example the 5800X currently mounted on a B550 being benchmarked, stable -20 -15 -15 -15 -10 -10 -10 -10 on whatever you want, but reboot on a 110gb copy of a PC to another, crash when I DL RDR2, crash on youtube ...

But in itself your reasoning was not wrong, be careful.

Besides, I would like to take this opportunity to make a request if possible, how can CoreCycler be adjusted so that it benchmarks the entire CPU at 20-25%? @sp00n82


----------



## wuttman

Akex said:


> I disagree with your statement, the most critical point is when the CPU is idle. It is possible to spend CoreCycler / OCCT all night and eat a reboot in idle.


Because it boosts highest at idle, just like I said.


----------



## ManniX-ITA

Akex said:


> I disagree with your statement, the most critical point is when the CPU is idle. It is possible to spend CoreCycler / OCCT all night and eat a reboot in idle.


Yes, @wuttman is right.

When the CPU is idling there's more budget and this will allow the CPU to boost higher.

There are cases where testing with CoreCycler can't help. Because the workload from P95, even with SSE, it's heavy.
You can compensate setting a longer *delayBetweenCores*, default is 15 seconds.
Set 1-3 minutes to allow the low idle temperature and more chances to catch a crash when boosting.
Also be sure *suspendPeriodically* is left at 1 by default.
But still the very light workload boost instability is hard to catch with CC.

You can try looping for a long time, without doing anything, my version of BoostTester.
Unlike the original, does trigger the max boost clock:





BoostTesterMannix.zip







drive.google.com





Generally if you have such frequent crashes with low load there are 2 possible causes.

The most frequent is the boost clock.
Some cores can't just go over a set frequency if the temperature trips over a set point.
Check with boost clock to 0 Mhz and go up until it shows instability.

The second is C States; sometimes must be disabled.
But it's a bad choice, better to try a different BIOS.
Usually there's a reason why it's not stable with C States enabled.
Often can be fixed with Idle Supply power set to Typical.


----------



## sp00n82

Akex said:


> Besides, I would like to take this opportunity to make a request if possible, how can CoreCycler be adjusted so that it benchmarks the entire CPU at 20-25%? @sp00n82


Good question.
Please correct me if I'm wrong, but as far as I understand it, there's no "true" 25% usage of a core. It's either 100% or 0%, and the value we see as e.g. 25% is then just the average over a certain amount of time, the sampling or polling rate.
All instructions are always fully utilizing the core for a certain amount of time (oversimplified by ignoring any power saving features or other advanced methods), so if for example an instruction takes 250 microseconds to complete, and our sampling rate is set to 1 millisecond (which is already pretty fast), we would see a CPU "usage" of 25% over this period of time. But instead what this really means is that the core was used 25% of the time with 100% utilization and 75% of the time with 0%.

Now, the CoreCycler already has the setting suspendPeriodically, which does suspend the stress test for 1 second every 10 seconds (and if your sampling rate was set to 10 seconds, we should see this as 90% "load"). What would be needed to simulate a 25% "load" would be to dramatically increase the frequency of the stress test thread suspension, e.g. divide this in 50ms steps and suspend the stress test for 3 out of 4 steps.
I don't know how feasible this is, and/or how much overhead PowerShell would introduce into this whole procedure. Maybe a direct C++ implementation would be required for this to work reliably.


----------



## Akex

sp00n82 said:


> Good question.
> Please correct me if I'm wrong, but as far as I understand it, there's no "true" 25% usage of a core. It's either 100% or 0%, and the value we see as e.g. 25% is then just the average over a certain amount of time, the sampling or polling rate.
> All instructions are always fully utilizing the core for a certain amount of time (oversimplified by ignoring any power saving features or other advanced methods), so if for example an instruction takes 250 microseconds to complete, and our sampling rate is set to 1 millisecond (which is already pretty fast), we would see a CPU "usage" of 25% over this period of time. But instead what this really means is that the core was used 25% of the time with 100% utilization and 75% of the time with 0%.
> 
> Now, the CoreCycler already has the setting suspendPeriodically, which does suspend the stress test for 1 second every 10 seconds (and if your sampling rate was set to 10 seconds, we should see this as 90% "load"). What would be needed to simulate a 25% "load" would be to dramatically increase the frequency of the stress test thread suspension, e.g. divide this in 50ms steps and suspend the stress test for 3 out of 4 steps.
> I don't know how feasible this is, and/or how much overhead PowerShell would introduce into this whole procedure. Maybe a direct C++ implementation would be required for this to work reliably.


Your explanation is very interesting and probably answers my question. However what I wanted to say is how to make so that the load of the CPU on all the cores is at most between 20 and 25% in a constant and real way. As if for example you were playing a game like Destiny or rocket league, LoL, this kind of load but 100% of the time.
In order to test the whole curve of PBO2 I do not see any other solution.


----------



## slayer6288

what kind of temps do u guys see on ur chips using core cycler with p95 in sse and avx mode? on my 5950x i saw 74c max in sse and 82 max in avx are these high for this? i feel like avx 2 in occt was a lot lower which may be cause of it being all core and not one core going wild also my cb23 temps are only 66 max


----------



## sp00n82

Akex said:


> Your explanation is very interesting and probably answers my question. However what I wanted to say is how to make so that the load of the CPU on all the cores is at most between 20 and 25% in a constant and real way. As if for example you were playing a game like Destiny or rocket league, LoL, this kind of load but 100% of the time.
> In order to test the whole curve of PBO2 I do not see any other solution.


It wouldn't be CoreCycler anymore if it wouldn't, well, cycle through the cores anymore. 😅

I don't know the behavior of the games you mentioned, but if you manually set Prime95 to a lower number of worker threads than the available cores, the Windows scheduler will automatically and dynamically choose which cores to use, e.g. by setting it to one worker thread it will switch back and forth between your best cores.
The problem with this is that there's no easy way to tell which core then had thrown an error.


----------



## Vayne4800

slayer6288 said:


> what kind of temps do u guys see on ur chips using core cycler with p95 in sse and avx mode? on my 5950x i saw 74c max in sse and 82 max in avx are these high for this? i feel like avx 2 in occt was a lot lower which may be cause of it being all core and not one core going wild also my cb23 temps are only 66 max


I have similar temps with my OC'ed 5900x using Arctic Freezer II 280mm.


----------



## carlosedt

I tried CoreCycler on my first ryzen 9 5900x and I got errors using stock settings (I have a Gigabyte Aorus Master x570) since I bought it on Amazon I requested a replacement and was the same thing with that new processor so maybe the settings are too heavy for some cores?


----------



## MikeS3000

carlosedt said:


> I tried CoreCycler on my first ryzen 9 5900x and I got errors using stock settings (I have a Gigabyte Aorus Master x570) since I bought it on Amazon I requested a replacement and was the same thing with that new processor so maybe the settings are too heavy for some cores?


That's bad luck. Do you have another mobo that you can test the 2nd CPU in just to rule out the mobo as the culprit? There is no such thing as too heavy of settings for any stock CPU. If the CPU can't handle it, then it is defective and should be replaced.


----------



## sp00n82

carlosedt said:


> I tried CoreCycler on my first ryzen 9 5900x and I got errors using stock settings (I have a Gigabyte Aorus Master x570) since I bought it on Amazon I requested a replacement and was the same thing with that new processor so maybe the settings are too heavy for some cores?


Check if the stock settings on your motherboard actually disable or enable PBO. PBO is not covered by the warranty, so it's not guaranteed to function with the default Curve Optimizer setting, and you may need to assign a positive value for it to work.

And also remember that unstable RAM settings will cause errors in Prime95 as well.


----------



## Netarangi

Where will the error be reported if one of my cores fails? I’ve set them all to -15 at the moment, do I just let it run and does it eventually give an output or does it run until I stop it?

Thanks for patience, I’m new to curve optimiser.


----------



## Akex

the log is in the corecycler folder as well as in the powershell window, you will see when this happens.
-15 all core to start is maybe too aggressive for your best cores, I recommend you to start with -10 and again ... The hardest part is not identifying the defective core under heavy load, but idle, at rest, you risk reboots


----------



## boldenc

I am having hard time passing FFT 720k when testing my CO with CoreCycler so I suggest who ever looking for better stability to test custom FFT with CoreCycle in # Prime95 specific settings and edit FFTSize = 720-720
I have passed the custom presets including Moderate, Heavy, HeavyShort and Huge for hours fine. But this specific FFT 720k will fail on all cores and I had to lower my offset to pass it for 1 hour each core.
And the best core couldn't pass it till I used 0 offset, this core still boosts to 5GHz with - 0 CO but was hoping for better offset to use but guess not the best luck.


----------



## cyberloner

carlosedt said:


> I tried CoreCycler on my first ryzen 9 5900x and I got errors using stock settings (I have a Gigabyte Aorus Master x570) since I bought it on Amazon I requested a replacement and was the same thing with that new processor so maybe the settings are too heavy for some cores?


some core are boost too high by the motherboard....
if using heatsink cooling... tweak via curve and positive some fail core ....
if using aio... set permanent core speed and voltage as high as stable you can....... it will powerful than all boost stuff...


----------



## Sam64

cyberloner said:


> if using aio... set permanent core speed and voltage as high as stable you can....... it will powerful than all boost stuff...


I don't think so. Mora420 Custom WC here and I'm still getting optimal results with PBO/CO only.

With PBO/CO Mainboard-Limits:










With Allcore 47/46:










So i get only about 3% more MC-Score with Allcore setting while getting 6-7% better SC Score with PBO/CO only.


----------



## Netarangi

Should I be pushing each core to the limit? If it errors and I set it back one and then it’s fine, is that the final number? Or is it safer to reduce it by 2?


----------



## boldenc

Netarangi said:


> Should I be pushing each core to the limit? If it errors and I set it back one and then it’s fine, is that the final number? Or is it safer to reduce it by 2?


I would say by 1 if you are looking for the best possible results.
And yes just offset by -1 can can make things stable or unstable.


----------



## Blameless

Unlike most stability tests, I find it to be best to use CoreCycler when the CPU is as cold as practical, to maximize the boost clocks and catch instabilities that would otherwise only be present at idle. Running the test at night and with maximum fan speeds can help find weak cores faster. You can always do some higher temp stress testing as well, to cover all bases.

It should also be kept in mind that the offset on one core can also influence the stability of neighboring cores. For example, these were my CoreCycler results on one of my 5800Xes when starting with an offset of -30 and adding to it any time a core failed, until all were stable for at least ten iterations:

-25, +6, -12, -7, +3, -12, -7, -3

And when I reevaluated the curves, adjusting neighboring cores first, to see if they allowed a previously failed offset on one core to be stable, I wound up with these:

-30, -2, -14, -22, -6, -13, -7, -5

Also, the core numbering within a fully intact Vermeer CCD is laid out like this, with the "|" being the center of the CCD where the L3 cache is:

0 | 1
2 | 3
4 | 5
6 | 7

Core 1, for example, would tend to be most influenced by core 3 and 0, then 2, in roughly that order of precedence.

Obviously, fully tuning individual curves until all are at their mutually strongest negative offset, where they are as stable as can be in all things, and have no more headroom to take advantage of, can take quite a bit of time.


----------



## PJVol

Blameless said:


> Core 1, for example, would tend to be most influenced by core 3 and 0


Influenced in what way? If you mean thermally, core0 doesn't affect core1 much (if at all) due to them being split by a huge L3 chunk.


----------



## Blameless

PJVol said:


> Influenced in what way? If you mean thermally, core0 doesn't affect core1 much (if at all) due to them being split by a huge L3 chunk.


Mostly electrically, I assume. A core doing work pulls a lot of current, which would introduce jitter and droop. The LDOs that tune per-core voltage are surely fast, but not instantaneous. The main vcore and PLL must be considerably slower, being fed by off-chip switching regulators. I also imagine there is at least some degree locality to this, no matter how well managed the on-chip power distribution is.

I'm not a semiconductor engineer and I'm not privy to any non-public AMD design documentation. All I know is that I can often induce instability in one core by manipulating the curve of the others, and this effect appears to be stronger with neighboring cores, even those that are separated by L3 slices.


----------



## PJVol

Blameless said:


> The LDOs that tune per-core voltage...


Just out of curiosity, is it so obvious, considering


Blameless said:


> I'm not privy to any non-public AMD design documentation


? 

As to the electrical part, that's not I'm very good at, without knowing, when, how, and to what extent (if at all) dldo's are participating in CPB workflow, I don't think any conclusions can be drawn regarding core's interactions.
Anyway, happy to be enlightened.


----------



## Blameless

PJVol said:


> Just out of curiosity, is it so obvious, considering
> 
> ?


That Zen has per core LDOs is public knowledge and has been all over AMD's slides and presentations since 2017.

Some examples:


















https://pc.watch.impress.co.jp/docs/column/kaigai/1043349.html

[QUOTE="PJVol, post: 28849421, member: 622816"]As to the electrical part, that's not I'm very good at, without knowing, when, how, and to what extent (if at all) dldo's are participating in CPB workflow, I don't think any conclusions can be drawn regarding to core's interactions.
Anyway, happy to be enlightened.
[/QUOTE]

These are inferences that make sense to me given the observable results and what information is on hand. I wouldn't take my very tentative conclusions as gospel, I just don't have any better explanation.


----------



## PJVol

Yes, I've seen those and they(ldo's) was mentioned in cezanne slides as well.
I thought this was the case, until have been convinced in the opposite (by some knowleagable people), at least for the ryzen desktop series specifically.
For example:

__
https://www.reddit.com/r/Amd/comments/kuy8wa/_/givj1df

there were others, claiming basically the same.

On the other side, something's might have changed since then, if dldo's supposedly just need to be activated in smu firmware, to start working, and assuming they're physically there.


----------



## Milkysunshine

I posted this in another thread, but it should probably go here, so here was my brainstorming while laying in bed this morning.

Out of curiosity, When I updated to the latest beta bios for the dark hero viii, I left pbo curve completely stock. I did a mild +50 to the autoOC, set my power limits manually (220,160,155), then ran through about 10 hours of core cycler. Core 14 failed even with zero offset. That got me thinking... Maybe our methodology for testing "stability" using core cycler on EVERY core is flawed. There isn't a real life scenario where single threaded loads are going to be stuck blasting a core on the second ccd for an extended period of time, while the preferred cores on the first ccd are doing nothing. I found that 10 threads in prime 95 was enough to just start using core 14 fully. 9 threads dropped core 14. 14 is the lesser 'preferred core' on the second ccd with core 10 being the primary preferred core on that ccd. I ran 10 threads of the same 720k FFT for hours without error. So, yes. It is unstable under 'worst case scenario', but unfortunately, that scenario will most likely never, ever happen.

What I suggest as a better real world test is have a program like core cycler start out with a single core workload, and go all the way up to the full 16 core workload in stages. Instead of assigning affinity to each core specifically, Let the CPU handle the distribution of the load. This way, we're emulating a true possible test from single thread, all the way to full 32 thread load (on the 5950x, obviously). One issue I see right away is tracking which prime95 worker actually errors. I'm not entirely sure the logical way to tackle the tracking of core usage. Maybe have the app do a test run first monitoring core usage per thread count and create a probable order of core preference, then use that order to add on threads one at a time at certain time intervals? The app could even do a more real world style test bouncing from higher thread loads to lower thread loads via a configuration flag.

I feel like the current method of using you're amazing script could be leaving a lot of performance on the table in many situations.


----------



## sp00n82

Milkysunshine said:


> I posted this in another thread, but it should probably go here, so here was my brainstorming while laying in bed this morning.
> 
> Out of curiosity, When I updated to the latest beta bios for the dark hero viii, I left pbo curve completely stock. I did a mild +50 to the autoOC, set my power limits manually (220,160,155), then ran through about 10 hours of core cycler. Core 14 failed even with zero offset. That got me thinking... Maybe our methodology for testing "stability" using core cycler on EVERY core is flawed. There isn't a real life scenario where single threaded loads are going to be stuck blasting a core on the second ccd for an extended period of time, while the preferred cores on the first ccd are doing nothing. I found that 10 threads in prime 95 was enough to just start using core 14 fully. 9 threads dropped core 14. 14 is the lesser 'preferred core' on the second ccd with core 10 being the primary preferred core on that ccd. I ran 10 threads of the same 720k FFT for hours without error. So, yes. It is unstable under 'worst case scenario', but unfortunately, that scenario will most likely never, ever happen.
> 
> What I suggest as a better real world test is have a program like core cycler start out with a single core workload, and go all the way up to the full 16 core workload in stages. Instead of assigning affinity to each core specifically, Let the CPU handle the distribution of the load. This way, we're emulating a true possible test from single thread, all the way to full 32 thread load (on the 5950x, obviously). One issue I see right away is tracking which prime95 worker actually errors. I'm not entirely sure the logical way to tackle the tracking of core usage. Maybe have the app do a test run first monitoring core usage per thread count and create a probable order of core preference, then use that order to add on threads one at a time at certain time intervals? The app could even do a more real world style test bouncing from higher thread loads to lower thread loads via a configuration flag.
> 
> I feel like the current method of using you're amazing script could be leaving a lot of performance on the table in many situations.


As you've said, there's no way to reliably track which core threw an error in Prime95 if you run multiple threads and only have the log file available to check.
You'd need to modify the source code of Prime95 to be able to do so, and if you let Windows itself handle the core assignment, probably even this wouldn't be enough.

And while I concur that testing every single core for its max boost clock stability is a pretty uncommon usage scenario in the real world, personally I like to be on the safe side, where I know that none of cores will throw an error on me.

Theoretically you could just exclude the worse cores from the testing process, when you feel they'll be never used anyway and focus more on the better ones. This could at least save you some time.


----------



## nada324

I dont know whats happening, can be windows installation issue?

I tried even with pbo auto and still get those errors, i get no whea errors so i dont think it can be realted to FCLK,

They just say ILEGAL SUMOUT.


----------



## Tzuyu

Ive been using this for a bit now and am I correct in assuming we should run the Moderate, HeavyShort and Heavy tests for CoreCycler? Default is set to Huge. (Core 0 and 1 threw errors in Huge when -5 and -10, so they now at -0 and -5) The rest chug along fine at -20 seemingly. in all 4 tests.

Any ideas on what tests one can do to simulate idle workloads? CPU ID 0 (and its the only one, ever) causes WHEA bus/interconnect crashing often in idle just opening a chrome tab or doing chrome browsing while listening to music through spotify etc at complete random, if I change cycler to anything lower than -0 on that core.


----------



## sp00n82

nada324 said:


> I dont know whats happening, can be windows installation issue?
> 
> I tried even with pbo auto and still get those errors, i get no whea errors so i dont think it can be realted to FCLK,
> 
> They just say ILEGAL SUMOUT.
> 
> View attachment 2522417


ILLEGAL SUMOUT seems to be a floating point error, but a rather rare one in Prime95. Make sure your other components, especially the RAM is running stable. Also try to disable PBO (and not just Auto) and see if this error still shows up.
You can also check the logs and try to determine for which FFT sizes these errors show up frequently, and then limit the test to this range to speed things up a little.


@Tzuyu
You will want to run all of the FFT sizes eventually.


----------



## bebius

Posting my numbers that needs more testing just to confirm that the best core may indeed need a positive number:
23, 6, +7, 14, 22,16 @+50MHz - PPT 95W
I have made some changes and improved the airflow, so I think I can increase the power a little. Could that disrupt my curves? I think I could sustain higher clocks for more that way.


----------



## Milkysunshine

bebius said:


> Posting my numbers that needs more testing just to confirm that the best core may indeed need a positive number:
> 23, 6, +7, 14, 22,16 @+50MHz - PPT 95W
> I have made some changes and improved the airflow, so I think I can increase the power a little. Could that disrupt my curves? I think I could sustain higher clocks for more that way.


I have 2 cores that need a positive offset to pass 720k. One of which is a the second preferred core. 

If you aren't hitting thermal limiting, you can definitely add more power until you come close to it.


----------



## bebius

While finetuning and testing the co, I noticed that 4 of my 6 cores failed during a test at the "Large" size (p95 fft, "All" sizes setting). I have tested my ram oc with anta extreme and usmus configs, along with hci 1500% coverage. Due to the corecycler failing at the "Large" setting, which is suggested to be used for ram testing, I was wondering if I should check my ram again with the cpu @ stock.


----------



## Luggage

I’d do the opposite - set your ram to stock/very safe - and run CS. Huge is the default setting because it runs with the highest boost.


----------



## sp00n82

You can do either. And probably should.
That being said, testing out the limits of the CPU should be done without any RAM overclock anyway, to eliminate any possible interferences and other possible sources of errors. And vice-versa, RAM overclock testing without any CPU OC.

But in the end you'll have to test both OCs in combination as well. A RAM overclock also puts more stress on the CPUs internal memory controller (IMC), which might be enough to tip a once stable CPU overclock suddenly into the unstable region.


----------



## bebius

I guess for my case, as I have already tested my ram oc thoroughly, it's most efficient to keep testing the cpu curve as it is, and this way the combination will be tested also.
I can test the ram alone with prime95 though, with stock cpu, as it was the test I least used. What's the best p95 settings for ram stress testing?


----------



## TimeDrapery

Spoiler






bebius said:


> I guess for my case, as I have already tested my ram oc thoroughly, it's most efficient to keep testing the cpu curve as it is, and this way the combination will be tested also.
> I can test the ram alone with prime95 though, with stock cpu, as it was the test I least used. What's the best p95 settings for ram stress testing?






@bebius 

Uh wut, no ... That's the absolute least efficient way to do this as, like you'd said, you've encountered errors during testing with FFT sizing that's often used to pinpoint DRAM issues yet you're testing your CPU for stability when configured with the settings you've entered into Curve Optimizer

This means you're unable to pinpoint the *proximate* cause of your errors as you've got two bits of your system (truly more considering how it all works together) running outside of spec

Do what you like, but you're most assuredly not working in an efficient manner


----------



## ManniX-ITA

bebius said:


> Due to the corecycler failing at the "Large" setting, which is suggested to be used for ram testing, I was wondering if I should check my ram again with the cpu @ stock.


I would test RAM settings with TM5. You said you tested it already both with anta and 1usmus config. 
Was it with the CO settings you are now testing with CoreCycler?
Cause if you did already, I see no point in testing again.
Probably a count issue. 
Large and Huge will make boost the core very high in frequency.
Set a less negative count for those cores and see if they fail again.


----------



## TimeDrapery

Spoiler






ManniX-ITA said:


> I would test RAM settings with TM5. You said you tested it already both with anta and 1usmus config.
> Was it with the CO settings you are now testing with CoreCycler?
> Cause if you did already, I see no point in testing again.
> Probably a count issue.
> Large and Huge will make boost the core very high in frequency.
> Set a less negative count for those cores and see if they fail again.






@ManniX-ITA 

Yes, it is _probably_ a Count error

Regardless, it's inefficient to attempt to diagnose the proximate cause of the error without doing away with the memory OC... Especially when it's as simple as saving a profile and reverting the memory to the standard spec


----------



## ManniX-ITA

TimeDrapery said:


> Regardless, it's inefficient to attempt to diagnose the proximate cause of the error without doing away with the memory OC...


Well, he said he's more than confident the RAM OC is 100% safe.
I'd prefer to run CC to test the counts with it instead of safe settings.
Ryzen IPC is highly dependent on memory so there's a chance the safe settings could let an unstable count slip away and give problems when the OC profile is set back.
It's all about being confident the memory works properly. A mistake there can be costly in time.


----------



## TimeDrapery

Spoiler






ManniX-ITA said:


> Well, he said he's more than confident the RAM OC is 100% safe.
> I'd prefer to run CC to test the counts with it instead of safe settings.
> Ryzen IPC is highly dependent on memory so there's a chance the safe settings could let an unstable count slip away and give problems when the OC profile is set back.
> It's all about being confident the memory works properly. A mistake there can be costly in time.






@ManniX-ITA 

That's all very true and I do agree with you, I do the same myself with regards to stability testing using CC as I'm aware of what it means to conduct testing as you've described

Considering the poster spoke about being unsure of what settings are "best" to test DRAM stability I was responding with that in mind...

If you're (directed at the user asking the question, not you @ManniX-ITA) unsure of why certain FFT sizes stress one component less/more than another than likely, in my opinion, you're not entirely sure your memory OC is actually stable and, rather, you're guessing it is because you've done what you've seen others do on a forum/Reddit

In that case, I'd rather see the user revert the memory OC, test the CPU (if it passes... great!), and then restore it and try again with the memory OC intact

Everyone's got their own idea of "stable" but, unfortunately, it's looked at as a static goal to be attained and this means people waste time looking to do one thing or another when the simplest answer is, most often, the easiest and most efficient


----------



## bebius

Isn't it better to oc the ram first and then, on top of that, oc and stress test the CPU? If you do each one separately, how can you point out the cause of error when you test the combined oc?
Anyway, I tested my ram again with p95 (custom settings: 13/16gb and large sizes) and it was error free after 9h so I feel it's totally stable.
Back to the curve optimiser now.


----------



## TimeDrapery

Spoiler






bebius said:


> Isn't it better to oc the ram first and then, on top of that, oc and stress test the CPU? If you do each one separately, how can you point out the cause of error when you test the combined oc?
> Anyway, I tested my ram again with p95 (custom settings: 13/16gb and large sizes) and it was error free after 9h so I feel it's totally stable.
> Back to the curve optimiser now.






@bebius

Like I'd initially told you, do as you like...

You're talking about doing something different from troubleshooting an error ... You're talking about the order with which one proceeds to overclock different components which, truly, doesn't make a lick of difference nor does it have anything to do with determining the proximate cause of an error you encounter during stability testing

I normally proceed with whatever one is most interesting to me first, save that profile on the BIOS, load "Optimized Defaults", configure the system as I would were I to proceed without OCing, OC whatever component I'm most interested in next, and then put it all together and stability test/troubleshoot from that point

What I'm telling you is that, regardless of how you feel, until you isolate the suspects you're not going to definitively know what caused the error and (should you never encounter it again) you'll never know...

That's not that big of a deal at all, until it causes you headaches when you feel like you're all done and you encounter crashes or something else of that nature

Of course, I also don't like my food to touch when it's all together on my dinner plate so don't listen to me as I'm obviously overly concerned with what's causing what to happen in my system

*Don't take this personally, I don't know you and I really have no vested interest in the performance of your system... I do have an interest in this resource being (somewhat) free of technical inaccuracies* due to individuals that do know what they're doing contributing more of what works for them with their high levels of experience as opposed to what should work most of the time for those that are learning

*In summation*, OC whatever component you're most interested in first and proceed in whatever order you prefer as it makes no difference but certainly isolate the components when troubleshooting errors that occur during stability testing


----------



## CrustyJuggler

Does the AIDA64 message, _Aida64 doesn't like running the stress test on the first thread of Core 0.
Setting it to thread 2 of Core 0 instead (Core 0 CPU 1)._ Indicate I have an issue or is this normal? CoreCycler doesn't flag it as an error.


----------



## TimeDrapery

Spoiler






CrustyJuggler said:


> Does the AIDA64 message, _Aida64 doesn't like running the stress test on the first thread of Core 0.
> Setting it to thread 2 of Core 0 instead (Core 0 CPU 1)._ Indicate I have an issue or is this normal? CoreCycler doesn't flag it as an error.






@CrustyJuggler 

That's a rather interesting message... Do you have SMT disabled? It's also interesting that it calls it "Thread 2" but yet "Core 0" 😂😂😂😂😂... Good one, post a screenshot of the message please


----------



## CrustyJuggler

TimeDrapery said:


> @CrustyJuggler
> 
> That's a rather interesting message... Do you have SMT disabled? It's also interesting that it calls it "Thread 2" but yet "Core 0" 😂😂😂😂😂... Good one, post a screenshot of the message please


SMT is enabled. I'm running a 5600x. I ran the test for 1 minute per core to grab the screenie, normally its AUTO. It does this for both the CACHE and RAM tests. I haven't loaded defaults to see if it resolves the issue, I'll give that as go next. I did notice a post on page one that has this same message, but no indication if it's an issue or just a feature.


----------



## CrustyJuggler

CrustyJuggler said:


> SMT is enabled. I'm running a 5600x. I ran the test for 1 minute per core to grab the screenie, normally its AUTO. It does this for both the CACHE and RAM tests. I haven't loaded defaults to see if it resolves the issue, I'll give that as go next. I did notice a post on page one that has this same message, but no indication if it's an issue or just a feature.
> 
> View attachment 2523887


BIOS Default resulted in no change


----------



## TimeDrapery

CrustyJuggler said:


> SMT is enabled. I'm running a 5600x. I ran the test for 1 minute per core to grab the screenie, normally its AUTO. It does this for both the CACHE and RAM tests. I haven't loaded defaults to see if it resolves the issue, I'll give that as go next. I did notice a post on page one that has this same message, but no indication if it's an issue or just a feature.
> 
> View attachment 2523887


@CrustyJuggler 

Ohhhhh! That's too funny, I'd thought you'd meant AIDA64 shot that message out, not the script

I don't think it's an error so much as an informational notice, I'm sure the user @sp00n82 would be able to better inform you of why it might feel you need to know about this


----------



## sp00n82

Yeah, I noticed that during development. When I tried setting the process affinity to the first thread of the first core, Aida64 would basically stop doing anything at all. It seems that the first CPU core it sees is reserved for the "main" program (Aida64 is split into two processes, one for the GUI etc and one for the actual stress test), and if you try to run both on the same thread, bad things happen.
Therefore I switched to the second "CPU" (which in case with SMT enabled is just the second thread on the first core) so that Aida64 stays happy. The switch itself shouldn't affect stability testing.
When SMT is disabled though, as far as I can remember I had to completely skip core 0 then.


----------



## bebius

When an error is logged while running p95, we get the following output.


Code:


ERROR MESSAGE: FATAL ERROR: Rounding was 0.5, expected less than 0.4
ERROR: The last *passed* FFT size before the error was: 2048K
ERROR: Unfortunately FFT size fail detection only works for Smallest, Small or Large FFT sizes.
                 + The max FFT size was outside of the range where it still follows a numerical order
                 + The selected max FFT size:         32768
                 + The limit for the numerical order: 8192
                 + The last 5 entries in the results.txt:
                 + - [Line 2223] Self-test 1280K passed!
                 + - [Line 2224] [Mon Sep  6 11:57:24 2021]
                 + - [Line 2225] Self-test 2048K passed!
                 + - [Line 2226] FATAL ERROR: Rounding was 0.5, expected less than 0.4
                 + - [Line 2227] Hardware failure detected running 1344K FFT size, consult stress.txt file.

Isn't the FFT size properly detected, given that it's reported in the last line?
It's also reported in the p95 log:


Code:


FATAL ERROR: Rounding was 0.5, expected less than 0.4
Hardware failure detected running 1344K FFT size, consult stress.txt file.

Why does the warning about the size fail detection have to be printed in this case?


----------



## TimeDrapery

sp00n82 said:


> Yeah, I noticed that during development. When I tried setting the process affinity to the first thread of the first core, Aida64 would basically stop doing anything at all. It seems that the first CPU core it sees is reserved for the "main" program (Aida64 is split into two processes, one for the GUI etc and one for the actual stress test), and if you try to run both on the same thread, bad things happen.
> Therefore I switched to the second "CPU" (which in case with SMT enabled is just the second thread on the first core) so that Aida64 stays happy. The switch itself shouldn't affect stability testing.
> When SMT is disabled though, as far as I can remember I had to completely skip core 0 then.


@sp00n82 

Righteous! Thanks so much for the explanation, that's really helpful


----------



## sp00n82

bebius said:


> When an error is logged while running p95, we get the following output.
> 
> 
> Code:
> 
> 
> ERROR MESSAGE: FATAL ERROR: Rounding was 0.5, expected less than 0.4
> ERROR: The last *passed* FFT size before the error was: 2048K
> ERROR: Unfortunately FFT size fail detection only works for Smallest, Small or Large FFT sizes.
> + The max FFT size was outside of the range where it still follows a numerical order
> + The selected max FFT size:         32768
> + The limit for the numerical order: 8192
> + The last 5 entries in the results.txt:
> + - [Line 2223] Self-test 1280K passed!
> + - [Line 2224] [Mon Sep  6 11:57:24 2021]
> + - [Line 2225] Self-test 2048K passed!
> + - [Line 2226] FATAL ERROR: Rounding was 0.5, expected less than 0.4
> + - [Line 2227] Hardware failure detected running 1344K FFT size, consult stress.txt file.
> 
> Isn't the FFT size properly detected, given that it's reported in the last line?
> It's also reported in the p95 log:
> 
> 
> Code:
> 
> 
> FATAL ERROR: Rounding was 0.5, expected less than 0.4
> Hardware failure detected running 1344K FFT size, consult stress.txt file.
> 
> Why does the warning about the size fail detection have to be printed in this case?


Oh, so he did already add the message, I must have missed it!
This was specifically requested by me in the Prime95 forums, and apparently he added it without me noticing it. 🙈


----------



## ioannis91

Hello! I see that huge FFTs is the default, does that mean it's the best setting for error detection or is it better to alternate between the FFT sizes? I am planning to run the script overnight for the next 10 or 15 days. Should I also alternate between the instruction sets?


----------



## TimeDrapery

ioannis91 said:


> Hello! I see that huge FFTs is the default, does that mean it's the best setting for error detection or is it better to alternate between the FFT sizes? I am planning to run the script overnight for the next 10 or 15 days. Should I also alternate between the instruction sets?


Huge FFT sizes will do well for you when tuning but you'll eventually want to run all the FFT sizes... Instructions are your own poison to choose, I'd run through them all but you may not feel the need to depending on how things go and what you use your system to do


----------



## ioannis91

I am testing for about 12 hours now, all cores on -30 and only once I got an error on one core, put it on -28 and not getting any more errors since. So 2 things might be happening. Either I got so lucky or I am doing something wrong. I am guessing it needs more testing but I am surprised that it is not an error-fest at such low curve counts. Interestingly enough, I run the blender benchmark and it failed. Not reboot or WHEA, just stops and brings up an error message. Without curve optimizer it runs just fine. So obviously something is wrong with the curve but core cycle can't find it (yet?).


----------



## ManniX-ITA

ioannis91 said:


> I am testing for about 12 hours now, all cores on -30 and only once I got an error on one core, put it on -28 and not getting any more errors since. So 2 things might be happening. Either I got so lucky or I am doing something wrong. I am guessing it needs more testing but I am surprised that it is not an error-fest at such low curve counts. Interestingly enough, I run the blender benchmark and it failed. Not reboot or WHEA, just stops and brings up an error message. Without curve optimizer it runs just fines. So obciously something is wrong with the curve but core cycle can't find it (yet?).


Indeed, not yet.
You can be sure it works only after you have tested all the FFT with SSE/AVX/AVX2.
Also I'd recommend to test one core at a time, even if it takes a lot of time.
Set in config.ini:

runtimePerCore = auto

This will force testing ALL the FFT sizes.
If you already went through a cycle for Huge and want to be sure go straight for:

FFTSize = All

Properly testing means you have to close everything in background and not use the PC while CC is running.
If that's too much one browser open with one tab only it's really the worst you should do. Risky anyway.
Otherwise leave it running during night, best thing.

If not already exhausted and traumatized you can then do the same changing mode first to AVX and AVX2:

mode = AVX

Blender failing probably means AVX or AVX2 is unstable.
But you'll probably will catch the unstable core earlier running all SSE.

There's also the expected runtime for All FFT in the different modes for each mode in the config:

*Prime95 "All": 4K to MAX - [SSE] ~40-65 Minutes <|> [AVX] ~92-131 Minutes <|> [AVX2] ~102-159 Minutes*

Just to give an idea how much it would take for each core.


----------



## ioannis91

So as I can understand runtime on auto, all FFTs and starting from -30 on all cores is the best way. It will take the most time but you cover all cases and you can be sure that you will find the best curve. At least I have a 5600X, so only 6 cores to test..


----------



## mongoled

@ioannis91 
You not running any "Boost Override" increment ??


----------



## ManniX-ITA

There's another testing strategy but is risky; means accepting that the CPU could end up being unstable.
It's more suited for those having troubles with the secondary cores not being able to run at a low CO count.
This means not only these cores will be slower in single thread but will also impact the overall all-core performances.

It's based on the fact that the Windows scheduler is pretty good at starting and redirecting high load to the best cores.
This means that is really unlikely that a secondary core runs a high load without anything running already on the best cores.

The strategy is to identify the 3 best cores as in the HWInfo screenshot below:










Then test with CC to find the best CO count for 2, 5, 1 running it on a single core.

To find the CO count for the rest of the cores, run CC on the secondary core and in parallel on the 3 best cores.
So to test Core 7 use the following config.ini option (HWInfo cores are +1):

coreTestOrder = 6, 1, 4, 0

If you want to reduce the chances of failures you can reduce the parallel cores under test:

coreTestOrder = 6, 1, 4
coreTestOrder = 6, 1 

It's risky and I wouldn't recommend it especially for 2CCDs as the scheduler sometimes doesn't move high load processes to the 1st CCD.
But it's a matter of choice


----------



## ioannis91

Thanks but I feel more confident sticking with auto runtime and all FFTs. It takes 40 minutes on SSE for each core. 
No, I am not running any autoOC offset.


----------



## ManniX-ITA

ioannis91 said:


> Thanks but I feel more confident sticking with auto runtime and all FFTs. It takes 40 minutes on SSE for each core.
> No, I am not running any autoOC offset.


If you have any intention to use an offset do it now cause it will probably change the test results.
I thought anyone with a 5600x is using +200


----------



## ioannis91

ManniX-ITA said:


> If you have any intention to use an offset do it now cause it will probably change the test results.
> I thought anyone with a 5600x is using +200


I am planning on finding the best curve first and then set offset to, let's say, 50MHz and see if all cores can hit it (effective clock) without streaching and check for stability. If it passes/fails then I move the offset 25Mhz up/down and check again.


----------



## mongoled

ManniX-ITA said:


> If you have any intention to use an offset do it now cause it will probably change the test results.
> I thought anyone with a 5600x is using +200


My thoughts exactly, hence the question and yes, little point doing this if you are not maxing the override ...


----------



## bebius

mongoled said:


> My thoughts exactly, hence the question and yes, little point doing this if you are not maxing the override ...


I also backed up from my initial +200 setting as the counts were getting smaller and smaller. But then they kept getting smaller anyway 😄 So back to +200 now.


----------



## mongoled

bebius said:


> I also backed up from my initial +200 setting as the counts were getting smaller and smaller. But then they kept getting smaller anyway 😄 So back to +200 now.


😂 😂

I also work "backwards"

Jump in to what I want to achieve (which is usually more than thats achievable) then scale it down ....


----------



## ioannis91

The thing with autoOC is that you need to have negative curve offset as well, at least for the bad cores, to achieve the offset in the effective clock. You can't just throw +200 and that's it. You may see 4850 (in the case of the 5600X) in MSI Afterburner overlay but that does not mean anything. It has to be 4850 in effective clock. So for a core to achieve +200 you may need to go so negative on the curve that is no longer stable. So you essentially need to find this balance where all cores do the effective clock with offset and are stable..


----------



## ManniX-ITA

ioannis91 said:


> The thing with autoOC is that you need to have negative curve offset as well, at least for the bad cores, to achieve the offset in the effective clock. You can't just throw +200 and that's it. You may see 4850 (in the case of the 5600X) in MSI Afterburner overlay but that does not mean anything. It has to be 4850 in effective clock. So for a core to achieve +200 you may need to go so negative on the curve that is no longer stable. So you essentially need to find this balance where all cores do the effective clock with offset and are stable..


You should not check the Effective Clock in an AB overlay 
Effective Clock is calculated over CPU Load.
It will only equal the Clock if the load is 100%; which rarely happens while gaming.
You need to check it with a steady 100% load.
Check with HWInfo while running CC and P95 all-core.

If you get a big skew from the Clock could be many things.
Maybe PBO limits too strict or voltages too low.

In general is better to have a higher Boost Clock with lower counts than lower Boost Clock with awesome negative counts.
The Boost Clock has also an effect on the average all-core clock, not only single thread.


----------



## ioannis91

Yeah I know you have to check the effective clock in hwinfo. What I am saying is that people just put +200 and see 4850 in games and think their CPU hits 4850, but if you run a single core test the effective clock is way lower..


----------



## mongoled

ioannis91 said:


> Yeah I know you have to check the effective clock in hwinfo. What I am saying is that people just put +200 and see 4850 in games and think their CPU hits 4850, but if you run a single core test the effective clock is way lower..


Those people shouldnt be overclocking

🤣 🤣


----------



## ManniX-ITA

ioannis91 said:


> Yeah I know you have to check the effective clock in hwinfo. What I am saying is that people just put +200 and see 4850 in games and think their CPU hot 4850, but if you run a single core test the effective clock is way lower..


That's because it's the Max Boost Clock, not the Sustained Boost Clock.
A good reference, I take a note for each core what could peak when running it, is the clock while running CC with SSE/Huge.
This will tell you how fast with a serious workload the core can boost sustained.
Otherwise to check the Max Boost Clock use this and check with HWInfo:






BoostTesterMannix.zip







drive.google.com


----------



## ioannis91

Thanks guys! I will make two curves, one prioritizing negative counts and one prioritizing autoOC and see which I get the best results with.


----------



## mongoled

ioannis91 said:


> Thanks guys! I will make two curves, one prioritizing negative counts and one prioritizing autoOC and see which I get the best results with.


Just a little confused with your quoting this "autoOC" .

Is this what "Boost Override" is named in your BIOS ?

As its not really an auto overclock feature, more like a way to increase the max limit any CPU core can reach.

I know you have understood this, just strange to call it "autoOC" ...


----------



## ioannis91

I've read it autoOC somewhere and stuck with it I guess. Yes Boost Override is the right term.


----------



## ioannis91

Let's say I run all FFTs on auto runtime and 2 cores fail so I increase the count by 1. Should I run CC only for those two cores or for all of them again? I am thinking of running only for those that failed, if one of them fails again, then increase the count and test it again. When it passes then I switch to AVX for all cores.


----------



## ManniX-ITA

ioannis91 said:


> Let's say I run all FFTs on auto runtime and 2 cores fail so I increase the count by 1. Should I run CC only for those two cores or for all of them again? I am thinking of running only for those that failed, if one of them fails again, then increase the count and test it again. When it passes then I switch to AVX for all cores.


Only those failing until they are passing.
But no, once the last one passed, you have to make another full pass with SSE before switching to AVX.
Very often a change in one core does influence the others.
And then you have to fix also the core that was passing before and once done another full pass.


----------



## bebius

Can someone share their 5600x CB23 multi scores? I'm hitting about 11.300 with a 95W PPT and an optimised curve. I wanna see how much of a difference more power would make.


----------



## PJVol

bebius said:


> I wanna see how much of a difference more power would make.


Depending on ambient temps, in a range of 12100 - 12500. PPT limit is set to unreachable value.


----------



## TimeDrapery

ManniX-ITA said:


> There's another testing strategy but is risky; means accepting that the CPU could end up being unstable.
> It's more suited for those having troubles with the secondary cores not being able to run at a low CO count.
> This means not only these cores will be slower in single thread but will also impact the overall all-core performances.
> 
> It's based on the fact that the Windows scheduler is pretty good at starting and redirecting high load to the best cores.
> This means that is really unlikely that a secondary core runs a high load without anything running already on the best cores.
> 
> The strategy is to identify the 3 best cores as in the HWInfo screenshot below:
> 
> View attachment 2524154
> 
> 
> Then test with CC to find the best CO count for 2, 5, 1 running it on a single core.
> 
> To find the CO count for the rest of the cores, run CC on the secondary core and in parallel on the 3 best cores.
> So to test Core 7 use the following config.ini option (HWInfo cores are +1):
> 
> coreTestOrder = 6, 1, 4, 0
> 
> If you want to reduce the chances of failures you can reduce the parallel cores under test:
> 
> coreTestOrder = 6, 1, 4
> coreTestOrder = 6, 1
> 
> It's risky and I wouldn't recommend it especially for 2CCDs as the scheduler sometimes doesn't move high load processes to the 1st CCD.
> But it's a matter of choice


Oooooh-la-la, I like your style @ManniX-ITA! I'm gonna give this a try!


----------



## ManniX-ITA

PJVol said:


> Depending on ambient temps, in a range of 12100 - 12500. PPT limit is set to unreachable value.


@bebius just if you didn't noticed
Cooling is of course the main factor, especially on all-core performances
As you can see in PJVol's signature: *Cooling*: EK FLUID GAMING A240R


----------



## bebius

Here is a snippet of my optimising process:









Getting the boost to +200 does nothing for the performance, as I have a PPT limit of 95W. So, the cpu can't reach those high clocks anyway.
I'm starting to get too much into the positive territory and it feels a bit uncomfortable. What do you think?
Also, isn't it a bit strange for Core 1 to fail at value 5 after so many hours?


----------



## ManniX-ITA

bebius said:


> Getting the boost to +200 does nothing for the performance, as I have a PPT limit of 95W


No experience with the 5600x but I'm surprised you don't see any change.
If you don't see a change in single thread with 95W something else is constraining.



bebius said:


> Also, isn't it a bit strange for Core 1 to fail at value 5 after so many hours?


That's because you are using runtime=6m.
Only Small FFT barely fits.
With Large and Huge only a fraction is tested every round.
Use "All" as suggested otherwise you'll get random results.


----------



## Sleepycat

bebius said:


> Here is a snippet of my optimising process:
> View attachment 2524230
> 
> 
> Getting the boost to +200 does nothing for the performance, as I have a PPT limit of 95W. So, the cpu can't reach those high clocks anyway.
> I'm starting to get too much into the positive territory and it feels a bit uncomfortable. What do you think?
> Also, isn't it a bit strange for Core 1 to fail at value 5 after so many hours?


Personally after my OC experience using Corecycler, I found it more beneficial to test using AVX2 instructions and SMALL size as I knew my memory clocks were stable and I was trying to isolate just the CPU stability. AVX2 is much tougher on the CPU and it fails within a few minutes if the core is unstable. 

SSE is just false security for me as I can pass hours of SSE, and then when an AVX2 load hits in a real life application, I get a crash to desktop. So all those hours of SSE testing is useless for me.


----------



## bebius

ManniX-ITA said:


> No experience with the 5600x but I'm surprised you don't see any change.
> If you don't see a change in single thread with 95W something else is constraining.
> 
> 
> 
> That's because you are using runtime=6m.
> Only Small FFT barely fits.
> With Large and Huge only a fraction is tested every round.
> Use "All" as suggested otherwise you'll get random results.


Oh, I forgot to say that there's no difference in the multithread score. I will compare the single thread ones.
I get your point about the "All" setting.


----------



## ManniX-ITA

Sleepycat said:


> SSE is just false security for me as I can pass hours of SSE, and then when an AVX2 load hits in a real life application, I get a crash to desktop. So all those hours of SSE testing is useless for me.


I don't think is necessarily true. 
In general yes, AVX2 is more though, but the FPU is split in 2 parts.
Testing only AVX2 does not test the other part which is for SSE/AVX-128 instructions.

Plus there's the clock issue. Sometimes a core works properly only up to a certain frequency.
Like in @bebius setup now it could not matter as he's not boosting the clocks.
So testing only with AVX/AVX2 without SSE he wouldn't see any difference.
But with a very high boost clock, especially on a 5900x/5950x, there's a huge difference.
SSE can boost up to 5150 MHz while AVX2 would not go above 4900 MHz.
In this case AVX2 could pass but not SSE.
Without boosting with clocks limited to 4950/5050 MHz they could both pass.
Depends on the settings.



bebius said:


> I will compare the single thread ones.


Let us know, curious to know if it works or not.
Did you register the max effective clocks with and without boost with HWInfo?


----------



## bebius

ManniX-ITA said:


> Let us know, curious to know if it works or not.
> Did you register the max effective clocks with and without boost with HWInfo?


Ι will run a singlethread CB23 for both +50 and +200 boost. Should I run p95 huge also to get the max boost readings?


----------



## ManniX-ITA

bebius said:


> Should I run p95 huge also to get the max boost readings?


That would be nice as well. In SSE mode!


----------



## bebius

ManniX-ITA said:


> That would be nice as well. In SSE mode!


Good, I will get the low boost measurements at night though when I get home, as I'm connected remotely to my pc atm.

Edit: I guess we need the readings for the best core, right?


----------



## ManniX-ITA

bebius said:


> Edit: I guess we need the readings for the best core, right?


Should be enough yes


----------



## bebius

This is the max clock with the aforementioned settings:








I guess it should be higher, closer to 4850Mhz, shouldn't it?
PBO limits are not even remotely reached.

Single thread CB23 score is 1560.


----------



## ManniX-ITA

bebius said:


> I guess it should be higher, closer to 4850Mhz, shouldn't it?


You should compare the score with CB23 vs 0/50MHz.
Being AVX load the clock could not boost to the max.
CC with P95 SSE Huge instead should go near 4850.


----------



## bebius

ManniX-ITA said:


> You should compare the score with CB23 vs 0/50MHz.
> Being AVX load the clock could not boost to the max.
> CC with P95 SSE Huge instead should go near 4850.


The load was P95 SSE Huge.


----------



## ManniX-ITA

bebius said:


> The load was P95 SSE Huge.


Ah... thought that was the clock for CB23.
Something is wrong indeed. It should clock much higher.
Not sure what since you don't get close the PBO limits.
Could be some BIOS setting or just a poor quality BIOS release.


----------



## bebius

ManniX-ITA said:


> Ah... thought that was the clock for CB23.
> Something is wrong indeed. It should clock much higher.
> Not sure what since you don't get close the PBO limits.
> Could be some BIOS setting or just a poor quality BIOS release.


Not cool.
I'm going to try to disable some additional protection options my mobo has later and see what happens.


----------



## ioannis91

Guys when testing the boost override, let's say at +200 what should I aim for? All the cores doing +200, 4 out of 6 or just the 2 best? Or is it just a matter or choice?


----------



## bebius

ioannis91 said:


> Guys when testing the boost override, let's say at +200 what should I aim for? All the cores doing +200, 4 out of 6 or just the 2 best? Or is it just a matter or choice?


Aim for one core with a lighter load, like SSE Huge size. You get lower boost with more cores or/and heavier loads.


----------



## ioannis91

Sorry, I didn't phrase it correctly. I meant each core individually. The bad cores need more negative curve counts to hit higher boost override offsets so you may end up unstable. So the question is, do I stay on +200 and accept the fact that not all cores can do it and being stable or lower the offset until each core can do it and of course being stable?


----------



## bebius

ioannis91 said:


> Sorry, I didn't phrase it correctly. I meant each core individually. The bad cores need more negative curve counts to hit higher boost override offsets so you may end up unstable. So the question is, do I stay on +200 and accept the fact that not all cores can do it and being stable or lower the offset until each core can do it and of course being stable?


Bad cores can't hit higher boost so they can manage with lower voltage = higher negative counts. 
Yes, you have to lower the cores' offset (or even set a positive one for the best cores) the higher you set the boost to.


----------



## PJVol

ioannis91 said:


> Guys when testing the boost override, let's say at +200 what should I aim for? All the cores doing +200, 4 out of 6 or just the 2 best? Or is it just a matter or choice?


You should set boost override based on your cooling capability and silicon quality.
For example, if both of your "best" cores can reach 4850 in CBR23 single core test, then just override max boost frequency with +200.
Tuning CO magnitudes for the other cores is another story.
1. No need to push them to the max stable offset, since allcore boost frequency will be limited by the core with the worst V/F/T.
2. The cores that marked as the 1st and 2nd best in CPPC rating won't necessarily be the best in all core scenario, so you may have to compromise somewhere.


----------



## bebius

I can't hit +200 whatever mobo setting I try (basically I have disabled all the overcurrent protections and emi protection). PBO scalar makes no difference. With aida memory test, I can hit 4740Mhz which is the highest I can see. 
Temps hit 73C maximum for single core testing.
Any help would be appreciated.
Can you guys hit max boost with p95 SSE Huge/Large size?


----------



## ManniX-ITA

bebius said:


> Can you guys hit max boost with p95 SSE Huge/Large size?


Someone with a 5600x should jump in...
With the 5950x I can hit at least 4900 MHz on all core on the 1st CCD.
Only the worst ones in the 2nd CCD can't make it to 4800 MHz.



Code:


# Core EffC VID 
#    0 4987 1.313
#    1 5037 1.395
#    2 4944 1.320
#    3 4992 1.322
#    4 5117 1.402
#    5 4990 1.340
#    6 5031 1.366
#    7 4934 1.320
#    8 4890 1.382
#    9 4793 1.393
#   10 4869 1.382
#   11 4798 1.393
#   12 4917 1.394
#   13 4840 1.381
#   14 4883 1.387
#   15 4776 1.381


----------



## Mach3.2

If you can sustain single core boost clocks above 4600MHz with good cooling, AMD have done their part. Any headroom that you can(or cannot) get is up to your luck. If you can't actually hit the +200MHz boost, it's probably better for you to dial it back to something you can actually hit.

Back when I still had a 5600X, best I can queeze out of my chip is around 4500-4600MHz all core boost while running CB20.


----------



## bebius

ManniX-ITA said:


> You should compare the score with CB23 vs 0/50MHz.


+50Mhz :1547 points, max boost 4699Mhz
+200Mhz:1560 points, max boost 4745Mhz 



Mach3.2 said:


> If you can sustain single core boost clocks above 4600MHz with good cooling, AMD have done their part. Any headroom that you can(or cannot) get is up to your luck. If you can't actually hit the +200MHz boost, it's probably better for you to dial it back to something you can actually hit.
> 
> Back when I still had a 5600X, best I can queeze out of my chip is around 4500-4600MHz all core boost while running CB20.


I'm mostly after single core boost, and my cooling is adequate for that. I used to think that 4850Mhz is achievable as my board is decent too. Temps for single core loads reach 70C. Especially today, the ambient dropped a lot and I can only see max temps up to 67C.
So it makes me wonder what holds it back atm.


----------



## ManniX-ITA

bebius said:


> So it makes me wonder what holds it back atm.


Ouch, didn't noticed it.
I think the main suspect is the board... I have seen some people complaining the same with the X470.
While in theory it should be absolutely capable, seems the PBO in the AGESA is kind of "nerfed".
Many complained it was a move from AMD to push people to upgrade to the B550/X570 but I wouldn't know.


----------



## bebius

Well... that sucks. I bought one of the premium ones for my humble R5 2600, in order to support stronger cpus later. I also had a terrible experience with my previous mobo from the fx series era. It had zero boost capabilities due to crappy vrm design and the cpu used to throttle at stock too. 
Anyway, I'll let you know if I find out anything interesting. Please link me to any thread about this nerfing if you find one by chance.


----------



## TimeDrapery

ManniX-ITA said:


> I don't think is necessarily true.
> In general yes, AVX2 is more though, but the FPU is split in 2 parts.
> Testing only AVX2 does not test the other part which is for SSE/AVX-128 instructions.
> 
> Plus there's the clock issue. Sometimes a core works properly only up to a certain frequency.
> Like in @bebius setup now it could not matter as he's not boosting the clocks.
> So testing only with AVX/AVX2 without SSE he wouldn't see any difference.
> But with a very high boost clock, especially on a 5900x/5950x, there's a huge difference.
> SSE can boost up to 5150 MHz while AVX2 would not go above 4900 MHz.
> In this case AVX2 could pass but not SSE.
> Without boosting with clocks limited to 4950/5050 MHz they could both pass.
> Depends on the settings.
> 
> 
> 
> Let us know, curious to know if it works or not.
> Did you register the max effective clocks with and without boost with HWInfo?


Your point regarding the split validates the need to test both for me!


----------



## bebius

bebius said:


> +50Mhz :1547 points, max boost 4699Mhz
> +200Mhz:1560 points, max boost 4745Mhz
> I'm mostly after single core boost, and my cooling is adequate for that. I used to think that 4850Mhz is achievable as my board is decent too. Temps for single core loads reach 70C. Especially today, the ambient dropped a lot and I can only see max temps up to 67C.
> So it makes me wonder what holds it back atm.


I thought about it for a little more, and I realised that my V-F curve has gone up after optiomising and testing with the tool:
20, 4, +11, 12, 20, 14
So, it's a situation where for the same voltages, a lower frequency can be achieved. (I had forgotten the fundamentals of the curves functionallity.)
I went on and set a negative -15 all core curve and voila (couldn't boot at -25), I can hit 4826Mhz. Of course, a bunch of errors are going to occur if stress testing it.
Basically, the algorithm gives you a voltage range to use for different clocks. If you need more voltage due to silicon lottery, the PBO will boost the cpu to lower max clocks in order to keep the voltage in range. Consequently, there is no point in trying to hit the target of the advertised boost+overdrive setting.


----------



## PJVol

bebius said:


> I can't hit +200 whatever mobo setting I try (basically I have disabled all the overcurrent protections and emi protection). PBO scalar makes no difference. With aida memory test, I can hit 4740Mhz which is the highest I can see.
> Temps hit 73C maximum for single core testing.
> Any help would be appreciated.
> Can you guys hit max boost with p95 SSE Huge/Large size?


Can you post hwinfo screen like this?
Take note of which sensors are shown, and which are hidden on purpose.
But before you do that, right after the start of HWInfo, in main window click "Settings" and set the checkbox labeled "Snapshot CPU polling".


----------



## bebius

PJVol said:


> Can you post hwinfo screen like this?
> Take note of which sensors are shown, and which are hidden on purpose.
> But before you do that, right after the start of HWInfo, in main window click "Settings" and set the checkbox labeled "Snapshot CPU polling".


Here it is while running single core CB23:









(I also gave a possible explanation right before your last message, in case you missed it.)


----------



## ManniX-ITA

bebius said:


> Here it is while running single core CB23:


It looks weird...
Especially the Core 2 which is 1/1 and boosts to clock 4612, effective 4462.
Maybe the pooling period is high, at 2000ms?


----------



## PJVol

So your CO values while benching was 20, 4, +11, 12, 20, 14 ? These are never gonna give you any profit.
Tell me what other PBO settings are, as well as the voltages and digi+ settings?
Did you messed with LLC or other VRM related stuff?
What is your temp in CB R23 MultiCore test?
Why there's no per-core temperatures, is your HWInfo version outdated? If so, better to update to the 7.10 at least.
Can you just reset your BIOS to default, and run the same single core CB R23 a couple of minutes just to snapshot hwinfo sensors?


----------



## bebius

ManniX-ITA said:


> It looks weird...
> Especially the Core 2 which is 1/1 and boosts to clock 4612, effective 4462.
> Maybe the pooling period is high, at 2000ms?


Yes it was high but lowering to 100ms didn't change anything. In fact, for some reason CB23 is hammering the 1/2 core all the time.



PJVol said:


> So your CO values while benching was 20, 4, +11, 12, 20, 14 ? These are never gonna give you any profit.
> Tell me what other PBO settings are, as well as the voltages and digi+ settings? Did you messed with LLC or other VRM related stuff?
> What is your temp in CB R23 MultiCore test?
> Can you just reset your BIOS to default, and run the same single core CB R23 a couple of minutes just to snapshot hwinfo sensors?


PBO with these settings gives me 1000 more CB R23 points than the stock settings.
Other PBO settings are 95W PPT (for the temps) and motherboard values for the rest (125 and 200 I think). Also +200 boost override.
I haven't changed any other LLC or VRM settings.
CB R23 Multi temps are around 73C.
I'm going to make a default run and post the screenshot now.


----------



## ManniX-ITA

PJVol said:


> Tell me what other PBO settings are, as well as voltages and digi+ settings?


Yes, there's something else that's holding back and messing with CO.
It's not right the best core needs +11 and works that bad.
Could be also a lack of SOC, IOD, CCD.


----------



## PJVol

ManniX-ITA said:


> Especially the Core 2 which is 1/1 and boosts to clock 4612, effective 4462.


Yeah, some weird metrics at a first glance, but look at his magnitude min-max delta... such a mess ))
If his core's 2 actual voltage suppled was 1.444V for the 4730Mhz, then it might be a CKS triggered on temp/power.


----------



## bebius

Here it is at stock:


----------



## PJVol

Can you make one more screen, this time while running cbr23 multicore test? So far i don't see anything odd.
Sure, your sample is a bit on a low-leakage side, i.e. cores needed more voltage compared to mine, but not much.
Plus MSI load-line implementation is quite agressive, compared to asrock one.


----------



## bebius

PJVol said:


> Can you make one more screen, this time while running cbr23 multicore test? So far i don't see anything odd.
> Sure, your sample is a bit on a low-leakage side, i.e. cores needed more voltage compared to mine, but not much.
> Plus MSI load-line implementation is quite agressive, compared to asrock one.


Sure, here it is with PBO:


----------



## PJVol

No, pbo should be set to auto (default). Just as default as before, when you made single core test.
We need to see, what VID is requested by each core during the allcore modest load, so that power or current limis were not reached


----------



## bebius

PJVol said:


> No, pbo should be set to auto (default). Just as default as before, when you made single core test.


Sorry, here it is:


----------



## AmateurRanger

So I seem to have a steady build with two cores at -30. However if I try to lower other cores, those two will become unstable, is this normal or has anyone experienced this before?


----------



## dansi

Mach3.2 said:


> If you can sustain single core boost clocks above 4600MHz with good cooling, AMD have done their part. Any headroom that you can(or cannot) get is up to your luck. If you can't actually hit the +200MHz boost, it's probably better for you to dial it back to something you can actually hit.
> 
> Back when I still had a 5600X, best I can queeze out of my chip is around 4500-4600MHz all core boost while running CB20.


i think amd is also artificially limiting max boost clocks for 56 and 58 ryzens. the ccd are the same in all of them, no explanation why 5600x for example cant hit 4.9ghz at least


----------



## Mach3.2

dansi said:


> i think amd is also artificially limiting max boost clocks for 56 and 58 ryzens. the ccd are the same in all of them, no explanation why 5600x for example cant hit 4.9ghz at least


That's possible, but it also could be "poor" quality silicon, especially on the 5600X SKU.

As it stands, the 5600X is literally at the bottom of the barrel when it comes to silicon binning, it's literally an Epyc, Threadripper, Ryzen 9 and Ryzen 7 CCD reject.


----------



## ManniX-ITA

bebius said:


> Sorry, here it is:


Unless some BIOS setting is messed up, I'm pending to think that Core 2 is faulty.
Which is a big problem considering is 1/1....



AmateurRanger said:


> So I seem to have a steady build with two cores at -30. However if I try to lower other cores, those two will become unstable, is this normal or has anyone experienced this before?


Yes it does happen. The gap with the other offsets should not be too high, though.
If they are the best cores could be valuable, you have to bench them.
Doesn't mean at -30 are faster than -25 with other cores with lower counts.


----------



## mongoled

ManniX-ITA said:


> @bebius just if you didn't noticed
> Cooling is of course the main factor, especially on all-core performances
> As you can see in PJVol's signature: *Cooling*: EK FLUID GAMING A240R


Yeah and then making the liquid colder by reducing ambient temperature substantially will boost the score considerably...



Mach3.2 said:


> That's possible, but it also could be "poor" quality silicon, especially on the 5600X SKU.
> 
> As it stands, the 5600X is literally at the bottom of the barrel when it comes to silicon binning, it's literally an Epyc, Threadripper, Ryzen 9 and Ryzen 7 CCD reject.


You have hurt my 5600x feelings, someone ban this poster

😂 😂


----------



## bebius

ManniX-ITA said:


> Unless some BIOS setting is messed up, I'm pending to think that Core 2 is faulty.
> Which is a big problem considering is 1/1....


All bios settings were default.


----------



## mongoled

Does anyone think that setting up a Ryzen CPU testing service would be a viable business venture ??


----------



## ManniX-ITA

bebius said:


> All bios settings were default.


Supposed so, I mean more something messed up on Auto.

Can you take screenshots of BIOS settings with F12 and post them here together with a Zentimings screenshot?


----------



## bebius

ManniX-ITA said:


> Supposed so, I mean more something messed up on Auto.
> 
> Can you take screenshots of BIOS settings with F12 and post them here together with a Zentimings screenshot?


I will do it tonight when I get home.


----------



## ioannis91

I am getting this behavior: I put offset at +200 and start testing (SSE, Huge FFTs, auto runtime). Each time I lower the curve count and most cores boost higher but after a certain point some boost lower. Is this is normal or not? And how do I proceed? How can I find the best boost clocks for each core and at which curve count they achieve it?
Here's a screenshot from the test runs.


----------



## mongoled

ioannis91 said:


> I am getting this behavior: I put offset at +200 and start testing (SSE, Huge FFTs, auto runtime). Each time I lower the curve count and most cores boost higher but after a certain point some boost lower. Is this is normal or not? And how do I proceed? How can I find the best boost clocks for each core and at which curve count they achieve it?
> Here's a screenshot from the test runs.
> View attachment 2524366


Of course its normal as you are now starving some cores for voltage, so the algorithm is doing its best to keep them stable by lowering the clock speed ..

Otherwise people would just set there CPUs to 0.5v and get 5Ghz+ overclocks !


----------



## ManniX-ITA

ioannis91 said:


> Is this is normal or not? And how do I proceed? How can I find the best boost clocks for each core and at which curve count they achieve it?


Yes it's the new normal. Earlier AGESA were different but now the count acts sometimes like a dial knob.
You go lower with count and the frequency could drop and the voltage go up.
That's what I did.


----------



## ioannis91

So what now? Cores #3 and #5 are the two best ones and with count 7 seem to do their best frequency. So I leave them on 7 and see how far the others can go? Or if I change the counts of the other cores will that impact the freq of 3 and 5 as well? It's a bit convoluted


----------



## mongoled

ioannis91 said:


> So what now? Cores #3 and #5 are the two best ones and with count 7 seem to do their best frequency. So I leave them on 7 and see how far the others can go? Or if I change the counts of the other cores will that impact the freq of 3 and 5 as well? It's a bit convoluted


Thats correct, all you can do is test test test


----------



## ManniX-ITA

ioannis91 said:


> So I leave them on 7 and see how far the others can go? Or if I change the counts of the other cores will that impact the freq of 3 and 5 as well? It's a bit convoluted


Yes 
Your sample seems working fine but still a bit disappointing... I'd expected more 4800-4820 from the best cores.

Could you make a test?
I supposed PBO scalar is Auto/1x.
Can you try with 4x and 8x at the same count what is the best cores speed?
Then if they are stable with a lower count and the frequency again.
Every scalar should give you 0.5-1.5 count.
So try with 8x between -10 and -17.


----------



## ioannis91

I don't feel so confident messing with the scalar. I'll just make do with what it can do with 1x. It is what it is I guess


----------



## mongoled

ioannis91 said:


> I don't feel so confident messing with the scalar. I'll just make do with what it can do with 1x. It is what it is I guess


Ive found that reducing CPU LLC (i.e. more droop) helps boosting behavior, but you would need to redo your CO as everything changes


----------



## ioannis91

Thanks a lot for the info guys, clears things up a lot! Fine tuning zen3 CPUs is indeed very interesting but time consuming, so I'll stick with what it can do on 1x scalar and auto LLC, run CC over night with all FFTs and instruction sets and call it a day. One last question, is it a good idea to put override offset at +200 or after finding what's the best boost it can do (let's say +125) put at +125? Or it doesn't matter?
And what about the polling rate in hwinfo?


----------



## ManniX-ITA

ioannis91 said:


> One last question, is it a good idea to put override offset at +200 or after finding what's the best boost it can do (let's say +125) put at +125? Or it doesn't matter?


This is sustained boost, the max boost should be higher.
Just leave HWInfo open in background and use the browser.
After a few hours you should have the clocks topping about 4850 at least for the best cores.
When there's a quick and light load they should go to max boost clock for brief moments.


----------



## PJVol

bebius said:


> Sorry, here it is:


Can you make screen of CBR23 run, with the default settings, but set PBO -> advanced -> limits -> manual -> 120 - 70 - 300 (PPT/TDC/EDC) ?
Then, 3-5 seconds after starting CBR23, reset sensors by clicking "clocks" at the bottom, and save screenshot right before the end of benchmark.
It should look like this:


----------



## bebius

ManniX-ITA said:


> Can you take screenshots of BIOS settings with F12 and post them here together with a Zentimings screenshot?


Here you are, everything @ stock:


----------



## bebius

PJVol said:


> Can you make screen of CBR23 run, with the default settings, but set PBO -> advanced -> limits -> manual -> 120 - 70 - 300 (PPT/TDC/EDC) ?
> Then, 3-5 seconds after starting CBR23, reset sensors by clicking "clocks" at the bottom, and save screenshot right before the end of benchmark.
> It should look like this:
> 
> View attachment 2524392


This is it:









Everything seems fine, doesn't it?
I guess the cores' ranking goes off when they are pushed by pbo and various curves come into place.


----------



## ManniX-ITA

bebius said:


> Here you are, everything @ stock:


Let's see the behavior, CB23 MT and ST with these settings, if you want to try.

Enable XMP, check that is set FCLK 1600 in sync.

PPT limits as suggested by @PJVol and boost clock to 200.

VDDG CCD and IOD at 1000mV and SOC at 1.1V.

CPU and CPU NB Over and Under Voltage/Current all to Max.
CPU NB LLC to 3, PWM CPU and CPU NB to Max.


----------



## bebius

ManniX-ITA said:


> Let's see the behavior, CB23 MT and ST with these settings, if you want to try.
> 
> Enable XMP, check that is set FCLK 1600 in sync.
> 
> PPT limits as suggested by @PJVol and boost clock to 200.
> 
> VDDG CCD and IOD at 1000mV and SOC at 1.1V.
> 
> CPU and CPU NB Over and Under Voltage/Current all to Max.
> CPU NB LLC to 3, PWM CPU and CPU NB to Max.


I just also set dram @1.42V as stock voltage is too low for xmp.
CB23 ST/MT:


----------



## ManniX-ITA

bebius said:


> I just also set dram @1.42V as stock voltage is too low for xmp.


Looks much better than the previous CB23 ST test.
Can you check if the Core 2 can now pass with CC with the same -4 CO count as Core 1?


----------



## ManniX-ITA

bebius said:


> I just also set dram @1.42V as stock voltage is too low for xmp.


And would be nice if you can record the sensors logging with HWInfo while running CB23 ST:










And then share it here of course.


----------



## bebius

ManniX-ITA said:


> Looks much better than the previous CB23 ST test.
> Can you check if the Core 2 can now pass with CC with the same -4 CO count as Core 1?


Unfortunately, core2 fails p95 instantly at both stock and your simple pbo settings after a BIOS reset.
Could the mobo or the beta bios be the problem instead of the cpu?


----------



## ManniX-ITA

bebius said:


> Could the mobo or the beta bios be the problem instead of the cpu?


Could be. But more likely the CPU.
Test with P95 as it is but with CPU LLC at 2.

Also test with CC as before with count at 7 and check what are the clocks.


----------



## bebius

ManniX-ITA said:


> Could be. But more likely the CPU.
> Test with P95 as it is but with CPU LLC at 2.
> 
> Also test with CC as before with count at 7 and check what are the clocks.


Still failing with LLC 2.
You mean +7 all core?


----------



## ManniX-ITA

bebius said:


> Still failing with LLC 2.
> You mean +7?


Yep to see if it's still having the same behavior or not.


----------



## bebius

ManniX-ITA said:


> Yep to see if it's still having the same behavior or not.


+7 all core single/multi:


----------



## ManniX-ITA

bebius said:


> +7 all core single/multi:


It's hard to understand with a single screenshot for ST.
Set the CO counts as you found stable and take a screenshot for MT.
It should run as before around 4.450.
Then for ST take the logging and share it.
I'd like to see what is the clock/effective at 100%.


----------



## bebius

ManniX-ITA said:


> It's hard to understand with a single screenshot for ST.
> Set the CO counts as you found stable and take a screenshot for MT.
> It should run as before around 4.450.
> Then for ST take the logging and share it.
> I'd like to see what is the clock/effective at 100%.


Stable pbo settings, Multi CB23: 









Single CB23 log on google drive here.


----------



## ManniX-ITA

bebius said:


> Stable pbo settings, Multi CB23:


It doesn't like strong LLC.
Set back LLC Auto and check on MT it runs again at 4450.

I'll check the log.


----------



## PJVol

bebius said:


> This is it


Ok, now repeat the test, but this time set CO values as below
-3 -1 0 -6 -9 -7
Boost override +200, scalar x3 and make the screenshot the same way, as previously.
Then check, if CPU pass the OCCT 9.1 (or whatever the latest) bencmark (not the cpu test) with these settings.
All voltages should be set to auto for now.


----------



## bebius

ManniX-ITA said:


> It doesn't like strong LLC.
> Set back LLC Auto and check on MT it runs again at 4450.
> 
> I'll check the log.


It was already with LLC Auto.



PJVol said:


> Ok, now repeat the test, but this time set CO values as below
> -3 -1 0 -6 -9 -7
> Boost override +200, scalar x3 and make the screenshot the same way, as previously.
> Then check, if CPU pass the OCCT 9.1 (or whatever the latest) bencmark (not the cpu test) with these settings.
> All voltages should be set to auto for now.












Benchmark was passed.


----------



## PJVol

bebius said:


> Benchmark was passed.


Ok, though better to save results.
Try to lower boost to 150 and see, if it affect the the results.
Then you may try the same, but this time CO
-6 -4 -3 -9 -12 -10
Post HWInfo screen then run OCCT bench 2-3 times and post the last score.
If OCCT passed, run blender 1.93 bencmark, scene "Koro" and see if it pass.


----------



## bebius

PJVol said:


> Ok, though better to save results.
> Try to lower boost to 150 and see, if it affect the the results.
> Then you may try the same, but this time CO
> -6 -4 -3 -9 -12 -10
> Run OCCT bench and show the result


Here's the bench for +200 and +150:
















and hwinfo for +150:









Could you please tell me what further testing can show about the cpu's condition?
I'm thinking of ways to try it on any friend's compatible system and see if it fails p95 at stock so I can rma it.


----------



## PJVol

bebius said:


> Could you please tell me what further testing can show about the cpu's condition?


What further testing? Did you passed Blender-Koro?


bebius said:


> I'm thinking of ways to try it on any friend's compatible system and see if it fails p95 at stock so I can rma it.


I dont get it. Are you telling me that you CPU can't pass prime95 at stock settings? Not the per-core test, but the usual allcore?

If it passes, I wouldn't pay much attention to what you get in per-core prime95 testing.
From my experience, if CPU passes OCCT bench, Blender Koro, Linpack extreme, 3DMark CPU profile and Y-cruncher with these settings, you can keep them for 24/7 without a doubt. There's basically nothing wrong in this case with your chip.
The performance is adequate to the cooling used.

If it doesn't pass allcore Prime95 at stock - of course it's subject for RMA.


----------



## Sleepycat

ManniX-ITA said:


> I don't think is necessarily true.
> In general yes, AVX2 is more though, but the FPU is split in 2 parts.
> Testing only AVX2 does not test the other part which is for SSE/AVX-128 instructions.
> 
> Plus there's the clock issue. Sometimes a core works properly only up to a certain frequency.
> Like in @bebius setup now it could not matter as he's not boosting the clocks.
> So testing only with AVX/AVX2 without SSE he wouldn't see any difference.


The Curve Optimizer offset doesn't differentiate between the different parts of the FPU though. But in general, I have found that my 5900X can be run with SSE instructions at a higher clock speed and a lower temperature, for the same voltage compared to AVX. Then similarly, it also seems to run AVX instructions at a higher clock speed and lower temperature than AVX2. So in the end, we are trying to find the best curve based on a single offset number per core, to cover all 3 instruction sets. And because if you pass SSE at a higher clockspeed/lower voltage, it is more likely to fail with AVX and even more so with AVX2.



> But with a very high boost clock, especially on a 5900x/5950x, there's a huge difference.
> SSE can boost up to 5150 MHz while AVX2 would not go above 4900 MHz.
> In this case AVX2 could pass but not SSE.
> Without boosting with clocks limited to 4950/5050 MHz they could both pass.
> Depends on the settings.


In my testing of my 5900X, I found that AVX2 requires 100 MHz lower clock speed for the same voltage compared to SSE, just as you have described, However, it is also the case that because I am on air cooling, the highest clock I ever reached is 4.95GHz @ 1.45V. It doesn't seem to go any higher even with SSE instructions and +200 MHz in PBO. Others have described to me that perhaps there is a map of temperature vs clock speed that the CPU also adheres to when it performs its PBO overclocking. I would reach about 80 ºC in single core CB R23, and it would just peg at 4.95GHz, I have never seen 5 GHz on my system.


----------



## ManniX-ITA

bebius said:


> It was already with LLC Auto.


The whole point was to test different LLC settings 
MSI LLC is really weird.
With all those settings try LLC 2 to LLC 5 and check the ST behavior CB23 and frequency running CC on Core 2 and Core 1.

Your Core 2 could have issues or could have been wrongly serialized as the best core during production.
But can also be a board issue, testing on another board could be helpful.

Test different LLC and maybe save the logs.
You can also check yourself with Generic Log Viewer:










The 100% load peaks on Core 1 are at 75-100MHz clock higher than Core 2.
But most importantly there's a big clock stretching on Core 2.
Only sometimes the effective clock is not skewing; most of the times at peak there's a 50-100 MHz from clock to effective.
So your Core 2 is actually running most of the times 200 MHz lower than Core 1.

If testing LLC you don't see any improvement in Core 1 clocks you should also consider to set +100 and see how it goes.



PJVol said:


> If it passes, I wouldn't pay much attention to what you get in per-core prime95 testing.


I don't know, I wouldn't keep it if not passing Prime95 per-core.
Usually means sudden reboots while browsing internet or playing a Youtube video.
Annoying 



Sleepycat said:


> The Curve Optimizer offset doesn't differentiate between the different parts of the FPU though. But in general, I have found that my 5900X can be run with SSE instructions at a higher clock speed and a lower temperature, for the same voltage compared to AVX. Then similarly, it also seems to run AVX instructions at a higher clock speed and lower temperature than AVX2. So in the end, we are trying to find the best curve based on a single offset number per core, to cover all 3 instruction sets. And because if you pass SSE at a higher clockspeed/lower voltage, it is more likely to fail with AVX and even more so with AVX2.


AVX and AVX2 are linearly more complex and increase the thermal load accordingly therefore reducing the sustained clock.
My point was that being a different die part, if you have a criticality on the SSE/AVX die part it will not show itself running AVX2.
In general I found more important testing SSE on the best cores; the delta of frequency with AVX/AVX2 is higher.
In my case the best cores can go up to 5200 MHz running SSE and crash but don't running AVX2 which runs at 4900 MHz.
I have to limit boost clock to 100 MHz otherwise have to reduce the counts.
While the less better cores doesn't boost anyway very high and the delta is sometimes much lower 100-150 MHz.
They get more stressed by the high temperatures first so AVX/AVX2 becomes more critical.



Sleepycat said:


> In my testing of my 5900X, I found that AVX2 requires 100 MHz lower clock speed for the same voltage compared to SSE, just as you have described, However, it is also the case that because I am on air cooling, the highest clock I ever reached is 4.95GHz @ 1.45V. It doesn't seem to go any higher even with SSE instructions and +200 MHz in PBO.


Definitely something wrong, PBO is not working as it should.
Check your Fmax with HWInfo, should be only 100 MHz less than mine, 4950 MHz.
Then you should see the PBO Clock limit at 5150 MHz if the +200 is enabled.


----------



## PJVol

Sleepycat said:


> The Curve Optimizer offset doesn't differentiate between the different parts of the FPU though


Why it should? It's the CPB 's job to determine frequency based on various restrictions, including type of load. And it knows where and what offset to apply.


Sleepycat said:


> So in the end, we are trying to find the best curve based on a single offset number per core, to cover all 3 instruction sets.


I think the type of workload is one of the restrictive rules respected by CPB algos.
So that actual V offset will take it into account as well.


----------



## bebius

PJVol said:


> What further testing? Did you passed Blender-Koro?
> 
> I dont get it. Are you telling me that you CPU can't pass prime95 at stock settings? Not the per-core test, but the usual allcore?
> 
> If it passes, I wouldn't pay much attention to what you get in per-core prime95 testing.
> From my experience, if CPU passes OCCT bench, Blender Koro, Linpack extreme, 3DMark CPU profile and Y-cruncher with these settings, you can keep them for 24/7 without a doubt. There's basically nothing wrong in this case with your chip.
> The performance is adequate to the cooling used.
> 
> If it doesn't pass allcore Prime95 at stock - of course it's subject for RMA.


I can see your point, but this specific thread is about the main tool for stress testing individual cores and establishing corresponding baselines, so I think that our discussion gets a bit off-topic. I will pm you about further information on the subject.
All core p95 does not fail, at least not in the first couple of minutes like the single core one.



ManniX-ITA said:


> The whole point was to test different LLC settings
> MSI LLC is really weird.
> With all those settings try LLC 2 to LLC 5 and check the ST behavior CB23 and frequency running CC on Core 2 and Core 1.
> 
> Your Core 2 could have issues or could have been wrongly serialized as the best core during production.
> But can also be a board issue, testing on another board could be helpful.
> 
> Test different LLC and maybe save the logs.
> You can also check yourself with Generic Log Viewer:
> 
> 
> 
> The 100% load peaks on Core 1 are at 75-100MHz clock higher than Core 2.
> But most importantly there's a big clock stretching on Core 2.
> Only sometimes the effective clock is not skewing; most of the times at peak there's a 50-100 MHz from clock to effective.
> So your Core 2 is actually running most of the times 200 MHz lower than Core 1.
> 
> If testing LLC you don't see any improvement in Core 1 clocks you should also consider to set +100 and see how it goes.
> 
> I don't know, I wouldn't keep it if not passing Prime95 per-core.
> Usually means sudden reboots while browsing internet or playing a Youtube video.
> Annoying


As I've told you, I had already tested LLC 2 with stock settings, and it failed single core p95 at stock. I'm not expecting any LLC setting to improve the situation at this point.
I'm going to try to RMA it. Thanks a lot for your time!


----------



## PJVol

ManniX-ITA said:


> Usually means sudden reboots while browsing internet or playing a Youtube video.


Im not sure, if that followed from unstable core in a FFT test, and not just overboosting. At least, I've had experienced something like that when CO was not the option yet.


----------



## ManniX-ITA

bebius said:


> As I've told you, I had already tested LLC 2 with stock settings, and it failed single core p95 at stock. I'm not expecting any LLC setting to improve the situation at this point.
> I'm going to try to RMA it. Thanks a lot for your time!


A stronger or weaker LLC settings could improve but not with stock settings.
Anyway if you can RMA the CPU, go for it. My opinion.
Even if it's the board, seems to be a very depressing binning...
Hopefully the whole conversation can be helpful to someone else trying to stabilize the counts.



PJVol said:


> Im not sure, if that followed from unstable core in a FFT test, and not just overboosting.


Direct experience 

Did some "what if" testing with unstable counts and even one count too much on best cores will lead to sudden reboots eventually.
Much more tolerance on the "standard" cores and very unlikely on the bad cores.
But at the end is pointless for my setup; I use ProcessLasso to redirect low priority threads to the 2nd CCD.
Hence I need perfectly stable counts on all cores.


----------



## ioannis91

That's where I ended up, it passes all FFTs on SSE, so AVX/2 to do. Gives about 4530 all core with a bit under 80 degrees on 24 ambient room temperature.


----------



## ioannis91

What is a good pooling rate at hwinfo? I noticed that when i put it in 1000ms instead of the default 2000ms, I saw cores going to 4800. Of course pooling rate does increase the boost , it just measures correctly those very quick boosts..


----------



## ManniX-ITA

ioannis91 said:


> What is a good pooling rate at hwinfo? I noticed that when i put it in 1000ms instead of the default 2000ms, I saw cores going to 4800. Of course pooling rate does increase the boost , it just measures correctly those very quick boosts..


Depends, the CPU usage is increasing a lot lowering the rate.
If you need to catch peaks 1000ms is a good one.
At 500ms it's going to have a sensible hit, not recommended if you want to monitor a benchmark.
Below 200ms is going to be unreliable and could cause instability.
At very fast rates is better to disable all monitors you don't need.
To lower dramatically CPU usage is better to adjust SMART and embedded controllers cycles to have them queries only once 1-2 seconds.


----------



## Sleepycat

ManniX-ITA said:


> Definitely something wrong, PBO is not working as it should.
> Check your Fmax with HWInfo, should be only 100 MHz less than mine, 4950 MHz.
> Then you should see the PBO Clock limit at 5150 MHz if the +200 is enabled.
> 
> View attachment 2524546


Mine shows exactly as you described. Fmax is 4950, and PBO clock limit is 5150. Maybe that's the difference between a 5900X and 5950X.


----------



## ManniX-ITA

Sleepycat said:


> Mine shows exactly as you described. Fmax is 4950, and PBO clock limit is 5150. Maybe that's the difference between a 5900X and 5950X.


Every tier down has -100 MHz Fmax from 5950x. So 5800x has -200 etc.
I'm surprised that not even the best cores goes above 4950.
Did you try with BoostTester?


----------



## PJVol

ManniX-ITA said:


> Your Core 2 could have issues or could have been wrongly serialized as the best core during production


It may turn out, that his Core 2 has met original QC requirements and specs compliance.
I see two possible issues.

First, based on various amd claims(i.e. slides, lol) and user experience, cores are supposedly binned by some auto-test procedures, assigning rating by SIDD value, so its logical to assume, that "fusing-out" two cores (or the whole CCD sometimes)) ) from the CCX is made after that, and therefore might not reflect just changed core layout and potentially, boosting behavior as well.
My 5600X CPU seems to illustrate that well:










CPPC or fused rating is 4-3-5-2-1-6 (from Core0 to Core5) and basically correct if cores weren't influencing each other. But Core0 is ended up so far from the others, that in all-core load its temp sensor report 7-10°C lower than the rest. You can imagine how such delta may impact boosting algorithm behavior. But even without it being so special, there are other factors affecting.

2nd issue:
Core3 in my 5600X is similar to Core2 in * bebius' 5600X*.
Here are the VID requested by each core, and the reported Vcore from SVI2 in a per-core OCCT-prime run (Large/Normal/Steady)
I intentionally capped frequency at 4700 to make voltages comparable.
For clarity, 2 best cores marked with green dots, 2 modest - gray and 2 worst - with red.










At the top test ran cycling through each core with a 30 sec interval (to record average Vcore SVI2) - Vcore and VIDs basically match CPO/fused rating.
Then if look at the second table, where test is performed in a usual manner (i.e. all core load), you'll see how the 2nd best core magically become 2nd modest .
Moreover, the VIDs order is consistent with reported per-core temps in this test.

As a side note, see the temperature of a Core 5 in per-core test?
Its so bad, that it struggle to reach even 4700 in a test conditions, I think it was needed temp 3-5° lower for that.
And look at how core 0 temp correlates with its physical location.

The conclusion is that the individual V/F/T curves not necessarily similar, I mean cores are very different in a way they scaling with voltage and temp.
That is the main reasons, I think, why a certain core with a fused rating X may actually not perform as its rating imply for all use cases.

PS: SSE Large is noticeably heavier than AVX large.


----------



## ManniX-ITA

PJVol said:


> It may turn out, that his Core 2 has met original QC requirements and specs compliance.


It could be indeed but I've never seen such a big gap 
There's 100 MHz delta from the 2nd best plus the 50-100 MHz delta between the reference and effective clock. It's huge!
I'm more inclined something defective in the core or the board messing up.


----------



## PJVol

ManniX-ITA said:


> There's 100 MHz delta from the 2nd best plus the 50-100 MHz delta between the reference and effective clock. It's huge!


Its hard to sort out all his screens now, but if its the one with +7 allcore CO, then its not surprising, CPB just turn on CKS, given the cooling performance.


----------



## ManniX-ITA

PJVol said:


> Its hard to sort out all his screens now, but if its the one with +7 allcore CO, then its not surprising, CPB just turn on CKS, given the cooling performance.


Yes it's the 2 with +7 but why it should be penalized in ST?










It runs cooler than Core 1.


----------



## PJVol

ManniX-ITA said:


> It runs cooler than Core 1.


I see its from screen, where you asked him of doing some vrm trickery, and CPU with loosen limits and +200 boost...
Hmm.. didn't see anything odd there, clocks are 4695 and 4698. May be you meant some other screen, cause it took some time for myself to find the one you referred


----------



## ManniX-ITA

PJVol said:


> Didn't see anything odd there, clocks are 4695 and 4698. May be you meant some other screen, cause it took some time for myself to find what you were referred to


I've asked him to record the HWInfo monitoring in CSV 
There you can see the odd clock behavior.
No temperatures logged but I don't expect is going to be different from that screenshot.
That cooler is not the best but in ST can keep the max temperature between 65-70c easily.


----------



## PJVol

ioannis91 said:


> What is a good pooling rate at hwinfo?


2s is sometimes too long, so I used 1s for rough measurements, which is fine.
It would be nice, if next time you gonna extensive testing, you keep an eye on Vcore SVI2 sensor value and add it to the statistics, as a V/F pairs.



ManniX-ITA said:


> I've asked him to record the HWInfo monitoring in CSV


Do you know of some suitable tool, or better browser extension for quick and easy CSV reading, besides Office?
Tried a dozen of them, and basically all of them not worth installing.


----------



## ManniX-ITA

PJVol said:


> Do you know of some suitable tool, or better browser extensions for quick CSV reading, besides Office?
> Tried a dozen of them, and basically all of them not worth installing.


I use Generic Log Viewer, quite powerful.









Generic Log Viewer Download


Generic Log Viewer ermöglicht die grafische Auswertung der Logfiles von Afterburner, AIDA64, GPU-Z und HWiNFO. Freeware, kostenloser Download!




www.computerbase.de





Not sure if there's any browser extension


----------



## bebius

PJVol said:


> It may turn out, that his Core 2 has met original QC requirements and specs compliance.
> I see two possible issues.
> 
> First, based on various amd claims(i.e. slides, lol) and user experience, cores are supposedly binned by some auto-test procedures, assigning rating by SIDD value, so its logical to assume, that "fusing-out" two cores (or the whole CCD sometimes)) ) from the CCX is made after that, and therefore might not reflect just changed core layout and potentially, boosting behavior as well.
> My 5600X CPU seems to illustrate that well:
> 
> View attachment 2524719
> 
> 
> CPPC or fused rating is 4-3-5-2-1-6 (from Core0 to Core5) and basically correct if cores weren't influencing each other. But Core0 is ended up so far from the others, that in all-core load its temp sensor report 7-10°C lower than the rest. You can imagine how such delta may impact boosting algorithm behavior. But even without it being so special, there are other factors affecting.
> 
> 2nd issue:
> Core3 in my 5600X is similar to Core2 in * bebius' 5600X*.
> Here are the VID requested by each core, and the reported Vcore from SVI2 in a per-core OCCT-prime run (Large/Normal/Steady)
> I intentionally capped frequency at 4700 to make voltages comparable.
> For clarity, 2 best cores marked with green dots, 2 modest - gray and 2 worst - with red.
> 
> View attachment 2524724
> 
> 
> At the top test ran cycling through each core with a 30 sec interval (to record average Vcore SVI2) - Vcore and VIDs basically match CPO/fused rating.
> Then if look at the second table, where test is performed in a usual manner (i.e. all core load), you'll see how the 2nd best core magically become 2nd modest .
> Moreover, the VIDs order is consistent with reported per-core temps in this test.
> 
> As a side note, see the temperature of a Core 5 in per-core test?
> Its so bad, that it struggle to reach even 4700 in a test conditions, I think it was needed temp 3-5° lower for that.
> And look at how core 0 temp correlates with its physical location.
> 
> The conclusion is that the individual V/F/T curves not necessarily similar, I mean cores are very different in a way they scaling with voltage and temp.
> That is the main reasons, I think, why a certain core with a fused rating X may actually not perform as its rating imply for all use cases.
> 
> PS: SSE Large is noticeably heavier than AVX large.


Solid analysis. I agree that the rankings may not apply for different scenarios
Did you use stock settings for the tests?
Also, out of curiosity, have you run p95 for SSE large size at bios defaults?

I can run anything in case someone needs more loggings.
Hopefully, I will only have it for a few more days until they accept the RMA and replace it.


----------



## PJVol

bebius said:


> Did you use stock settings for the tests?
> Also, out of curiosity, have you run p95 for SSE large size at bios defaults?


If you mean the tests in the quoted post, they are just PBO limits and +50 boost override, CO disabled.
Don't get your question regarding p95 at stock, as I'm curious as well, what's the purpose of it.


----------



## bebius

PJVol said:


> If you mean the tests in the quoted post, they are just PBO limits and +50 boost override, CO disabled.
> Don't get your question regarding p95 at stock, as I'm curious as well, what's the purpose of it.


Maybe the real ranking changes again with default setting for single thread benchmarks?
The purpose of running p95 at stock is to check if it's rock stable with the factory settings.


----------



## PJVol

bebius said:


> Maybe the real ranking changes again with default setting for single thread benchmarks?
> The purpose of running p95 at stock is to check if it's rock stable with the factory settings.


No, ranking is never changed. It just sometimes may not reflect the behavior in allcore scenarios, but not in a single core test.
Or it may not be respected by OS at all, if you tell CPU not to pass it to OS (disable CPPC), so system was unable to build ACPI _PSS objects.


----------



## Luggage

I have a new CO test workload - Blender Benchmark, scene Koro.

Still testing but, crashed one of my bad cores from -30 to -15. Repeatable.

Too late now but going to try it with my other “safe” cores tomorrow.


----------



## bebius

Just for the record, the RMA has been approved by AMD for my 5600X.


----------



## AmateurRanger

ManniX-ITA said:


> Unless some BIOS setting is messed up, I'm pending to think that Core 2 is faulty.
> Which is a big problem considering is 1/1....
> 
> 
> 
> Yes it does happen. The gap with the other offsets should not be too high, though.
> If they are the best cores could be valuable, you have to bench them.
> Doesn't mean at -30 are faster than -25 with other cores with lower counts.


Yes sir! Thanks for the insight!


----------



## Poloman

After this:


Spoiler: CC















I got BSOD and WHEA 5 minutes in rdr2,currently it is the only of 4 games i tried that does that,should i keep trying on fixing the OC or just give up on the game?


----------



## bebius

Poloman said:


> After this:
> 
> 
> Spoiler: CC
> 
> 
> 
> 
> View attachment 2525743
> 
> 
> 
> 
> I got BSOD and WHEA 5 minutes in rdr2,currently it is the only of 4 games i tried that does that,should i keep trying on fixing the OC or just give up on the game?


😁 you must be kidding...
RDR2 is great at exposing unstable systems from my experience. It was the only load that could expose my GPU unstable undervolt at some point. Also obviously one of the greatest games ever so don't even think about skipping it.
Have you oc your ram also? You have to be sure that ram is rock stable before the cpu oc.
What's the CC settings?


----------



## Poloman

bebius said:


> 😁 you must be kidding...
> RDR2 is great at exposing unstable systems from my experience. It was the only load that could expose my GPU unstable undervolt at some point. Also obviously one of the greatest games ever so don't even think about skipping it.
> Have you oc your ram also? You have to be sure that ram is rock stable before the cpu oc.
> What's the CC settings?


Default

I got the "erroneous" cores from the event and gave them less negative offset and also running the cc with crunchy. 

I have did a 4 pass memtrest86 for the rams. 
3600c14 with 1.5V,no errors. 
The thing is rdr2 is random at crashing, i have managed to get almost 2hours run before i get the crash, but is frustrating losing the progress, so i wont touch it until im sure.
But its only this game, i run warzone, rf2, acc pretty much indefinitely without a single hiccup.


----------



## PJVol

bebius







www.overclock.net




How's your new cpu?


----------



## bebius

Poloman said:


> Default
> 
> I got the "erroneous" cores from the event and gave them less negative offset and also running the cc with crunchy.
> 
> I have did a 4 pass memtrest86 for the rams.
> 3600c14 with 1.5V,no errors.
> The thing is rdr2 is random at crashing, i have managed to get almost 2hours run before i get the crash, but is frustrating losing the progress, so i wont touch it until im sure.
> But its only this game, i run warzone, rf2, acc pretty much indefinitely without a single hiccup.


I suggest to test the memory first with TM5 usmus config (20 cycles) and anta extreme (3 cycles).
For CC, try with different fft sizes and with avx also cause some configs may fail faster.


PJVol said:


> bebius
> 
> 
> 
> 
> 
> 
> 
> www.overclock.net
> 
> 
> 
> 
> How's your new cpu?


They shipped it yesterday but I will be on holidays for 5 days so I'm gonna get and test it next week.


----------



## Poloman

bebius said:


> I suggest to test the memory first with TM5 usmus config (20 cycles) and anta extreme (3 cycles).
> For CC, try with different fft sizes and with avx also cause some configs may fail faster.


Did the memory test,all went smooth. Havent done the CC yet.
BUT BUT BUT,disabled c-state , change windows power mode to high and managed to get a clean long session in rdr2.
If i had to guess that c-state might have done the job,i changed it because i also had small issues with USB (no disconections,just empty errors),and it seems like it fixed everything.


----------



## bebius

I didn't even know c-states can influence the oc or the USB state. Please share some relevant info if you have any.


----------



## Poloman

First,it was this:








AMD Suggests Possible Fixes for Ryzen USB Connectivity Issues


Here, give this a shot




www.tomshardware.com





Then i also read somewhere that some chips were dropping at too low voltage,it might not even be the OC for me but the way the cpu generally works.I'll try default bios settings at some point if im not bored.


----------



## Veii

AmateurRanger said:


> So I seem to have a steady build with two cores at -30. However if I try to lower other cores, those two will become unstable, is this normal or has anyone experienced this before?
> 
> 
> ManniX-ITA said:
> 
> 
> 
> Doesn't mean at -30 are faster than -25 with other cores with lower counts.
Click to expand...

+1
Changing the magnitudes of all cores -30 , doesn't mean you set all @ -30
It means AMD Value -30 on all cores

-30 without any positive vcore offset is generally not a good idea
And -30 still can be a bad idea, compared to -25 ~ as you have to depend on AMD doing their job correctly
Not every sample out there has a "correct V/F" curve ~ but every sample out there is benched inside CO range's headroom - before it get's pushed down as weaker unit or has "fused away" cores

Soo on bad samples, already going -1 allcore, can be the difference between stable and unstable


----------



## 1devomer

Veii said:


> +1
> Changing the magnitudes of all cores -30 , doesn't mean you set all @ -30
> It means AMD Value -30 on all cores
> 
> -30 without any positive vcore offset is generally not a good idea
> And -30 still can be a bad idea, compared to -25 ~ as you have to depend on AMD doing their job correctly
> Not every sample out there has a "correct V/F" curve ~ but every sample out there is benched inside CO range's headroom - before it get's pushed down as weaker unit or has "fused away" cores
> 
> Soo on bad samples, already going -1 allcore, can be the difference between stable and unstable


It is not better, to avoid adding positive vcore offset on top of the stock CO curve, when you probe the cores* the 1st time*?
Isn't the point of the CO curve, to detect weak and bad cores, easily fixing these weaker cores with lower negative CO or even positive CO values?

You want to add positive vcore offset, when you realize that some cores need too much CO positive offset, with the default curve.

Because it is not what we advised to users until now, we never advised to introduce a positive vcore offset straight, without having probed the cores first, with the default cpu CO curve?!

_Nb: a condensed answer, if an answer is need, is welcome, avoid lengthy post please!_


----------



## 1devomer

Poloman said:


> Did the memory test,all went smooth. Havent done the CC yet.
> BUT BUT BUT,disabled c-state , change windows power mode to high and managed to get a clean long session in rdr2.
> If i had to guess that c-state might have done the job,i changed it because i also had small issues with USB (no disconections,just empty errors),and it seems like it fixed everything.





Poloman said:


> First,it was this:
> 
> 
> 
> 
> 
> 
> 
> 
> AMD Suggests Possible Fixes for Ryzen USB Connectivity Issues
> 
> 
> Here, give this a shot
> 
> 
> 
> 
> www.tomshardware.com
> 
> 
> 
> 
> 
> Then i also read somewhere that some chips were dropping at too low voltage,it might not even be the OC for me but the way the cpu generally works.I'll try default bios settings at some point if im not bored.


Usually, when one needs to disable the C-states to get the latest AMD cpu working as they should, is not a good sign.
It seems you have all the symptoms of a badly dinned or weak cpu.

I would advise to RMA it to AMD or your reseller, being sure to record a video of the cpu bad behaviour, with the latest bios stock + XMP ram.


----------



## ManniX-ITA

1devomer said:


> It is not better, to avoid adding positive vcore offset on top of the stock CO curve, when you probe the cores* the 1st time*?


No doesn't look like a good idea indeed.
I'd first make a round with CC P95 Huge just to record the VID and Effective frequency at the lowest CO count that seems stable.



1devomer said:


> Isn't the point of the CO curve, to detect weak and bad cores, easily fixing these weaker cores with lower negative CO or even positive CO values?


Not really, the point is to maximize the V/F curve rendition. You set as lowest you can till it gets unstable.
Only in some cases, which usually means the binning/serialization is bad, you can use a positive offset to fix instability. It can happen on a bad as well on a good core. 



1devomer said:


> You want to add positive vcore offset, when you realize that some cores need too much CO positive offset, with the default curve.


The positive vCore will raise the VIDs for all cores. It's convenient eg. to fix instabilities when you can set almost all cores to a very low value.
A core than needs too much positive will not benefit; you can set a lower CO but the result will be always the same.
Eg. on a good core that can go down to -30 a little higher VID will not necessarily change the single core performances (if there's still headroom).
But could allow the other cores to go down to -25 instead of -20 which is a pretty substantial all-core advantage.
There are different use cases where it can be convenient. 



1devomer said:


> Because it is not what we advised to users until now, we never advised to introduce a positive vcore offset straight, without having probed the cores first, with the default cpu CO curve?!


I've never heard about setting straight a positive vCore, I don't think that's what @Veii said.


----------



## Veii

1devomer said:


> It is not better, to avoid adding positive offset on top of the stock CO curve, when you probe the cores* the 1st time*?
> Isn't the point of the CO curve, to detect weak and bad cores, easily fixing these weaker cores with lower negative CO or even positive CO values?
> 
> You want to add positive offset, when you realize that some cores need too much positive offset, with the default curve.
> 
> Because it is not what we advised to users until now, we never advised to introduce a positive offset straight, without having probed the cores firts, with the default cpu CO curve?!
> 
> _Nb: a condensed answer, if an answer is need, is welcome, avoid lengthy post please!_


Bit hard to avoid length, when the question/request is on a big unclear/unanswered topic 
Comes over bit rude, defining the way of asking for help

First important lesson;

dLDO_Injector will balance global requested VID, up to core requested VID ~ since AGESA 1.1.8.X
Core requested VID will pass through FIT, in FIT PRE-Voltage limit (usually 50mV higher than the invisible voltage throttle wall)
2nd stage , it checks whenever this allowed voltage ~ passes within PPT, THM, TDC, EDC limit. Rather recognizes if amperage of X amount of cores for Y global VID requested ~ passes over set EDC FUSE limit (A)
later cores frequency target check and so request Z VID by the V/F curve, by the architecture (mind you, every sample has a different range ~ they are not on the same scale)

What means "unstable" ~ is it;

*A* core can not hold frequency under AVX ! selected workload (loadline to droopy ?, AVX2 has a fixed voltage drop + loadline droop)
*B* core is more than capable , but global VID was too low and other bad cores took away too much priority and dLDO ruined boost
*C* also* B* ~ BUT, higher strap-stepping voltage couldn't be provided, because FIT detected a limit (most likely CCA limit) and had to throttle back
*D* followup for *C* ~ but the reasoning purely was, because it reached ProcHot limit yet not reaching THM set limit. Soo every 10c it lost 100mhz maximum boost (an issue on 6 cores, but unclear if dual CCD PROCHOT is really accurate & extended) ~ mostly happens on AVX2 loads titled under CCA throttle
* mostly it's *B* only. Cores are far more than capable but by default are plain simply overvolted soo they reach *C* first. They reach an artificial 1.4v wall by FIT
(from 1.45 ~ 1.55v wall guys mileage & limit, will vary by CPU "version")
_soo before they even get the ability to reach potential high clocks - they are throttled back as VID was *too high for FIT*_

Single Core is crashing ~ Usage;

if #3 out of 5 (0-5) cores, is unstable ~ then you give this core more negative CO offset (if *C* is the reason. But it's close to always this reason _~the bad core requesting too much VID~_, soo you try this first)
if #3 continues to crash, you put it back where it was by AMD (values change magnitude, they do not override AMDs binning !) but you give everything around it a negative CO ~ soo dLDO will leave more for this "bad" core (this is now the case *A* in the core being just too hungry and not getting enough voltage ~ but this is very rare and close to never the case, as cores all are binned -/+ 30 CO steps by AMD unless it's an 6 core)
Core by this time should be stable. If not, you continue in bigger steps. -2 all cores except this one, soo global VID remains identical
(if scenario *C* is not reached and req vid doesn't surpass FIT-Pre-VID hardlimit)
At this point you finally should have solved the dropping core issue ~ if the "unstable/drop" was not caused in the first place by being throttled back by reason *C or D *~ by reason FIT, not core quality

Boost is not reachable, cores are not first stage PPT, TDC, EDC throttled ~ but Strap is applied;
Cores will be package throttled , but you didn't figure the reason why.
If they are not PPT, TDC, EDC, THM, FIT-PRE-VID, PROCHOT ~ throttled & all of these 5 are held
(FIT PRE will drop once prochot limit has reached, systematically and so lower "FIT Limit" systematically ~ which is extended by the scalar but not fully disabled)








Also if cTDP & Package Power limit in AMD CBS - NBIO , are lifted (i put 400W because it's high enough)
One event that is still possible , aside from *C *is

Cores being stable, yet being throttled back (package throttle) mostly belongs to lack of VDD18 rail or lack of VDDG CCD (which also is capable to "crash cores" without it being a VID reason)
======================================================
I'll write next time a more clear tutorial how to work on "Single Core is crashing" scenario
~ once Hydra 1.0 (or free public version) has released and users have to experiment "in-windows" with CO limits
As Hydra will also give you a "diagnosed" BIOS Value ~ field, it makes sense to catch support where it's needed. The scenario where the user extends fixed CO in order to extend V/F curve
Just remember the quote


> -2 on everything, every +25mhz
> 1 CO value = 3-5mV VID


======================================================


1devomer said:


> It is not better, to avoid adding positive offset on top of the stock CO curve, when you probe the cores* the 1st time*?
> Isn't the point of the CO curve, to detect weak and bad cores, easily fixing these weaker cores with lower negative CO or even positive CO values?


What people use as a shortcut = -30 all core
Is to prevent FIT-PRE-V to throttle back. as cores will move below this limit & try to reach the frequency
What users do not think, is that -30 = -110mV ~ -120mV taken away VID / while Frequency to Voltage strap, will be tried to be set
Either they
A ~ reach the strap and have good cores, yet Effective clock never reaches that frequency
B ~ they pull everything else down, because cores are not capable to run at individual frequency. CCX Delta & CCD Delta are a thing, but under closed disclosure. Cores have to run at the lowest frequency strap one core in the chain runs at ~ unless the core is fully hibernated, but not just idle-suspended

The "easy mode" is to run a global magnitude of -30 , and just add positive vcore offset till it's stable 
(till the worst core surely has enough voltage & all cores hold fully the peak freq strap)
Positive vcore offset by VRMs is not detected inside the FIT-PRE-V scale.
FIT-PRE only checks requested VID , but never supplied voltage
FIT does check global supplied voltage ~ but their range lies in the 1.55+. Soo it only throttles on the 4th stage (emergency package throttle) if you overdo supplied positive vcore
* Yet again, this information about the range is not shareable till X user under NDA leaks it and it get's public knowledge
Sensor max voltages are far higher and bios offset allows to use a +100mV range at least.

Keep my word that Vermeer samples still have a lot of range in them, and +200 Mhz override ~ as SMNCLK peak, is too low. AMD has to finally free this limiter and allow us back +500Mhz overrides & more CO ranges.
They should move this only inside AMD OVERCLOCKING ~ soo users are own fault if they have unstable units. Not artificially limit being sub 1.5v. 

EDIT:
The only reason , users -30 Global-CO passes ~ is because CPUs are binned inside -/+ 30 CO range out of the factory (not always but most of the time posts)
If higher samples core quality (even bronze) does not pass this - it's reused as lower core sample or fully a single CCD unit with "different" V/F curve
Dual CCD 6 & 8 core units - generally have a broken V/F curve of their Dual-CCD brothers. Soo often these samples fail to hold AMD's CO range by default, as VID per frequency strap (V/F) is messed up on such (reminder ~ 5600X, 5800X, 5900X, 5950X have different V/F Curve)
These need generally a bit of positive offset, to fix WHEA #18 issues on stock stock (X1 scalar) without boardpartner cheatery enhancers
Some users like me, also combine then droopy loadline + positive vcore ~ to as best as possible match Supplied TEL-V with VID-V 


Spoiler: Reused Example


----------



## 1devomer

ManniX-ITA said:


> No doesn't look like a good idea indeed.
> I'd first make a round with CC P95 Huge just to record the VID and Effective frequency at the lowest CO count that seems stable.
> 
> 
> 
> Not really, the point is to maximize the V/F curve rendition. You set as lowest you can till it gets unstable.
> Only in some cases, which usually means the binning/serialization is bad, you can use a positive offset to fix instability. It can happen on a bad as well on a good core.
> 
> 
> 
> The positive vCore will raise the VIDs for all cores. It's convenient eg. to fix instabilities when you can set almost all cores to a very low value.
> A core than needs too much positive will not benefit; you can set a lower CO but the result will be always the same.
> Eg. on a good core that can go down to -30 a little higher VID will not necessarily change the single core performances (if there's still headroom).
> But could allow the other cores to go down to -25 instead of -20 which is a pretty substantial all-core advantage.
> There are different use cases where it can be convenient.
> 
> 
> 
> I've never heard about setting straight a positive vCore, I don't think that's what @Veii said.





Veii said:


> Bit hard to avoid length, when the question/request is on a big unclear/unanswered topic
> 
> First important lesson;
> 
> dLDO_Injector will balance global requested VID, up to core requested VID
> Core requested VID will pass through FIT, in FIT PRE-Voltage limit (usually 50mV higher than the invisible voltage throttle wall)
> 2nd stage , it checks whenever this allowed voltage ~ passes within PPT, THM, TDC, EDC limit. Rather recognizes if amperage of X amount of cores for Y global VID requested ~ passes over set EDC FUSE limit (A)
> later cores frequency target check and so request Z VID by the V/F curve, by the architecture (mind you, every sample has a different range ~ they are not on the same scale)
> 
> What means "unstable" ~ is it;
> 
> *A* core can not hold frequency under AVX ! selected workload (loadline to droopy ?, AVX2 has a fixed voltage drop + loadline droop)
> *B* core is more than capable , but global VID was too low and other bad cores took away too much priority and dLDO ruined boost
> *C* also* B* ~ BUT, higher strap-stepping voltage couldn't be provided, because FIT detected a limit (most likely CCA limit) and had to throttle back
> *D* followup for *C* ~ but the reasoning purely was, because it reached ProcHot limit yet not reaching THM set limit. Soo ever 10c it lost 100mhz maximum boost (an issue on 6 cores, but unclear if dual CCD PROCHOT is really accurate & extended)
> * mostly it's *B* only. Cores are far more than capable but by default are plain simply overvolted soo they reach *C* first. They reach an artificial 1.4v wall
> (from 1.45 ~ 1.55v wall guys mileage & limit, will vary by CPU "version")
> _soo before they even get the ability to reach potential high clocks - they are throttled back as VID was *too high for FIT*_
> 
> Single Core is crashing ~ Usage;
> 
> if #3 out of 5 (0-6) cores, is unstable ~ then you give this core more negative CO offset (if *B* is the reason. But it's close to always this reason, soo you try this first)
> if #3 continues to crash, you put it back where it was by AMD (values change magnitude, they do not override AMDs binning !) but you give everything around it a negative CO ~ soo dLDO will leave more for this "bad" core (this is now the case *A* in the core being just too hungry and not getting enough voltage ~ but this is very rare and close to never the case, as cores all are binned -/+ 30 CO steps by AMD unless it's an 6 core)
> Core by this time should be stable. If not, you continue in bigger steps. -2 all cores except this one, soo global VID remains identical
> (if scenario *C* is not reached and req vid doesn't surpass FIT-Pre-VID hardlimit)
> At this point you finally should have solved the dropping core issue ~ if the "unstable/drop" was not caused in the first place by being throttled back by reason *C or D *~ by reason FIT, not core quality
> 
> Boost is not reachable, cores are not first stage PPT, TDC, EDC throttled ~ but Strap is applied;
> Cores will be package throttled , but you didn't figure the reason why.
> If they are not PPT, TDC, EDC, THM, FIT-PRE-VID, PROCHOT ~ throttled & all of these 5 are held
> (FIT PRE will drop once prochot limit has reached, systematically and so lower "FIT Limit" systematically ~ which is extended by the scalar but not fully disabled)
> 
> 
> 
> 
> 
> 
> 
> 
> Also if cTDP & Package Power limit in AMD CBS - NBIO , are lifted (i put 400W because it's high enough)
> One event that is still possible , aside from *C *is
> - Cores being stable, yet being throttled back (package throttle) mostly belongs to lack of VDD18 rail or lack of VDDG CCD (which also is capable to "crash cores" without it being a VID reason)
> ======================================================
> I'll write next time a more clear tutorial how to work on "Single Core is crashing" scenario
> ~ once Hydra 1.0 (or free public version) has released and users have to experiment "in-windows" with CO limits
> As Hydra will also give you a "diagnosed" BIOS Value ~ field, it makes sense to catch support where it's needed. The scenario where the user extends fixed CO in order to extend V/F curve
> Just remember the quote
> ======================================================
> 
> What people use as a shortcut = -30 all core
> Is to prevent FIT-PRE-V to throttle back. as cores will move below this limit & try to reach the frequency
> What users do not think, is that -30 = -110mV ~ -120mV taken away VID / while Frequency to Voltage strap, will be tried to be set
> Either they
> A ~ reach the strap and have good cores, yet Effective clock never reaches that frequency
> B ~ they pull everything else down, because cores are not capable to run at individual frequency. CCX Delta & CCD Delta are a thing, but under closed disclosure. Cores have to run at the lowest frequency strap one core in the chain runs at ~ unless the core is fully hibernated, but not just idle-suspended
> 
> The "easy mode" is to run a global magnitude of -30 , and just add positive vcore offset
> Positive vcore offset by VRMs is not detected inside the FIT-PRE-V scale.
> FIT-PRE only checks requested VID , but never supplied voltage
> FIT does check global supplied voltage ~ but their range lies in the 1.5+. Soo it only throttles on the 4th stage (emergency package throttle) if you overdo supplied positive vcore
> * Yet again, this information about the range is not shareable till X user under NDA leaks it and it get's public knowledge
> Sensor max voltages are far higher and bios offset allows to use a +100mV range at least.
> 
> Keep my word that Vermeer samples still have a lot of range in them, and +200 Mhz override ~ as SMNCLK peak is too low. AMD has to finally free this limiter and allow us back +500Mhz overrides & more CO ranges.
> They should move this only inside AMD OVERCLOCKING ~ soo users are own fault if they have unstable units. Not artificially limit is sub 1.5v.


As far as you guys don't advise users skewing stock default voltages, introducing vcore offset to the default CO curve, when one start tuning its AMD cpu, everything is fine!

The opposite is not, it is literally lying to less knowledgable user, that seeks help to tune their cpu!

@Vei, i didn't read your post, as usual, dunno what you wrote into and if your post says something coherent or not.
Please, once again, make an effort to condense your thought.
Or open a new thread, detailing all the huge knowledge you own, in the first posts, that we can have a clear reference of everything you said, thank you!


----------



## Bal3Wolf

Im joining the party with you guys seeing what i can pull out of this 5950x with PBO and CO Right now i have -10 on all of ccd1 and -20 on ccd2 working on it still but pretty steady staying above 4.6Ghz in cb23 on all core, i am testing with corecycler now to see how stable it is any tips >?


----------



## TimeDrapery

Spoiler






1devomer said:


> As far as you guys don't advise users skewing stock default voltages, introducing vcore offset to the default CO curve, when one start tuning its AMD cpu, everything is fine!
> 
> The opposite is not, it is literally lying to less knowledgable user, that seeks help to tune their cpu!
> 
> @Vei, i didn't read your post, as usual, dunno what you wrote into and if your post says something coherent or not.
> Please, once again, make an effort to condense your thought.
> Or open a new thread, detailing all the huge knowledge you own, in the first posts, that we can have a clear reference of everything you said, thank you!






@1devomer 

Yeah, this has been a fairly commonly found recommendation on how to go about tuning Curve Optimizer for some time now... Perhaps it's talked about in some of those posts that you didn't read


----------



## 1devomer

TimeDrapery said:


> @1devomer
> 
> Yeah, this has been a fairly commonly found recommendation on how to go about tuning Curve Optimizer for some time now... Perhaps it's talked about in some of those posts that you didn't read


Well, i'm happy to know it was already the case, not a big deal if being repeated, i guess.
But thank you for the head up, i will go back and read what i missed!


----------



## PJVol

Veii said:


> dLDO_Injector will balance global requested VID, up to core requested VID ~ since AGESA 1.1.8.X


Isn't dLDO's functioning quite the opposite way?
I mean, tuning per core VID's down from requested VID rather than turning global VID up, i.e. something, that might be called "debalancing" in that case? 
Or did I misinterpret what was wrote?

Am I right assuming we talk about CI level (charge injection) here, or there's some other use case for dLDO's unknown for me?


----------



## ManniX-ITA

PJVol said:


> Isn't dLDO's functioning quite the opposite way?
> I mean, tuning per core VID's down from requested VID rather than turning global VID up, i.e. something, that might be called "debalancing" in that case?


From my understanding the dLDO is the power regulator for the core, it will give more or less core VID upon needs, not just less.
So I guess the above means if the injector needs to give more VID than the actual vCORE voltage will ask to raise it.
Guessing right?


----------



## PJVol

ManniX-ITA said:


> Guessing right?


IDK, tbh  since according to AMD, they are functioning together with CKS just for additional power saving, i.e. reducing VID for the cores, according to their capabilities.
Hence, still wanted to hear what Veii meant.



ManniX-ITA said:


> it will give more or less core VID upon needs, not just less.


Are you sure LDOs can increase input voltage at all?
AFAIK they are designed mostly for lowering operating voltage for various IC.


----------



## AmateurRanger

I think I can finally rest in peace.. Finally broke 1.6k/12k simultaneously with one set of CO, and seems stable after few iterations of CoreCycler and hours of gaming, needs to run overnight to be sure.


----------



## Frosted racquet

Can you share your settings? Cooling?


----------



## PJVol

Frosted racquet said:


> Can you share your settings? Cooling?


Didn't he said he can rest in peace?


----------



## AmateurRanger

Frosted racquet said:


> Can you share your settings? Cooling?


PBO Limit set to motherboard (Aorus B550I), Auto OC +200, that's it. Cooling is under CM 280 AIO


----------



## Frosted racquet

Can you check Effective clock in HWInfo during Multi core test? I have difficulty going near 12k multi and that's with a big negative CO, so I'm really curious about your effective clocks


----------



## AmateurRanger

Frosted racquet said:


> Can you check Effective clock in HWInfo during Multi core test? I have difficulty going near 12k multi and that's with a big negative CO, so I'm really curious about your effective clocks


Oh I forgot to mention this was run in safe mode, unless there's another wat to check freq. I'm not sure I can get anything meaningful lol

Also I'm not on a aggressive negative curve per se. I believe its 22, 8, 17, 10, 17, 20


----------



## Frosted racquet

OK, I thought you haven't used CO at all since you haven't mentioned it in the previous post above


----------



## Veii

PJVol said:


> Isn't dLDO's functioning quite the opposite way?
> I mean, tuning per core VID's down from requested VID rather than turning global VID up, i.e. something, that might be called "disbalancing" in that case?
> Or did I misinterpret what was written?


The opposite of injection
Let me copy this

















I have a fixed throttle at 1.4v & a big issue with ProcHOT being far too low
In this FIT-PRE math ,FIT Q also falls into it
Mostly the FIT limit that is visible on Tool.exe (which depends on scalar and thermal distance on prochot ~ should be prochot not THM)
Reuploading it again ~ credits ASUS XOC Community (HWBot), probably Shamino but i'm not entirely sure

Nearly always it's that , the reason for frequency throttle
At any voltage you provide it

dLDO has more usecases ~ it's not only a low voltage stabilizer , although strongly used to balance voltage, when/if cores hibernate and are fully gone ~ not sleep or park
It's main purpose is to smooth voltage supply between cores, while cores all have individual c-states and individual p-state targets
It differentiates between the 3 p-states which bellow P0 3.7 or 3.8ghz , Global-C State control generates C & P States
While Above P0, it's Precision Boost ,
which factors in explained *first* stage mainboard limits,* 
2nd* stage voltage request limit + checkup with current EDC FUSE limit & prochot,
*3rd* stage vid to strap-frequency limit + FIT Q quality per core,
and *4th* stage if inside emergency voltage throttle or outside (which i think also covers VDD & remain power voltages)

*2nd* & *4th* stage is a common issue we memOCer have with open limits (while on stock everyone already is not even passing 1st stage, board based power throttle)
Mostly *2nd* stage, is what people have when they open up the limits and the unit overvolts (more than it already does on stock)

Sadly i've tried couple of combinations with voltage balancing, and CO trickery / faking trickery (telemetry faking get's detected , if the range is too big)
But FIT-PRE is bothering too much.
It doesn't check SVI2 voltage ~ that's 4th stage part, but it does check if Voltage/Frequency straps align on VID & if it doesn't, it either throttles back voltage first or package throttles down fabric ~ to maintain stability

Probably the best thing somebody could do (if not dependent on Hydra in OC_MODE)
is to figure out CO's,
push the worst cores down , as they will request too much VID
Let them stabilize as low as they can on CO , soo they are not the bottleneck for the other "good cores"
And then push everything step by step down together -2 , till you get your target boost frequency

Start with +100 boost override , till every core can reach and hold this strap (also together, if you aren't reaching CCA EDC FUSE LIMIT ~ 2nd stage)
Then start to drop CO further into negative, soo it will help cores reach higher frequency. -2 every +25mhz strap
Be sure effective frequency keeps being hold & if a core is holding frequency (also single) but not crashing, then try to give everything around it -1 except this "bad" core ~ resulting in more VID being left for this bad core, to reach it

Just again, if cores are crashing - it's a missmatch of voltage to strap (and needs less CO)
if cores are not crashing but not reaching boost
(it's likely that other cores request too much voltage and global VID exceeds FIT-PRE limit ~ well 50mV less than FIT PRE, but this wall everyone has to find for themself)
I again am hardcapped at 1.4v ~ by 1.45v FIT-PRE

EDIT:
Every core by AMD is binned to pass specific ACPI rating, and the +/- 30 CO range @ 4.6ghz , some at 4.55
If it doesn't pass it - it will be fused away unless it's a 6 core 
Soo the reason for it crashing at low CO is likely something around it taking voltage away - or it overvolting itself by trying to stay on a high strap , while reaching throttle VID wall


Spoiler: EDIT 2:



For me Hydra, worked out in holding 4.85 on AVX2 tests ~ compared to what i did by hand
The tool itself "different", soo i still prefer my PBO - but the CO finding feature is useful















On dual CCD units , i can see powermanagement and power distribution (throttling) being an issue - why FAST CO doesn't work out
Also it appears that according to the tool ~ my bad core 04 & 05 are soo worse, that they need to reach the lowest CO state , for them not to VID Request throttle :') ~ i got better results with 10ish mV positive vCore offset. Required less negative CO , soo had more boosting range (if we where capable to run more than +200 boost override)
My suggestion, start with Safe CO and drop it further and further -2 till you reach your target frequency - and cores do not crash
If you can not reach it but cores start to crash ~ start to find which one it is and push that one down further on CO
Ignore strap frequency ~ when cores are crashing, as they will only crash if VID to Freq is missmatching. They will just not reach higher boost if they are bad (as they lack required VID for this higher strap) but clearly not crash


----------



## Bal3Wolf

well i tested for about the last 12 hrs off and on each core till it didn't throw errors anymore fairly happy with it holding 4630-4660Mhz almost 30k on cb23.


----------



## RosaPanteren

Hi

Any input in regards to my questions will be highly appreciated!

This is a gaming PC and used daily for 4-6 hours. CPU is water cooled in a loop of 2x360 + a 240 slims rad with 2xD5 pumps, cpu block is TechN with LM between colde plate and IHS.

All rads get cold air directly from the window, so I stay at 20c +- 2c most of the time, even if I run a heavy stress test like P95 or Y-Cruncher

So I have worked a bit on the PBO CO and currently got a "stable" curve of this:

No scalar
No override boost
Limits set to auto
CPU voltage set to auto



Spoiler: Bios CO
























This CO yields these CB results:



Spoiler: CB























This curve have been tested for 6 hours of YC test 15, 16 and 19, and all YC test for another 6 hours, along with CoreCycler for 4 hours, and Linpack X for 4 hours with 10GB stress test.

Linpack shows approx 680 GFlops, during a the 4 hour run the GFlops varied on avg. by 3 between the different runs, e.g 682, the next might be 679....



Spoiler: Linpack X GFlops variation















Is this variation of GFlops within normal, this run is in normal win 10 with all services running like win defender ect.?


Global C-state is disabled because I would get random reboots with it set enabled/auto.

However when benching with it on I see quite some performance increase and therefor wonder if there are anything I could do to stabilize Global-C state enabled?




Spoiler: Global C-state



Global C-State on:









Global C-state off yields about singel 695 and multi 13 800

Global C-State on yields CB15 multi score of 5300-5333, while off yields 5246-5289













Also setting PBO limits to auto yields the best performance but also quite high temps. Setting manual limits, even with higher limits than I see used for PPT, TDC and EDC in HWinfo results in lower performance, 10c lower temps on avg. and lower power draw across the limits(PPT,TDC,EDC).

With limits set to auto I see PPT of 280w, TDC 185A and EDC 215A running YC stress tests.

The 280w power draw seems quite high, what are other 5950x owners seeing running YC and is the 280W draw with in reasonable safe range?

Is there any way I could find out what magical limits auto sets, and from there work on lowering TDC in order decrease temps a bit?



Spoiler: Hwinfo















Or is there some other route in order to optimize the curve further I should explore?

I tried to set CPU vlotage to positive offset mode with +0.0125v but that seemed to destabilize the curve. Should I try lower voltage offset values?

Sorry for all the questions, but I hope someone have time to give me some pointers


----------



## Luggage

RosaPanteren said:


> Hi
> 
> Any input in regards to my questions will be highly appreciated!
> 
> This is a gaming PC and used daily for 4-6 hours. CPU is water cooled in a loop of 2x360 + a 240 slims rad with 2xD5 pumps, cpu block is TechN with LM between colde plate and IHS.
> 
> All rads get cold air directly from the window, so I stay at 20c +- 2c most of the time, even if I run a heavy stress test like P95 or Y-Cruncher
> 
> So I have worked a bit on the PBO CO and currently got a "stable" curve of this:
> 
> No scalar
> No override boost
> Limits set to auto
> CPU voltage set to auto
> 
> 
> 
> Spoiler: Bios CO
> 
> 
> 
> 
> View attachment 2526349
> 
> 
> View attachment 2526350
> 
> 
> 
> 
> This CO yields these CB results:
> 
> 
> 
> Spoiler: CB
> 
> 
> 
> 
> View attachment 2526351
> 
> View attachment 2526352
> 
> 
> 
> 
> This curve have been tested for 6 hours of YC test 15, 16 and 19, and all YC test for another 6 hours, along with CoreCycler for 4 hours, and Linpack X for 4 hours with 10GB stress test.
> 
> Linpack shows approx 680 GFlops, during a the 4 hour run the GFlops varied on avg. by 3 between the different runs, e.g 682, the next might be 679....
> 
> 
> 
> Spoiler: Linpack X GFlops variation
> 
> 
> 
> 
> View attachment 2526355
> 
> 
> 
> 
> Is this variation of GFlops within normal, this run is in normal win 10 with all services running like win defender ect.?
> 
> 
> Global C-state is disabled because I would get random reboots with it set enabled/auto.
> 
> However when benching with it on I see quite some performance increase and therefor wonder if there are anything I could do to stabilize Global-C state enabled?
> 
> 
> 
> 
> Spoiler: Global C-state
> 
> 
> 
> Global C-State on:
> View attachment 2526356
> 
> 
> Global C-state off yields about singel 695 and multi 13 800
> 
> Global C-State on yields CB15 multi score of 5300-5333, while off yields 5246-5289
> View attachment 2526357
> 
> 
> 
> 
> 
> 
> Also setting PBO limits to auto yields the best performance but also quite high temps. Setting manual limits, even with higher limits than I see used for PPT, TDC and EDC in HWinfo results in lower performance, 10c lower temps on avg. and lower power draw across the limits(PPT,TDC,EDC).
> 
> With limits set to auto I see PPT of 280w, TDC 185A and EDC 215A running YC stress tests.
> 
> The 280w power draw seems quite high, what are other 5950x owners seeing running YC and is the 280W draw with in reasonable safe range?
> 
> Is there any way I could find out what magical limits auto sets, and from there work on lowering TDC in order decrease temps a bit?
> 
> 
> 
> Spoiler: Hwinfo
> 
> 
> 
> 
> View attachment 2526358
> 
> 
> 
> 
> Or is there some other route in order to optimize the curve further I should explore?
> 
> I tried to set CPU vlotage to positive offset mode with +0.0125v but that seemed to destabilize the curve. Should I try lower voltage offset values?
> 
> Sorry for all the questions, but I hope someone have time to give me some pointers


I see the best results tuning PBO values so they never quite reach 100% no matter what load I throw at it. Max ppt with p95/y-cruncher. Max edc with occt mem test/mt5. Setting tdc about 40 under edc. CB is a bit lighter so can drop values 5% or so. (Though working with trying veiis trickery of no limits EDC, so far I’ve not gotten it to really work…)

This only works great for multi core though, sc likes lower limits.


----------



## Obtendo

I can run CoreCycler for 12 hours without errors using Prime95 and y-cruncher, but can't do 2 minutes of Apex Legends without WHEA BSOD. Good ideas regarding what tests I could run to simulate games with low CPU load appreciated.


----------



## PJVol

Veii said:


> Just again, if cores are crashing - it's a missmatch of voltage to strap (and needs less CO)
> if cores are not crashing but not reaching boost
> (it's likely that other cores request too much voltage and global VID exceeds FIT-PRE limit ~ well 50mV less than FIT PRE, but this wall everyone has to find for themself)
> I again am hardcapped at 1.4v ~ by 1.45v FIT-PRE


Am I right to assume that if precalculated based on CO core VID lacks corresponding V/F strap, this is where CKS is activated, which can clerarly be observed watching for the effective clocks?
Is it what you mean, saying effective frequency should hold?
Thanks for tool, btw!


----------



## Frosted racquet

@Obtendo What CPU do you have? It's recommended to run the test 12h _per core_ as a general rule for achieving ""absolute stability"". If you're running a 6 core cpu then 6*12h=72h
Unfortunately, most people don't have the time patience to go to such lengths, especially for 16 core parts.


----------



## Obtendo

Frosted racquet said:


> @Obtendo What CPU do you have? It's recommended to run the test 12h _per core_ as a general rule for achieving ""absolute stability"". If you're running a 6 core cpu then 6*12h=72h
> Unfortunately, most people don't have the time patience to go to such lengths, especially for 16 core parts.


5800X. Yes, I noticed the recommendation. I've run several 12h runs cores combined, but no 12h per core runs. Yes, I can do that, but I was just curious if it was any test configuration that would more specifically simulate issues Apex Legends can produce within 2 minutes for some reason.

I'll continue running CoreCycler while also attempting to get more insight into how the cores are loaded by Apex Legends when crashing.


----------



## Iarwa1N

Veii said:


> Bit hard to avoid length, when the question/request is on a big unclear/unanswered topic
> Comes over bit rude, defining the way of asking for help
> 
> First important lesson;
> 
> dLDO_Injector will balance global requested VID, up to core requested VID ~ since AGESA 1.1.8.X
> Core requested VID will pass through FIT, in FIT PRE-Voltage limit (usually 50mV higher than the invisible voltage throttle wall)
> 2nd stage , it checks whenever this allowed voltage ~ passes within PPT, THM, TDC, EDC limit. Rather recognizes if amperage of X amount of cores for Y global VID requested ~ passes over set EDC FUSE limit (A)
> later cores frequency target check and so request Z VID by the V/F curve, by the architecture (mind you, every sample has a different range ~ they are not on the same scale)
> 
> What means "unstable" ~ is it;
> 
> *A* core can not hold frequency under AVX ! selected workload (loadline to droopy ?, AVX2 has a fixed voltage drop + loadline droop)
> *B* core is more than capable , but global VID was too low and other bad cores took away too much priority and dLDO ruined boost
> *C* also* B* ~ BUT, higher strap-stepping voltage couldn't be provided, because FIT detected a limit (most likely CCA limit) and had to throttle back
> *D* followup for *C* ~ but the reasoning purely was, because it reached ProcHot limit yet not reaching THM set limit. Soo every 10c it lost 100mhz maximum boost (an issue on 6 cores, but unclear if dual CCD PROCHOT is really accurate & extended) ~ mostly happens on AVX2 loads titled under CCA throttle
> * mostly it's *B* only. Cores are far more than capable but by default are plain simply overvolted soo they reach *C* first. They reach an artificial 1.4v wall by FIT
> (from 1.45 ~ 1.55v wall guys mileage & limit, will vary by CPU "version")
> _soo before they even get the ability to reach potential high clocks - they are throttled back as VID was *too high for FIT*_
> 
> Single Core is crashing ~ Usage;
> 
> if #3 out of 5 (0-5) cores, is unstable ~ then you give this core more negative CO offset (if *C* is the reason. But it's close to always this reason _~the bad core requesting too much VID~_, soo you try this first)
> if #3 continues to crash, you put it back where it was by AMD (values change magnitude, they do not override AMDs binning !) but you give everything around it a negative CO ~ soo dLDO will leave more for this "bad" core (this is now the case *A* in the core being just too hungry and not getting enough voltage ~ but this is very rare and close to never the case, as cores all are binned -/+ 30 CO steps by AMD unless it's an 6 core)
> Core by this time should be stable. If not, you continue in bigger steps. -2 all cores except this one, soo global VID remains identical
> (if scenario *C* is not reached and req vid doesn't surpass FIT-Pre-VID hardlimit)
> At this point you finally should have solved the dropping core issue ~ if the "unstable/drop" was not caused in the first place by being throttled back by reason *C or D *~ by reason FIT, not core quality
> 
> Boost is not reachable, cores are not first stage PPT, TDC, EDC throttled ~ but Strap is applied;
> Cores will be package throttled , but you didn't figure the reason why.
> If they are not PPT, TDC, EDC, THM, FIT-PRE-VID, PROCHOT ~ throttled & all of these 5 are held
> (FIT PRE will drop once prochot limit has reached, systematically and so lower "FIT Limit" systematically ~ which is extended by the scalar but not fully disabled)
> 
> 
> 
> 
> 
> 
> 
> 
> Also if cTDP & Package Power limit in AMD CBS - NBIO , are lifted (i put 400W because it's high enough)
> One event that is still possible , aside from *C *is
> 
> Cores being stable, yet being throttled back (package throttle) mostly belongs to lack of VDD18 rail or lack of VDDG CCD (which also is capable to "crash cores" without it being a VID reason)
> ======================================================
> I'll write next time a more clear tutorial how to work on "Single Core is crashing" scenario
> ~ once Hydra 1.0 (or free public version) has released and users have to experiment "in-windows" with CO limits
> As Hydra will also give you a "diagnosed" BIOS Value ~ field, it makes sense to catch support where it's needed. The scenario where the user extends fixed CO in order to extend V/F curve
> Just remember the quote
> ======================================================
> 
> What people use as a shortcut = -30 all core
> Is to prevent FIT-PRE-V to throttle back. as cores will move below this limit & try to reach the frequency
> What users do not think, is that -30 = -110mV ~ -120mV taken away VID / while Frequency to Voltage strap, will be tried to be set
> Either they
> A ~ reach the strap and have good cores, yet Effective clock never reaches that frequency
> B ~ they pull everything else down, because cores are not capable to run at individual frequency. CCX Delta & CCD Delta are a thing, but under closed disclosure. Cores have to run at the lowest frequency strap one core in the chain runs at ~ unless the core is fully hibernated, but not just idle-suspended
> 
> The "easy mode" is to run a global magnitude of -30 , and just add positive vcore offset till it's stable
> (till the worst core surely has enough voltage & all cores hold fully the peak freq strap)
> Positive vcore offset by VRMs is not detected inside the FIT-PRE-V scale.
> FIT-PRE only checks requested VID , but never supplied voltage
> FIT does check global supplied voltage ~ but their range lies in the 1.55+. Soo it only throttles on the 4th stage (emergency package throttle) if you overdo supplied positive vcore
> * Yet again, this information about the range is not shareable till X user under NDA leaks it and it get's public knowledge
> Sensor max voltages are far higher and bios offset allows to use a +100mV range at least.
> 
> Keep my word that Vermeer samples still have a lot of range in them, and +200 Mhz override ~ as SMNCLK peak, is too low. AMD has to finally free this limiter and allow us back +500Mhz overrides & more CO ranges.
> They should move this only inside AMD OVERCLOCKING ~ soo users are own fault if they have unstable units. Not artificially limit being sub 1.5v.
> 
> EDIT:
> The only reason , users -30 Global-CO passes ~ is because CPUs are binned inside -/+ 30 CO range out of the factory (not always but most of the time posts)
> If higher samples core quality (even bronze) does not pass this - it's reused as lower core sample or fully a single CCD unit with "different" V/F curve
> Dual CCD 6 & 8 core units - generally have a broken V/F curve of their Dual-CCD brothers. Soo often these samples fail to hold AMD's CO range by default, as VID per frequency strap (V/F) is messed up on such (reminder ~ 5600X, 5800X, 5900X, 5950X have different V/F Curve)
> These need generally a bit of positive offset, to fix WHEA #18 issues on stock stock (X1 scalar) without boardpartner cheatery enhancers
> Some users like me, also combine then droopy loadline + positive vcore ~ to as best as possible match Supplied TEL-V with VID-V
> 
> 
> Spoiler: Reused Example


@Veii I was trying to apply your suggestions to my PBO settings, I couldn't figure out what the actual EDC is while gaming; 
While CS:GO is open and active window, the Tool utility is showing EDC as 220, but if I check the EDC with HWInfo it is way lower 55ish. What should be my EDC limit according to these values?

The other question I got is in Tool application the PPT is showing as the real frequency limiter for me during CS:GO even though I set the PPT and cTDP as 400w. What should I do to make the boost go to +200. CPU is 5900x and I have a custom PBO as "30,30,26,21,30,15,30,30,30,17,30,20" with +0.05v positive offset.


----------



## PJVol

Iarwa1N said:


> if I check the EDC with HWInfo it is way lower 55ish


If by any chance you flashed the latest beta 1.2.0.4 based fw? If so, then there could be some issues with monitoring soft.
I'm not sure, but the version of pm_table, reported by a new smu fw, may differ noticeably, compared to 38.08(9).05, and various monitoring apps just can't keep up yet.


----------



## Iarwa1N

PJVol said:


> If by any chance you flashed the latest beta 1.2.0.4 based fw? If so, then there could be some issues with monitoring soft.
> I'm not sure, but the version of pm_table, reported by a new smu fw, may differ noticeably, compared to 38.08(9).05, and various monitoring apps just can't keep up yet.


I am using the unlocked A21 bios for the Unify X based on Agesa 1.2.0.1.


----------



## Taraquin

I can do - 30 CO +50 and have run this for 3 months without problems, but the last month I tried +200 pbo. The second best core failed at - 30 on corecycler after 3 mins, but became rock solid in testing at - 29. Problem is I get rare reboots during the night, about once a week. I mine at nights, but only with gpu. It seems there are some very low loads now and then that crashes a core, but which one? I tried - 25 on the worst core and same thing happends so I guess it's one of the others. I ran the prime95 and ycruncher 6 times in a row, passed all way. Any idea how to identify the 'bad' core?


----------



## Bal3Wolf

Taraquin said:


> I can do - 30 CO +50 and have run this for 3 months without problems, but the last month I tried +200 pbo. The second best core failed at - 30 on corecycler after 3 mins, but became rock solid in testing at - 29. Problem is I get rare reboots during the night, about once a week. I mine at nights, but only with gpu. It seems there are some very low loads now and then that crashes a core, but which one? I tried - 25 on the worst core and same thing happends so I guess it's one of the others. I ran the prime95 and ycruncher 6 times in a row, passed all way. Any idea how to identify the 'bad' core?


I been testing all weekend and what i have found is some times cores randomly fail out of no where even after lots of passes that might be what causes a bsod if the core is to close to stable and unstable maybe back all cores down 1 click. Just finished running hydra 5-6hrs lol it has a reconmmended value for CO values now for bios most my numbers were spot on but my bad core needed a pos 5 i had it at neg 1 so i changed that and a few other minior ones will see how the system responds next few days.


----------



## Obtendo

Taraquin said:


> Problem is I get rare reboots during the night, about once a week. I mine at nights, but only with gpu. It seems there are some very low loads now and then that crashes a core, but which one? I tried - 25 on the worst core and same thing happends so I guess it's one of the others. I ran the prime95 and ycruncher 6 times in a row, passed all way. Any idea how to identify the 'bad' core?


Have you searched/filtered system event log for events with source "WHEA-Logger"? Could list the faulting thread. Core 0 = thread 0 and 1 (...)


----------



## noxious89123

Taraquin said:


> I can do - 30 CO +50 and have run this for 3 months without problems, but the last month I tried +200 pbo. The second best core failed at - 30 on corecycler after 3 mins, but became rock solid in testing at - 29. Problem is I get rare reboots during the night, about once a week. I mine at nights, but only with gpu. It seems there are some very low loads now and then that crashes a core, but which one? I tried - 25 on the worst core and same thing happends so I guess it's one of the others. I ran the prime95 and ycruncher 6 times in a row, passed all way. Any idea how to identify the 'bad' core?


Look in the event viewer for something that looks like this;

WHEA-Logger Event ID 18 02/09/2021 15:18:48

A fatal hardware error has occurred.

Reported by component: Processor Core
Error Source: Machine Check Exception
Error Type: Cache Hierarchy Error
Processor APIC ID: 0 

In this case, it was my Core 0 that failed. Same scenario as you, random reboot in the middle of the night with minimal load. I tweaked my CO setting from -28 to -27 for that core and haven't had any problems since.


----------



## PJVol

Bal3Wolf said:


> Just finished running hydra 5-6hrs lol it has a reconmmended value for CO values now for bios most my numbers were spot on but my bad core needed a pos 5 i had it at neg 1 so i changed that and a few other minior ones will see how the system responds next few days.


Yeah, it calculate CO based on VID rating in a specific workload, and I used basically the same set of values for a months,
except for the 2nd best core, which has V/F/T curve very different from 1st best, despite actually being 2nd best, if tested individually.
The issue is that in multi-core loads, depending on test conditions, it may be either 3rd or 4th, and as a result, it'd instantly crash if its magnitude is set to proposed value.


----------



## Taraquin

Bal3Wolf said:


> I been testing all weekend and what i have found is some times cores randomly fail out of no where even after lots of passes that might be what causes a bsod if the core is to close to stable and unstable maybe back all cores down 1 click.


Will try that 


noxious89123 said:


> Look in the event viewer for something that looks like this;
> 
> WHEA-Logger Event ID 18 02/09/2021 15:18:48
> 
> A fatal hardware error has occurred.
> 
> Reported by component: Processor Core
> Error Source: Machine Check Exception
> Error Type: Cache Hierarchy Error
> Processor APIC ID: 0
> 
> In this case, it was my Core 0 that failed. Same scenario as you, random reboot in the middle of the night with minimal load. I tweaked my CO setting from -28 to -27 for that core and haven't had any problems since.


Thx for the advice both of you. I found 2 whea 18 errors on both core 0 and 1, tried adjusting both to - 29 now to see what happends  The errors on 0 was before I adjusted. None after - 29


----------



## Taraquin

Obtendo said:


> Have you searched/filtered system event log for events with source "WHEA-Logger"? Could list the faulting thread. Core 0 = thread 0 and 1 (...)


Thx, found it!


----------



## thigobr

PJVol said:


> Yeah, it calculate CO based on VID rating in a specific workload, and I used basically the same set of values for a months,
> except for the 2nd best core, which has V/F/T curve very different from 1st best, despite actually being 2nd best, if tested individually.
> The issue is that in multi-core loads, depending on test conditions, it may be either 3rd or 4th, and as a result, it'd instantly crash if its magnitude is set to proposed value.


 Where can I find the CO recommendation? I ran the diagnostics but it only show some weird values and not the -30:+30 interval one would expect to use directly on the BIOS


----------



## Bal3Wolf

thigobr said:


> Where can I find the CO recommendation? I ran the diagnostics but it only show some weird values and not the -30:+30 interval one would expect to use directly on the BIOS


Scroll up your log some its listed alittle further up.


----------



## error-id10t

Not sure if right thread but I'm seriously questioning OC 5600X. 

I've done my max and confirmed via y-cruncher it's stable. So I do get the 4.85 single and 4.7 for Multi because of the ProcHot and Vid limits. That's fine for hwbot scores etc. But I've also simply put cores to -30 with no boost and that loses 30 points in single core and about 80 points in multi with no difference in real life / games (yes I left PPT, TDC and EDC the same for both as I don't want it neutered anymore by AMD). But with Prochot and VID we just can't get much out of it?


----------



## bebius

PJVol said:


> bebius
> 
> 
> 
> 
> 
> 
> 
> www.overclock.net
> 
> 
> 
> 
> How's your new cpu?


Just got the replacement for 5600X. Fwiw AMD was perfect regarding the RMA. It's a newer batch with a manufacture date from the middle of July.
It passed CC at bios defaults for a couple of iterations (edit: Unlike my previous sample).
Then, I ran a CB single test with zero CO counts @ +200MHz, and I got the following:









I guess it's nice that I'm getting max boost, although I can see that it's the perf #1/2 core is used more than the perf #1/1 one.


----------



## PJVol

bebius said:


> I guess it's nice that I'm getting max boost, although I can see that it's the perf #1/2 core is used more than the perf #1/1 one.


Good to know you're fine now)
As for preferred cores, in CPPC rating two best cores are quite often swapped.
You can see your Core 4 even with streched clocks cant reach target frequency of 4850mhz, so judging by single core VID's core 0 is better. Lets see what will multicore test show.


----------



## mongoled

1devomer said:


> Well, i'm happy to know it was already the case, not a big deal if being repeated, i guess.
> But thank you for the head up, i will go back and read what i missed!


I dont know if you have done this yet, but you really should not dismiss the knowledge that Veii is providing because its a little too long for your liking

 

I do agree that his posts are "intense" but he is doing his best to relay inportant aspects of "what we needs to know" if we want to take full advantage of CO.

The manner that you dismissed it is a little confusing to me as I have read your escapades with the BIOS hacking on your motherboard so understand that you understand the concept that some things you cant just skimp over.

😃😃

As with BIOS hacking you need to know how to handle your 'tools', Veii is giving us the 'tools' on how to handle CO effectivley


----------



## bebius

PJVol said:


> Good to know you're fine now)
> As for preferred cores, in CPPC rating two best cores are quite often swapped.
> You can see your Core 4 even with streched clocks cant reach target frequency of 4850mhz, so judging by single core VID's core 0 is better. Lets see what will multicore test show.


Here's the pic from CB multi:


----------



## ManniX-ITA

bebius said:


> I guess it's nice that I'm getting max boost, although I can see that it's the perf #1/2 core is used more than the perf #1/1 one.


Seems to be a nice sample!
It's normal that you see more usage on #1/2, it's the Core 0 and some processes can only run there.


----------



## PJVol

bebius said:


> Here's the pic from CB multi:


Yeah, Core 0 a little bit better, i.e. needs 3-4 mv less in allcore, unless dLDO's did its job there. 
Are you sure you didn't use CO yet? ) And what was the ambient temp throughout the tests?


----------



## bebius

PJVol said:


> Yeah, Core 0 a little bit better, i.e. needs 3-4 mv less in allcore, unless dLDO's did its job there.
> Are you sure you didn't use CO yet? ) And what was the ambient temp throughout the tests?


They curves were manually set at 0, now I have set CO to disabled:

* Single \ Multi*
















Ambient in Greece has dropped to 21C now, the cooler is a new Liquid Freezer II 240.


----------



## 1devomer

mongoled said:


> I dont know if you have done this yet, but you really should not dismiss the knowledge that Veii is providing because its a little too long for your liking
> 
> 
> 
> I do agree that his posts are "intense" but he is doing his best to relay inportant aspects of "what we needs to know" if we want to take full advantage of CO.
> 
> The manner that you dismissed it is a little confusing to me as I have read your escapades with the BIOS hacking on your motherboard so understand that you understand the concept that some things you cant just skimp over.
> 
> 😃😃
> 
> As with BIOS hacking you need to know how to handle your 'tools', Veii is giving us the 'tools' on how to handle CO effectivley




Let's stop a second here, what your own knowledge, in the first place?
Are you more knowledgeable than @Veii?
Or you're maybe saying that you are more knowledgeable than me?

Or you want maybe ask @Veii my level of knowledge?
Also, have you enough knowledge to be able to judge @Veii saying?
And have you enough knowledge to be able to judge my saying?
Do you want to evaluate the good faith of my post, my sayings, yours and the @Veii ones?

It's a sleepy slope the one you are taking here, i would be careful judging people like you are doing.

And i repeat it loud, i have nothing against @Veii, nor said i ever refuted its level of knowledge.
But i'm clearly not happy of the way he shares his information, that is not always precise and clear, as it should.
Nor it is regrouped in one place where it is easily accessible, which is not the best when things, need to be updated!

But rest assured, i don't expect to be liked, for the fact of criticizing @Veii way to post.
But hei, asking question and confute things said by your lover, is always harder, than following your lover passionately, without asking any questions ever, i guess!


----------



## ManniX-ITA

1devomer said:


> But rest assured, i don't expect to be liked, for the fact of criticizing @Veii way to post.
> But hei, asking question and confute things said by your lover, is always harder than following your lover passionately without questions, i guess!


If you can't make an effort to read Veii's posts it's your problem, you'll not be criticized for that.
But it does seem you lack basic manners and a respectful attitude.
That's something you'll be criticized a lot.


----------



## 1devomer

ManniX-ITA said:


> If you can't make an effort to read Veii's posts it's your problem, you'll not be criticized for that.
> But it does seem you lack basic manners and a respectful attitude.
> That's something you'll be criticized a lot.


No worry, i take the bullet and the criticism.

But once again, i would refrain to judging my manners.
I don't know you, you don't know me.
But yeah, feel free to go down this road and leaving your opinions.
Nevertheless, as i said, i will take the bullet!


----------



## PJVol

bebius said:


> Ambient in Greece has dropped to 21C now, the cooler is a new Liquid Freezer II 240


Strange, trying to reproduce your test conditions, and no way in hell I can make my CPU run out of ~100W PPT with CO disabled 
And temps stays below 68°C? WTH is going on? 
I don't know what happened, may be some radical changes in BIOS occured since last time I've ran CBR23 with disabled CO, but what I see looks kinda weird at least.
Here are two runs with CO disabled and enabled, Boost +200, limits 120/75/350, scalar x3.













Btw, what the score was in multicore test?


----------



## Frosted racquet

PJVol said:


> Strange, trying to reproduce your test conditions, and no way in hell I can make my CPU run out of ~100W PPT with CO disabled
> And temps stays below 68°C? WTH is going on?
> I don't know what happened, may be some radical changes in BIOS occured since last time I've ran CBR23 with disabled CO, but what I see looks kinda weird at least.
> Here are two runs with CO disabled and enabled, Boost +200, limits 120/75/350, scalar x3.
> View attachment 2526674
> View attachment 2526673
> 
> Btw, what the score was in multicore test?


Wow, cooling has a lot more influence than I expected honestly. What AGESA are you running? My scores hover around 11700k multi with +100MHz Boost, -30 CO allcore, 125w/90/130, temps around 83°.
With AGESA 1200 I could get higher effective clock by ~75Mhz and a score of 11900k.


----------



## PJVol

Frosted racquet said:


> Wow, cooling has a lot more influence than I expected honestly. What AGESA are you running? My scores hover around 11700k multi with +100MHz Boost, -30 CO allcore, 125w/90/130, temps around 83°.
> With AGESA 1200 I could get higher effective clock by ~75Mhz and a score of 11900k.


Lol, for a moment I thought you talking about intel processors 
BIOS flashed with latest 1203 patch C, but the scores were basically in the same ballpark since the beginning.
Honestly, I have a rather good sample, so pls don't worry if your score cant catch up. There are not so many such CPUs around.


----------



## bebius

PJVol said:


> Strange, trying to reproduce your test conditions, and no way in hell I can make my CPU run out of ~100W PPT with CO disabled
> And temps stays below 68°C? WTH is going on?
> I don't know what happened, may be some radical changes in BIOS occured since last time I've ran CBR23 with disabled CO, but what I see looks kinda weird at least.
> Here are two runs with CO disabled and enabled, Boost +200, limits 120/75/350, scalar x3.
> View attachment 2526674
> View attachment 2526673
> 
> Btw, what the score was in multicore test?


Temps are below 68C in the single thread test, in case you got it wrong.
Multi score was 11700.


----------



## PJVol

bebius said:


> Temps are below 68C in the single thread test, in case you got it wrong.
> Multi score was 11700.


Haven't you tried tuning CO yet? Just curious, will it handle allcore -15 or -20?


----------



## bebius

PJVol said:


> Haven't you tried tuning CO yet? Just curious, will it handle allcore -15 or -20?


Made a couple of quick runs before work. -20 and -15 gave errors in CB. With -10, I managed to pass 3-4 cycles:


----------



## PJVol

bebius said:


> Made a couple of quick runs before work. -20 and -15 gave errors in CB. With -10, I managed to pass 3-4 cycles:


Can you set CO values as follow : -9 -16 -17 -13 -10 -13 and tell if you see a difference, for example in CBR23 multi score?


----------



## ENTERPRISE

Guys, please if you cannot say anything nice, or interact nicely, just stay away from each other. A policy that tends to work very well.


----------



## bebius

PJVol said:


> Can you set CO values as follow : -9 -16 -17 -13 -10 -13 and tell if you see a difference, for example in CBR23 multi score?


Multi score dropped to 11540 from 11910, so did the clocks:








May I ask how you come up with these counts?


----------



## PJVol

Are you sure the "offset" for the core 2 is set to negative, cause it looks like it is positive instead (I did made such mistake a couple of times on my msi board )
So, double check the sign for this core's magnitude first.
And then adjust magnitude for the cores 0 and 1 to -10 and -15 respectively.


----------



## bebius

PJVol said:


> Are you sure the "offset" for the core 2 is set to negative, cause it looks like it is positive instead (I did made such mistake a couple of times on my msi board )
> So, double check the sign for this core's magnitude first.
> And then adjust magnitude for the cores 0 and 1 to -10 and -15 respectively.


My bad, it was positive indeed, I was in hurry to run it before leaving for work in the morning.
Now the test has given an error in the 3rd cycle.


----------



## PJVol

What per core test shows. Did it report which core failed?
I used to run OCCT sse or avx large per-core in this case, so that faulty core quickly showed up.


----------



## bebius

It was a CB23 run as before.
Then CC gave an error on every core almost immediately (FFT large).


----------



## PJVol

So with allcore -10, it passed fft large per-core test?


----------



## bebius

PJVol said:


> So with allcore -10, it passed fft large per-core test?


I hadn't run CC with negative values on the new CPU. I mostly ran CB and tried the suggested values.
I have now started again with CC, -10 is failing on most cores. I will go on testing and changing the values while keeping +200mhz.


----------



## PJVol

bebius said:


> I hadn't run CC with negative values on the new CPU.


Lol, I thought you meant CC, when you said it passed 3 cycles at -10.
So just ignore then what I adviced above.

What I'd consider to do first, is to figure out - what the minimum stable CO values in CC (or OCCT) for both of your best cores (i.e. 0 and 4).
Because setting the rest of the curve based on those two is the quickest and easiest way.
You can start, for example, from -4 going down in -2 step until fail, and remember the last stable value for both, then post it here and we'll try to set your whole curve in one-click


----------



## bebius

PJVol said:


> Lol, I thought you meant CC, when you said it passed 3 cycles at -10.
> So just ignore then what I adviced above.
> 
> What I'd consider to do first, is to figure out - what the minimum stable CO values in CC (or OCCT) for both of your best cores (i.e. 0 and 4).
> Because setting the rest of the curve based on those two is the quickest and easiest way.
> You can start, for example, from -4 going down in -2 step until fail, and remember the last stable value for both, then post it here and we'll try to set your whole curve in one-click


Best Core (#4) failed even at *+10* (6th 6min iter.) and max achieved clock was 4800mhz. Second best one (#0) is still running at *-7 *and hitting 4850mhz. I guess +200Mhz is too much for my sample. Do you think I should I continue lifting the curve for Core 0?


----------



## ManniX-ITA

bebius said:


> Best Core (#4) failed even at *+10* (6th 6min iter.). Second best one (#0) is still running at *-7*. I guess +200Mhz is too much for my sample. Do you think I should I continue lifting the curve for Core 0?


Could be at +200 it's too much.
But best Core failing at +10 smells like there's another Core which you validated stable and it's not.
Drove me crazy this issue a while ago.
I would set a +4 on all other cores and re-check again if you can set a negative count on Core 4.


----------



## bebius

ManniX-ITA said:


> Could be at +200 it's too much.
> But best Core failing at +10 smells like there's another Core which you validated stable and it's not.
> Drove me crazy this issue a while ago.
> I would set a +4 on all other cores and re-check again if you can set a negative count on Core 4.


I'm testing each core seperately with CC, do the other cores' counts matter?


----------



## ManniX-ITA

bebius said:


> I'm testing each core seperately with CC, do the other cores' counts matter?


Yes, you have to test one by one.
And then when you're done start again a full re-test one by one.
They influence each other.

But what I'm talking about is when a Core is unstable.
Meaning it will randomly pass Prime test and randomly fail cause the count is borderline.
When it's on the brink of instability but not enough to always fail.

This will cause all sort of random behavior on the other Cores.
I've doubted that Prime95 was working properly cause the results didn't make sense.
Sometimes my best Cores where failing with counts I knew they were stable.
Then I've found out that one bad core, in the 2nd CCD not even the 1st, was unstable and needed a +something...
Suddenly all the cores in the 1st CCD started behaving as they should have.


----------



## PJVol

bebius said:


> Best Core (#4) failed even at *+10* (6th 6min iter.) and max achieved clock was 4800mhz. Second best one (#0) is still running at *-7 *and hitting 4850mhz. I guess +200Mhz is too much for my sample. Do you think I should I continue lifting the curve for Core 0?


Can you run OCCT specifically on Core 4 like that:








and confirm it failed the same way, as in CC ?
Do SSE test first, then AVX one.


----------



## PJVol

ManniX-ITA said:


> Then I've found out that one bad core, in the 2nd CCD not even the 1st, was unstable and needed a +something...


This is what I'm trying to make people understand, that only testing individual cores doesn't make much sense.
Just direrctly applying them as is, in CO, would inevitably cause crash in multicore SSE or AVX load sooner or later.
-----------------------------------------------------------------------------
BTW, have you seen my new DIMM's ? - posted photos in DDR thread ... weird, to say the least  
They are new Ripjaw's - GVKA.


----------



## ManniX-ITA

PJVol said:


> Just direrctly applying them as is, in CO, would inevitably cause crash in multicore SSE or AVX load sooner or later.


Very tricky, it's not inevitable but it depends on what's going to be the decision by the CPU on where to floor the VIDs and frequency.
It's different on combinations of cores, all-core, PBO is enabled/disabled/scalar and gets even more complex with 2 CCD.
Wonder if there's a way to predict these decisions but it would need a very long analysis to even get a feasibility


----------



## PJVol

ManniX-ITA said:


> Wonder if there's a way to predict these decisions but it would need a very long analysis to even get a feasibility


Yeah, I intentionally haven't gone into details here, cause it would be just a one more lengthy post, with a little to no interest from anyone ))
It's a shame that people like Thestilt not participating in such type of discussions.

Just some observations got me asking, could it be that with the recent dLDO's appearance, some power management things happened twice as much as needed (curve optimizer first). What comes to mind is the first reports of 5000-system instabilities after some bios update, where presumably all those tricks were finally activated. Also there were reports of increased perfornance after 1.2.0.0 agesa, etc.


----------



## ManniX-ITA

PJVol said:


> Yeah, I intentionally haven't gone into details here, cause it would be just a one more lengthy post, with a little to no interest from anyone ))


I'd be delighted we can start a new thread on this topic...



PJVol said:


> It's a shame that people like Thestilt not participating in such type of discussions.


I guess they'd love more to spend time with proprietary (and paid) features for board manufacturers 



PJVol said:


> Just some observations got me asking, could it be that with the recent dLDO's appearance, some power management things happened twice as much as needed (curve optimizer first). What comes to mind is the first reports of 5000-system instabilities after some bios update, where presumably all those tricks were finally activated. Also there were reports of increased perfornance after 1.2.0.0 agesa, etc.


Very likely. It's still a big unknown for me but a lot definitely changed when they enabled dLDO and from 1.2.0.0.


----------



## 1devomer

ManniX-ITA said:


> I guess they'd love more to spend time with proprietary (and paid) features for board manufacturers


I guess that, when you are working for a tech company and you are under permanent NDA, Non Discosure Agreement, you can't freely give your own opinion, without being in line with the company policies!

Which mean, you can't disclose issues, ameliorations, future implementation details, really anything that would be a liability for the company!

So i don't think the main reason would be, liking playing with proprietary manufactures features!


----------



## bebius

PJVol said:


> Can you run OCCT specifically on Core 4 like that:
> View attachment 2527050
> 
> and confirm it failed the same way, as in CC ?
> Do SSE test first, then AVX one.


I'm running the tests from a remote desktop and can't remember if the four weak cores are set to -10 or not.
Anyway:
SSE gave errors after 48 minutes.
AXV passed for an hour:










PJVol said:


> This is what I'm trying to make people understand, that only testing individual cores doesn't make much sense.
> Just direrctly applying them as is, in CO, would inevitably cause crash in multicore SSE or AVX load sooner or later.


What you describe is the crashes someone can have after testing each core individually and then starts bombing multithread loads, isn't it?
However, if you test with the affinity set to a single core, shouldn't the test be independent to the other cores' settings?


----------



## PJVol

bebius said:


> I'm running the tests from a remote desktop and can't remember if the four weak cores are set to -10 or not.


Dont bother, the goal was to confirm, whether Core 0 and Core 4 failed in OCCT per-core SSE and AVX tests at the same magnitudes as in CC testing or not?
I found your result kinda suspicious, where the CPPC (or fused) best core failed to handle even zero offset at with a +200 boost, though it's quite common amongst the bronze samples.
Either you're out of luck again )), perhaps you'd rather send them back that p.o.s. and ask, wouldn't they mind to ship the normal one at last...


bebius said:


> What you describe is the crashes someone can have after testing each core individually and then starts bombing multithread loads, isn't it?
> However, if you test with the affinity set to a single core, shouldn't the test be independent to the other cores' settings?


Yes,
and the reasons behind it was partly discussed here already, some pages ago, but as Mannix said, there are many unknowns and uncertainties, thanks to amd policy regarding official documentation. For example, the latest publicly availailable BKDG is for Family 15h and 16h, which is not even about Zen (17h) at all.

Ofcourse, in per-core test the results of each core are individual, but they are part of the whole system, where said cores aside from all their usual work, interacting either thermally with their neighbors, or concurrently within a limited power budget of the whole package, or chiplet, and so on...


----------



## bebius

PJVol said:


> Dont bother, the goal was to confirm, whether Core 0 and Core 4 failed in OCCT per-core SSE and AVX tests at the same magnitudes as in CC testing or not?
> I found your result kinda suspicious, where the CPPC (or fused) best core failed to handle even zero offset at with a +200 boost, though it's quite common amongst the bronze samples.
> Either you're out of luck again )), perhaps you'd rather send them back that p.o.s. and ask, wouldn't they mind to ship the normal one at last...


I must provoke an error at stock settings again to send it back. This seems unlikely after the first hour of testing, so I think I'm gonna just set a conservative curve and call it a day if it's game stable.
Thanks for your help and @ManniX-ITA's also.


----------



## cyberloner

sir prime95 release new version


https://mersenne.org/ftp_root/gimps/p95v307b2.win64.zip


manual change prime95 cause me all error xD


----------



## TimeDrapery

PJVol said:


> Dont bother, the goal was to confirm, whether Core 0 and Core 4 failed in OCCT per-core SSE and AVX tests at the same magnitudes as in CC testing or not?
> I found your result kinda suspicious, where the CPPC (or fused) best core failed to handle even zero offset at with a +200 boost, though it's quite common amongst the bronze samples.
> Either you're out of luck again )), perhaps you'd rather send them back that p.o.s. and ask, wouldn't they mind to ship the normal one at last...
> 
> Yes,
> and the reasons behind it was partly discussed here already, some pages ago, but as Mannix said, there are many unknowns and uncertainties, thanks to amd policy regarding official documentation. For example, the latest publicly availailable BKDG is for Family 15h and 16h, which is not even about Zen (17h) at all.
> 
> Ofcourse, in per-core test the results of each core are individual, but they are part of the whole system, where said cores aside from all their usual work, interacting either thermally with their neighbors, or concurrently within a limited power budget of the whole package, or chiplet, and so on...


@PJVol 



https://www.amd.com/system/files/TechDocs/56569-A1-PUB.zip



Released 9/23/2021


----------



## PJVol

TimeDrapery said:


> Released 9/23/2021


Thanks! I think this is complementary to the older publications for Cezanne arch (model 50). A bit of some fresh info, but honestly not much use of, since it's PPR (and not BKDG one)
It'd would be nice if someone post a link to some resource where the famous leaked amd doc's were published, I mean those stolen from Gigabyte, if you know what I'm about.
Those included PPR's for Zen4 and so on. Some screens can be found on "chipsandcheese"


----------



## TimeDrapery

PJVol said:


> Thanks! I think this is complementary to the older publications for Cezanne arch (model 50). A bit of some fresh info, but honestly not much use of, since it's PPR (and not BKDG one)
> It'd would be nice if someone post a link to some resource where the famous leaked amd doc's were published, I mean those stolen from Gigabyte, if you know what I'm about.
> Those included PPR's for Zen4 and so on. Some screens can be found on "chipsandcheese"


@PJVol 

Of course! I agree that it's certainly not what anyone interested is truly looking for

Duuuuude, I've been looking all over for the stash myself 😂😂😂😂😂... Sure would be nice to come across


----------



## PJVol

TimeDrapery said:


> Sure would be nice to come across


Yep. Something like this sound promising.










> FCLK appears to be around *2.4 GHz* in this diagram from the Zen 4 PPR if the 78 GB/s figure refers to read bandwidth, or 1.625 GHz if it includes write bandwidth as well. 2.4 GHz is more likely because that would correspond to 1:1 FCLK with DDR5-4800


----------



## TimeDrapery

PJVol said:


> Yep. Something like this sound promising.
> View attachment 2527571


@PJVol 

Now I'm reading through articles at your link 😂😂😂😂😂... Good site!


----------



## sp00n82

cyberloner said:


> sir prime95 release new version
> 
> 
> https://mersenne.org/ftp_root/gimps/p95v307b2.win64.zip
> 
> 
> manual change prime95 cause me all error xD


What kind of error?
According to the changelog, something might have changed for the Torture Test settings, so maybe the generated config file for Prime95 isn't working as it should anymore.


----------



## cyberloner

new prime95 release again sir
Windows 64-bit: https://mersenne.org/ftp_root/gimps/p95v307b3.win64.zip

error is like this 
ERROR: 16:31:18
ERROR: Prime95 seems to have stopped with an error!
ERROR: At Core 0 (CPU 0)
ERROR MESSAGE: Unknown gwnum error code: 1010
ERROR: No additional FFT size information found in the results.txt


----------



## TimeDrapery

cyberloner said:


> new prime95 release again sir
> Windows 64-bit: https://mersenne.org/ftp_root/gimps/p95v307b3.win64.zip
> 
> error is like this
> ERROR: 16:31:18
> ERROR: Prime95 seems to have stopped with an error!
> ERROR: At Core 0 (CPU 0)
> ERROR MESSAGE: Unknown gwnum error code: 1010
> ERROR: No additional FFT size information found in the results.txt


@cyberloner 

Why not use the version of Prime95 packaged with the Core Cycler?


----------



## sp00n82

Currently there seems to be a problem with the torture test in the new Prime95 version:
_"*Note to all:* Until build 4 comes out, hyperthreaded torture tests must use the custom setting and select FFT sizes larger than 256K."



https://www.mersenneforum.org/showthread.php?p=589800#post589800


_


----------



## error-id10t

Because everyone always wants to use the latest Prime for some reason.

Anyhow, use BF 2042 Beta as a test, crashed my OC straight away lol.


----------



## mongoled

error-id10t said:


> BF 2042 Beta


Wonder if its playable on a GTX 960 4GB

😂 😂


----------



## Gam3rD4v3

Hey everyone
So ive recently built myself a new system and have spent hrs/days setting pbo limits and curve optimiser settings with a negative(undervolt). Ive been using mainly occt and core cycler to test cores. I have had all the cores pass the core cycler for sse,huge and completing a full cycle of sizes before moving to next core.

Unfortunately a problem ive found recently is loading up Monster Hunter world straight after boot but within a 30secs-1min the screen will go black and comp restarts with a Kernel-power-41-63 error when i load the comp backup again it runs fine no restarts.

I have updated bios and reverted my gfx driver to 1 level lower but still its happening.

My theory is it might be a cold boot problem with the undervolt but im not sure how to diagnose which core is causing it, which software do i test with, what data package do i test with etc?
This problem is not causing a whea error

Thanks for any help in this matter and if you need me to post anymore info let me know

I was wondering what would be my best test to run to find the core/s that need tweaking without the whea error.

system is running a 5950x


----------



## Frosted racquet

Which CPU do you have? One complete cycle of CoreCycle is not nearly enough to verify stability. Check Event Viewer for WHEA errors, it's going to be logged there and see the APIC to figure out which core was the culprit. Download CPUz and create a report under tools to see what core is assigned what ID so you can figure it out from the Event Viewer logs. Some CPUs that have cores cut don't have the same core number and APIC assigned as others


----------



## Gam3rD4v3

Frosted racquet said:


> Which CPU do you have? One complete cycle of CoreCycle is not nearly enough to verify stability. Check Event Viewer for WHEA errors, it's going to be logged there and see the APIC to figure out which core was the culprit. Download CPUz and create a report under tools to see what core is assigned what ID so you can figure it out from the Event Viewer logs. Some CPUs that have cores cut don't have the same core number and APIC assigned as others


 My bad its a 5950x ive updated original post to include that. Thanks for the reply but doesnt help me at all, i already stated no whea errors. Ive also not run 1 cycle of corecycle I did state ive been doing this for days and hrs. Ive got to the point everything appears stable but i am getting the odd crash WITHOUT whea errors so im wondering what or which tests I could run to narrow down the problem core/s/


----------



## Frosted racquet

Sorry, misread your original post about the length of testing. Are you sure something else other than your CPU isn't causing the crashes? Do you have a .dmp file created in your windows directory or in Livekernelreports folder? Might want to check nirsoft bluescreenview just incase.
I've never had a CPU related crash that hasn't created a WHEA error in Event Viewer. Hell, I've had a WHEA error when my GPU VRAM OC wasn't stable...


----------



## ManniX-ITA

Gam3rD4v3 said:


> My bad its a 5950x ive updated original post to include that. Thanks for the reply but doesnt help me at all, i already stated no whea errors. Ive also not run 1 cycle of corecycle I did state ive been doing this for days and hrs. Ive got to the point everything appears stable but i am getting the odd crash WITHOUT whea errors so im wondering what or which tests I could run to narrow down the problem core/s/


I would look into LLC and PWM Switching frequency.
If they are insufficient, you get black screen and reboot.
Same for VSOC/VDDG CCD/IOD. But from that you usually get other signs of instability earlier.


----------



## PJVol

Gam3rD4v3 said:


> if you need me to post anymore info


Yes, post what were the settings for the CPU and RAM (zentimings screenshot) when crash happened.

And can you try OCCT benchmark to confirm it finished without error.


----------



## PJVol

ManniX-ITA said:


> From my understanding the dLDO is the power regulator for the core, it will give more or less core VID upon needs, not just less.
> So I guess the above means if the injector needs to give more VID than the actual vCORE voltage will ask to raise it.
> Guessing right?


Oh... forgot to refer to this slide 









Btw, have you seen WWZ: Aftermath?


----------



## MikeS3000

Any idea why in Windows 11 this program causes prime95 to be almost non-functional? The mouse if lagging like crazy and she system is almost unresponsive. I never experienced this on Windows 10.


----------



## sp00n82

There were severe problems with the Windows scheduler for Ryzen CPUs in Windows 11, maybe this plays a role, as the affinity for Prime95 is set in the script.
I haven't tested it in W11 so far, so can't really give a definitive answer.

Does Prime95 run normal in W11 if you run it manually / if you set the affinity manually using the task manager?


----------



## Ohim

I have been trying to run CoreCycler under Windows 11 but to no success.

The same error : "FATAL ERROR: Could not get the localized Performance Process Counter name!"


----------



## sp00n82

Ohim said:


> I have been trying to run CoreCycler under Windows 11 but to no success.
> 
> The same error : "FATAL ERROR: Could not get the localized Performance Process Counter name!"


Meh. That was a pretty common issue in Win10 as well, so that I included some approaches to fix this in the readme.txt. Maybe the guidelines there also work in Win11, but maybe they changed something and they won't.
Good luck trying to fix the problem and report back if something worked.


----------



## Ohim

sp00n82 said:


> Meh. That was a pretty common issue in Win10 as well, so that I included some approaches to fix this in the readme.txt. Maybe the guidelines there also work in Win11, but maybe they changed something and they won't.
> Good luck trying to fix the problem and report back if something worked.


You were right, sorry that i haven't read all the way .. it was fixed by running the tool provided.


----------



## nick name

Gam3rD4v3 said:


> My bad its a 5950x ive updated original post to include that. Thanks for the reply but doesnt help me at all, i already stated no whea errors. Ive also not run 1 cycle of corecycle I did state ive been doing this for days and hrs. Ive got to the point everything appears stable but i am getting the odd crash WITHOUT whea errors so im wondering what or which tests I could run to narrow down the problem core/s/


Can you run AIDA 64 RAM Copy without crashes? 

Also, is it only immediately upon starting the game after a cold boot? I remember the 2700X took about a minute after getting into Windows before it would begin boosting. I remember reading that it was doing some sort of power table or related setup or something, but I can't find that reference now. I wonder if Ryzen still does this.


----------



## MikeS3000

sp00n82 said:


> There were severe problems with the Windows scheduler for Ryzen CPUs in Windows 11, maybe this plays a role, as the affinity for Prime95 is set in the script.
> I haven't tested it in W11 so far, so can't really give a definitive answer.
> 
> Does Prime95 run normal in W11 if you run it manually / if you set the affinity manually using the task manager?


Yes, Prime95 runs normally if I set affinity manually in the task manager.


----------



## Mike156

Thank you for this tool. I've been running an all core CO setup for about a year now at -18 on a 5600X. It passes all the stability tests I've been running and in general runs well. This test immediately found a core that would crash at that setting though.

Going per core, I had to raise one core to -16 to get it stable but then was able to drop most the other cores by a decent amount. The priority core though still required -18. Makes sense why it wasn't crashing in single core when the core that's getting used all the time is what the all core was set to.

The performance difference isn't anything really measurable but it feels good to know that I've potentially eliminated an instability.


----------



## jcpq

Any solution


MikeS3000 said:


> Any idea why in Windows 11 this program causes prime95 to be almost non-functional? The mouse if lagging like crazy and she system is almost unresponsive. I never experienced this on Windows 10.


Any solution for this?


----------



## GoforceReloaded

MikeS3000 said:


> Any idea why in Windows 11 this program causes prime95 to be almost non-functional? The mouse if lagging like crazy and she system is almost unresponsive. I never experienced this on Windows 10.


I confirm that corecycler don't work on W11 (latest retail build) because of this bug.


----------



## Audioboxer

While I can repeat this behaviour if I try to interact with the Prime95 icon on the notification window, Corecycler will still correctly find instability if you leave it be. Done a few overnight runs now whilst tweaking my curve and it's working as expected.


----------



## dk_mic

for what it's worth, i can repeat this behavior, too, but on windows 10. Only when interacting with the status icon, and it's just a temporary stutter


----------



## KedarWolf

I'm pretty sure the best way to run Core Cycler is with two threads. I checked the logical threads in graph view in task manager and with only one thread running, it was only stressing one of the two threads in Core 1 for example.


----------



## Frosted racquet

Running one thread results in higher achieved clocks compared to two threads on the same core


----------



## KedarWolf

Frosted racquet said:


> Running one thread results in higher achieved clocks compared to two threads on the same core


Yes, I know that. But you're really only testing the first thread on the core, not both threads on the core. Only make sense if a core has two threads you want to test both threads, not just one of them.

Run with one thread and two, and open task manager to Performance in the graph view. You'll see with one thread your only actually testing half the core, only one of the two threads.


----------



## KedarWolf

Here, 5950X 32 threads.

First two pics, first two row 1 Core 0. One thread.



















Second two pics, two threads.


----------



## Frosted racquet

KedarWolf said:


> You'll see with one thread your only actually testing half the core, only one of the two threads.


It's the same physical core that's being tested, the instructions the CPU executes pass through the same physical location on the die whether it uses thread 0 or thread 1. I'd imagine if it's stable on the first thread it will be on the other as well.


----------



## KedarWolf

Frosted racquet said:


> It's the same physical core that's being tested, the instructions the CPU executes pass through the same physical location on the die whether it uses thread 0 or thread 1. I'd imagine if it's stable on the first thread it will be on the other as well.


You're wrong, see my pictures above.

Edit: Then why does Windows see them as 32 Logical Processors. Why test 16 of 32 of them.


----------



## Frosted racquet

Those are logical cores, you can't treat them the same as a physical core.

I'll try making an analogy. You're trying to test a pipe that connects point a to point b and see if the water gets to point b. The length of the pipe represents the instruction set Prime95 uses when CoreCycler runs. When you let CoreCycler use one thread, you're seeing how quick it can pump through water to point b (ie high core frequency). If you set it to 2 threads, you're testing how the same pump can move the most water it can through the pipe regardless of the speed of water. In both cases, you're testing the same pipe to see if water gets to point b (ie the same instruction set), but with different water flow rate.

OCCT for ex has the defaults set to test 2 threads of the same physical core. CoreCycler aims to test a different type of load. Both are valid testing tools as long as you know what they test exactly.


----------



## PJVol

KedarWolf said:


> I'm pretty sure the best way to run Core Cycler is with two threads.


It's not that obvious, since such scenario is far from realistic workload - scheduler won't load 2nd thread, until there are cores in low power states.



Frosted racquet said:


> I'd imagine if it's stable on the first thread it will be on the other as well.


Not nesessarily, since load intencity differes. One logical core usually consuming 30-50% less than two, but as i already said, such workload is quite unusual, and the single thread load is actually more in common with susceptible cases to ocassional crash.


----------



## Mike156

Can you come up with an instance where running 2 threads caused a worker crash where 1 thread didn't?

I had the same feeling that 2 threads would be better than one. You still see the max frequency when using 2 threads. I just figured more data would be processing and more heat would be in the core so it would be more likely to find an instability. The only thing I didn't really think about until now though is if voltage actually changes in a two thread single core load over single thread?


----------



## PJVol

Mike156 said:


> Can you come up with an instance where running 2 threads caused a worker crash where 1 thread didn't?


If it was addressed to me, then I was actually saying the opposite.



Mike156 said:


> if voltage actually changes in a two thread single core load over single thread?


Yeah, it would be strange if it didn't change, while consuming half as much again.


----------



## Akex

sp00n82 said:


> Currently there seems to be a problem with the torture test in the new Prime95 version:
> _"*Note to all:* Until build 4 comes out, hyperthreaded torture tests must use the custom setting and select FFT sizes larger than 256K."
> 
> 
> 
> https://www.mersenneforum.org/showthread.php?p=589800#post589800
> 
> 
> _


I still wonder what is the best preset to test the Curve for gaming / streaming use. 2T is harder than 1T but the load is unreal, SSE is better than AVX for boost, FFT size I'm not sure what to think about it, I'm on Large.

A recommendation ?


----------



## neurokirurgi

Just wanted to drop in and say thanks to @sp00n82 for this tool. It was not only useful when I was tuning the curve on my 5900X, it's also useful on Alder Lake when stress testing high 1-4 core overclocks using Thermal Velocity Boost!  

CoreCycler works fine as long as you disable the e-cores in the config and set the order of testing or either random or sequential.


----------



## Mike156

If you can still reach max clock speed on 2T, shouldn't that get more of the core active while also increasing the heat making it more likely to hit a failure?


----------



## noxious89123

Given that the tool has to be run in Windows, I feel that running only one thread in Core Cycler is more likely to keep the system running on 2 threads or less. CoreCycler is never going to be the only thing running; There's always *something* going on in the background!

With that said, I haven't tested it on more than one thread, and I'd be interested to hear what results people have if they run it on 2 or more.


----------



## Vayne4800

Hello everyone, sorry I haven't posted in a while. A lot has happened but I thought it is worth sharing my progress with my OC using CoreCycler. Please find below:


----------



## Mike156

noxious89123 said:


> Given that the tool has to be run in Windows... There's always *something* going on in the background!
> 
> With that said, I haven't tested it on more than one thread, and I'd be interested to hear what results people have if they run it on 2 or more.


That is a good point. I've ran both ways, usually 2T while I'm adjusting and then a first stability test overnight then I'll switch it to 1T before I go to work. I also run HWinfo with it too though as I'm adjusting so I'm definitely getting more than one core active but it still hits the expected single core frequency limit so I haven't worried about it. I do close everything out when finally settling in on a setup and testing for extended periods though.

I haven't noticed really any difference. To me, it just made sense to load the single core as heavy as possible to generate as much just as possible in that core, provided it consistently sticks the peak frequency. That extra load should, in theory, also be more likely to hit voltage spikes and dips on transitions as it cycles the tests which should push stability even harder?

I don't think I've ran into any instance where one passed and the other didn't though.


----------



## Frosted racquet

Quick question regarding Effective Clocks readout in HWInfo and stability testing. Currently reworking my CO values due to updating to AGESA 1205. Noticed Core 4 is now the only one not hitting +200 (4850MHz) effective clock on my 5600x.

Settings:
Motherboard limits for PPT/TDC/EDC, temps during testing below 65C, CO values (not finalized/stable yet): -12, -26, -22, -24, -20, -18. Cores 2, 4, 5 are yet to be stabilized.
Attached HWInfo readout after 10 cycles

Would trying PBO Scalar settings change anything?


----------



## ManniX-ITA

Frosted racquet said:


> Would trying PBO Scalar settings change anything?


I think you should set PBO limits with EDC below 140A (it's a new gift from AMD with 1.2.0.5...)
Seems your CPU vCore and VID is limited and is limiting your Core VIDs:











In general is a bad idea to use motherboard limits.
Look around for some good values for a 5600X.

If for some reason you want to keep EDC above 140A to unlock the Core VIDs you need a huge positive offset on vCore.
The offset will not let the Core VID to go above the hard lock at 1.425V but will allow the Core VIDs to go up to 1.425V.
I'm using 0.0875V for my 5950X but it doesn't bring back the same performances as old AGESAs.
Going higher will boost ST clocks but will progressively reduce MT performances.

And yes, you need to redo all the work with CoreCycler with this change.


----------



## Frosted racquet

I was using 130/90/130 limits with 1205 for PPT/TDC/EDC before trying motherboard limits and had the same Voltage cap of ~1.37v. I think 5600x has a different EDC limit than 140 where it doesn't cap voltage.


----------



## ManniX-ITA

Frosted racquet said:


> I was using 130/90/130 limits with 1205 for PPT/TDC/EDC before trying motherboard limits and had the same Voltage cap of ~1.37v. I think 5600x has a different EDC limit than 140 where it doesn't cap voltage.


Could be. Try with a positive offset or check if you can find the trigger threshold


----------



## PJVol

Frosted racquet said:


> I think 5600x has a different EDC limit than 140 where it doesn't cap voltage.


max VID limit 1.375V, not EDC.



ManniX-ITA said:


> set PBO limits with EDC below 140A


Did nothing with 1.2.0.5 based bios to my 5600X


----------



## Frosted racquet

PJVol said:


> max VID limit 1.375V, not EDC.


The theory is that on some CPUs going above 140 EDC changes the max VID to 1.425v (or 1.37v for 5600x) from 1.5v or whatever it was with 1203 or stock EDC.


----------



## ManniX-ITA

PJVol said:


> Did nothing with 1.2.0.5 based bios to my 5600X


Ouch it's always limited to 1.375V despite PBO settings?
Didn't even test with my 5950X but I've seen from other posts below 140A the Core VID is not limited.
And if you set below and later change with Ryzen Master it's not limited to 1.425V at all.

Anyway I'm using a vCore offset to "fix" it and it works.
Not the best as all the CO counts are shifted 10 below now.
But still general performances are from slightly worse to slightly better.
Did you try to use an offset?


----------



## PJVol

ManniX-ITA said:


> Did you try to use an offset?


No, i didn't. Tbh I tried to play with 1205 a couple of days and I don't like it. So I rolled back to 1203C and posted the diffierence in DDR thread.
Atm gonna try 1205 on my office 5700G PC. MSI rolled out b450 update, gonna report how it goes.

Check this out  (> 1,5 years)





MSI USA


Welcome to the MSI USA website. MSI designs and creates Mainboard, AIO, Graphics card, Notebook, Netbook, Tablet PC, Consumer electronics, Communication, Barebone, Server, industrial computing, Multimedia, Clean Machine and Car Infotainment.




us.msi.com


----------



## Frosted racquet

PJVol said:


> Tbh I tried to play with 1205 a couple of days and I don't like it. So I rolled back to 1203C and posted the diffierence in DDR thread.


According to @Veii once you flash 1205 the changes to voltage/frequency curves are permanent, so you can't roll them back to 1203 and expect to use the same CO settings. Can you confirm the previous 1203 CO values are stable after reflashing 1203 again? Thanks.


----------



## Veii

Frosted racquet said:


> According to @Veii once you flash 1205 the changes to voltage/frequency curves are permanent, so you can't roll them back to 1203 and expect to use the same CO settings. Can you confirm the previous 1203 CO values are stable after reflashing 1203 again? Thanks.


Half correct

There are permanent changes, but nobody exactly knows what changes
Security changes, PCH Link patches are permanent
But V/F curve is up to SMU, which might or might not get updated on a new AGESA.
* also a new SMU version doesn't mean everything has changed

Voltage limiters "can" be permanent - but hence PJVol showed that it was gone on the downgrade
So far they are not.
Although nobody knows what 1206 will show

There are permanent behaviors on firmware updates
But the AGESA by itself does not do much.
The blobs that come with the AGESA or don't come ~ can be a potential issue
Hence nobody tells you when things update, or "hidden sensors" start to function (1.1.8.1 onwards)
Nobody will hardly tell you when things change around
But once such things change. They are permanent.

Soo for example once IMC-FW updates, it is permanent & you will continue to notice the same memory behavior on a lower bios version
Just again ~ by the nature of them and the lack of information.
Some changes are noticed quite fast, some are not noticed one year later
And only these are permanent. Soo users have to hope that AMD doesn't supply experimental patches permanently, but like 1205 "beta" ~ well 1204A onwards, "tries" something and sees how it goes

EDIT:
The ABL (bootloader) change with the 2nd attempted FCLK lock on 1.1.0.0C should've been permanent
* as it was done to Matisse before.
But community did have several results beyond 2000 FCLK and higher ~ soo they "accidentally" removed this change on 1.1.0.0D and praised on social media "finetuned FCLK now till 2000Mhz"
Which was pure marketing ~ because they created a problem, just to solve it 
* maaybe they have worked on DPM changes, but i didn't see anything & they missed their opportunity with B2 samples

3rd example,
Same marketing "oopsy" was done on 1.1.0.0C to force users to update to it
"Finally allowed negative CO & ReBAR mode enabled"
Pure Marketing lie ! , as CO & BAR-Mode existed since the very first 1.1.0.0A patch (SMU 56.30)
Just also sadly, vendors did listen, and new boards do not run AGESA bellow 1.1.0.0C
Such secrecy and holding OC community for dumb ~ is annoying
And on the same topic, you can hardly know when things change around ~ but some indeed are permanent


----------



## PJVol

Frosted racquet said:


> According to @Veii once you flash 1205 the changes to voltage/frequency curves are permanent, so you can't roll them back to 1203


According to @Me that's not the case.


----------



## 1devomer

PJVol said:


> According to @Me that's not the case.


Correct me if i'm being wrong please, but i would tend to think that the addressable memory space, inside the cpu, is flagged as Read-Only after being produced.
So theoretically, it is not possible to update the AGESA keys and the bin information, residing inside the cpu after being produced.

So, if some hidden values are stored, they are store inside the bios, in a dedicated region that is not being updated during the flash.
That why flashing old bios may or may not restore the previous curves values, but a full chip blank and a clean flash with a programmer, maybe can.


----------



## PJVol

1devomer said:


> So theoretically, it is not possible to update the AGESA keys and the bin information, residing inside the cpu after being produced.


Sorry, I can't say for sure, as I haven't got enough low-level knowledge of flashing efi images, but I thought the same.
What I wrote above is what I checked out already.


1devomer said:


> That why flashing old bios may or may not restore the previous curves values, but a full chip blank and a clean flash with a programmer, maybe can.


I am sure that it's agesa and mb vendors who are responsible for the various tricks for not letting the users to flash back to older versions. This can be seen, for example, in a recent Cezanne agesa binary blobs "changelog"s


----------



## 1devomer

PJVol said:


> Sorry, I can't say for sure, as I haven't got enough low-level knowledge of flashing efi images, but I thought the same.
> What I wrote above is what I checked out already.
> 
> I am sure that it's agesa and mb vendors who are responsible for the various tricks for not letting the users to flash back to older versions. This can be seen, for example, in a recent Cezanne agesa binary blobs "changelog"s


Good observation i agree, i didn't make the link, even if already knowing it.
I got the 💡 when reading your post, it makes sense!


----------



## Sam_Oslo

Hey guys. My first post in this thread.

Overnight CoreCycler has passed over 8 hours with default settings, and *CO = -30 on all cores *









What do you guys think about this one?


----------



## Frosted racquet

It's recommended to run the test for 12h per core, 12hx8=96h in your case. Maybe configure it to test a single core per night, switching cores each night.
Are you aiming to increase max boost clock as well? If so, it's OK to test for shorter periods for frequency settings that aren't your goal. Once you dial in what you think are your final settings then run an extended test.


----------



## Sam_Oslo

Frosted racquet said:


> It's recommended to run the test for 12h per core, 12hx8=96h in your case.


Wow, that's a long time.

But I can take this 8 hours as a hint/indication and combine it with other tests. I have already run some OCCT CPU stress tests and such. I have planned to run the y-cruncher at the end of all optimization/tweaks.


----------



## Frosted racquet

That's a good option. IMO it's better to run more varied tests for shorter periods if you don't have the time to test extensively.


----------



## Luggage

Sam_Oslo said:


> Wow, that's a long time.
> 
> But I can take this 8 hours as a hint/indication and combine it with other tests. I have already run some OCCT CPU stress tests and such. I have planned to run the y-cruncher at the end of all optimization/tweaks.


You dont have to wait



http://imgur.com/a/ZMnaGHQ


perhaps you dont want to wait


----------



## HeadlessKnight

From my testing nothing is more punishing than [email protected], it just humbles half-assed overclocks in no time.


----------



## ManniX-ITA

For a quick test (5 minutes per core) I'm using Prime95 - SSE - All FFT sizes in range 16000 - 26880

runtimePerCore = auto
mode = SSE
FFTSize = 16000-26880

Works quite reliably to catch an unstable count without running the whole range

@sp00n82 

May I ask for a couple of improvements, if possible?

It'd be nice to have multiple testing "straps" per core with prime.
Meaning testing each core with multiple consecutive configs (all FFT tested as the goal is to test always specific ranges).

Example:
I want to test first a specific range all modes, then from min to 16000 and next from 26880 to max.

SSE 16000 - 26880, AVX 16000 - 26880, AVX2 16000 - 26880, SSE 4000 - 16000, AVX 4000 - 16000, AVX2 4000 - 16000, SSE 26880 - MAX, AVX 26880 - MAX, AVX2 26880 - MAX

If testing one range fails, skip the rest and go to the next core.
This would help to skip quickly failing cores during a nighttime unattended run without losing the option to fully test a core .

2nd improvement would be to ask if you want to resume the session when breaking the script with Ctrl+C.
When i have to break it, I need to remember the Core was running and edit the ini to change the CoreTestOrder to put the already tested cores out or in the beginning

Would be nice if ti could save the core which was running and at next start ask you if you want to resume or start over from the beginning
Which could be even more useful with the change above as the script could resume from the last strap which was running, instead from the beginning.


----------



## dk_mic

I would also like to completely specifiy my own selection of FFT sizes, for example a group of small medium and large FFTs


----------



## KedarWolf

ManniX-ITA said:


> For a quick test (5 minutes per core) I'm using Prime95 - SSE - All FFT sizes in range 16000 - 26880
> 
> runtimePerCore = auto
> mode = SSE
> FFTSize = 16000-26880
> 
> Works quite reliably to catch an unstable count without running the whole range
> 
> @sp00n82
> 
> May I ask for a couple of improvements, if possible?
> 
> It'd be nice to have multiple testing "straps" per core with prime.
> Meaning testing each core with multiple consecutive configs (all FFT tested as the goal is to test always specific ranges).
> 
> Example:
> I want to test first a specific range all modes, then from min to 16000 and next from 26880 to max.
> 
> SSE 16000 - 26880, AVX 16000 - 26880, AVX2 16000 - 26880, SSE 4000 - 16000, AVX 4000 - 16000, AVX2 4000 - 16000, SSE 26880 - MAX, AVX 26880 - MAX, AVX2 26880 - MAX
> 
> If testing one range fails, skip the rest and go to the next core.
> This would help to skip quickly failing cores during a nighttime unattended run without losing the option to fully test a core .
> 
> 2nd improvement would be to ask if you want to resume the session when breaking the script with Ctrl+C.
> When i have to break it, I need to remember the Core was running and edit the ini to change the CoreTestOrder to put the already tested cores out or in the beginning
> 
> Would be nice if ti could save the core which was running and at next start ask you if you want to resume or start over from the beginning
> Which could be even more useful with the change above as the script could resume from the last strap which was running, instead from the beginning.


I find 6 minutes of 720-720 in Core Cycler overnight or it while I'm at work is finding errors Large etc miss. I've had to completely redo several cores in my curve that don't pass that


----------



## sp00n82

ManniX-ITA said:


> May I ask for a couple of improvements, if possible?
> 
> It'd be nice to have multiple testing "straps" per core with prime.
> Meaning testing each core with multiple consecutive configs (all FFT tested as the goal is to test always specific ranges).
> 
> Example:
> I want to test first a specific range all modes, then from min to 16000 and next from 26880 to max.
> 
> SSE 16000 - 26880, AVX 16000 - 26880, AVX2 16000 - 26880, SSE 4000 - 16000, AVX 4000 - 16000, AVX2 4000 - 16000, SSE 26880 - MAX, AVX 26880 - MAX, AVX2 26880 - MAX
> 
> If testing one range fails, skip the rest and go to the next core.
> This would help to skip quickly failing cores during a nighttime unattended run without losing the option to fully test a core .
> 
> 2nd improvement would be to ask if you want to resume the session when breaking the script with Ctrl+C.
> When i have to break it, I need to remember the Core was running and edit the ini to change the CoreTestOrder to put the already tested cores out or in the beginning
> 
> Would be nice if ti could save the core which was running and at next start ask you if you want to resume or start over from the beginning
> Which could be even more useful with the change above as the script could resume from the last strap which was running, instead from the beginning.


Hm. I thought about this but I think it's too much of an effort. The main roadblock is that Prime95 only accepts a minimum and a maximum FFT size in its config file, so to implement multiple groups of FFT sizes, I'd have to add a functionality that restarts Prime95 with a new config file when the end of the first group has been reached, resp. when all the FFT sizes within one group have been completed. Prime95 somewhat randomizes the order of the FFT sizes and doesn't linearly go from the smallest to the highest number, so I can't just rely on the max FFT size for a group to be complete.

The same problem occurs for an auto-resume feature. It can't just resume the FFT size where it left off when the order of the FFT sizes is random. There may still be FFT sizes lower than the one that was just completed that have not been tested yet.
It certainly _would_ be possible. But I would need to rewrite large portions of the code to support this.


Here's an example of the randomization:


Code:


# 11200, 8960, 9216, 9600, 10240, 10752, 11520, 11200, 11520, 12288, 11200, 8192, 11520, 12288, 12800, 13440, 13824, 8960, 14336, 15360,
# 16000, 16128, 16384, 9216, 17920, 18432, 19200, 20480, 21504, 9600, 22400, 23040, 24576, 25600, 26880, 10240, 28672, 30720, 32000, 32768,
# 35840, 10752, 38400, 40960, 44800, 51200


----------



## ManniX-ITA

sp00n82 said:


> The same problem occurs for an auto-resume feature. It can't just resume the FFT size where it left off when the order of the FFT sizes is random. There may still be FFT sizes lower than the one that was just completed that have not been tested yet.


Yes I meant restarting from the last group that was running, re-launching Prime95 for every group.



sp00n82 said:


> It certainly _would_ be possible. But I would need to rewrite large portions of the code to support this.


I thought so, sadly 
Well in case one day you decide for some reason to refactor...


----------



## OCmember

What's the safe max VCORE a core should see during these tests? e.g. Y Cruncher, P95.


----------



## Luggage

OCmember said:


> What's the safe max VCORE a core should see during these tests? e.g. Y Cruncher, P95.


Whatever you get if you leave everything on auto.


----------



## ManniX-ITA

OCmember said:


> What's the safe max VCORE a core should see during these tests? e.g. Y Cruncher, P95.


In single core load the Core VID can go up to 1.4x V.
More cores are loaded together and more will drop.
Also the type or workload (SSE, AVX, AVX2) will drop the max Core VIDs.
It's not unusual that all cores running with AVX2 the average is about 1.1V.
Depends on the temperature.


----------



## OCmember

ManniX-ITA said:


> In single core load the Core VID can go up to 1.4x V.
> More cores are loaded together and more will drop.
> Also the type or workload (SSE, AVX, AVX2) will drop the max Core VIDs.
> It's not unusual that all cores running with AVX2 the average is about 1.1V.
> Depends on the temperature.


With YCRUNCHER, through CoreCycler, I'm seeing +/-1.46v on a single core. Should I be worried?


----------



## Frosted racquet

@OCmember No

Has anyone confirmed whether or not changing CO value for one core can affect the stability of the adjacent core? I have read a post somewhere talking about this, but no exact evidence posted.


----------



## ManniX-ITA

Frosted racquet said:


> Has anyone confirmed whether or not changing CO value for one core can affect the stability of the adjacent core?


Not sure what "evidence" you need 
Drove me crazy a while ago when I had a bad Core in the 2nd CCD passing quick tests but unstable at the set CO count.
The good Cores in the 1st CCD were spitting random errors, sometimes quickly while others passing hours of cycling.


----------



## Frosted racquet

What I had in mind is, lets say Core 4 is very near clock stretching at +200 and -16 CO value and crashes while CoreCycling at those settings, but adjacent Core 5 is good/stable and has a few CO increments to spare before it clock stretches. So instead of decreasing the CO for Core 4 to -14, decrease it for the adjacent Core 5 and stabilize Core 4 that way, and avoid clock stretching Core 4 as well.
In my case 5600X has one CCD so it's relatively simpler case.


----------



## ManniX-ITA

Frosted racquet said:


> So instead of decreasing the CO for Core 4 to -14, decrease it for the adjacent Core 5 and stabilize Core 4 that way


It never worked for me to relax a CO Count on a Core to stabilize another.
If there's an unstable Core it will mess with the others.
But slowing down the others to get a better CO count on a best core doesn't work; I tried that


----------



## PJVol

Frosted racquet said:


> What I had in mind is, lets say Core 4 is very near clock stretching at +200 and -16 CO value and crashes while CoreCycling at those settings, but adjacent Core 5 is good/stable and has a few CO increments to spare before it clock stretches. So instead of decreasing the CO for Core 4 to -14, decrease it for the adjacent Core 5 and stabilize Core 4 that way, and avoid clock stretching Core 4 as well.
> In my case 5600X has one CCD so it's relatively simpler case.


Core 4 in no way is adjacent to Core 5. Check actual core layout with a someone's tool called PBO2 tool.

Regarding your assumption, let's say you're probably on the right track but at the same time setting inappropriate objectives.


----------



## ManniX-ITA

PJVol said:


> Check actual core layout with a someone's tool called PBO2 tool.


I heard someone from ASUS did it


----------



## Frosted racquet

PJVol said:


> Core 4 in no way is adjacent to Core 5. Check actual core layout with a someone's tool called PBO2 tool.





Code:


CPU AMD Ryzen 5 5600X 6-Core Processor
SMU Version 56.53.0
CCDs active 1 (total 1) Cores total 6
Active cores:
  Core0 - 0
  Core1 - 1
  Core2 - 2
  Core3 - 3
  Core4 - 6
  Core5 - 7

How to interpret this readout? The way I see it, core 4 and 5 are separated from the rest of the cores with 2 disabled cores inbetween? Also, how does the PBO2 tool readout differ from CPUz APICs readout? I'm guessing CPUz reads out the way Windows assigned IDs to cores, regardless of how they are physically located on the die.


Spoiler




*APICs*Socket 0 -- Node 0 -- CCX 0 -- Core 0 (ID 0) -- Thread 00 -- Thread 11 -- Core 1 (ID 1) -- Thread 22 -- Thread 33 -- Core 2 (ID 2) -- Thread 44 -- Thread 55 -- Core 3 (ID 3) -- Thread 66 -- Thread 77 -- Core 4 (ID 4) -- Thread 88 -- Thread 99 -- Core 5 (ID 5) -- Thread 1010 -- Thread 1111



Thanks


----------



## PJVol

Frosted racquet said:


> Also, how does the PBO2 tool readout differ from CPUz APICs readout?


Actual layout is


Core1​Core3​fused out​Core5​L3`​L3​L3​L3​Core0​Core2​fused out​Core4​

What CPUz is telling you about it?


----------



## Frosted racquet

Ah, I completely forgot about L3 cache in-between Cores.
Regarding CPUz, in the report it creates, you can see a list of APICs numbers that are assigned to specific Cores. Some CPUs have for example thread 10 and 11 in core 5 reported as APICs 16 and 17, indicating that there's a fused out core in-between. 
In my CPUz report posted above, APICs numbers align with Core/thread numbers so I thought the layout was

Core1Core3Core 5fused outL3`L3L3L3Core0Core2Core 4fused out
but I guess CPUz doesn't show physical core layout.


----------



## Frosted racquet

OK, I'm confused. Gave up on testing +200 MHz offset due to core 4 clock-stretching. CO values for +200 MHz were -12(?), -24, -20, -24, -16(?), -14(?) before I gave up; values with question marks were unstable/untested. Cores 1,2,3 were stable 12+h with CoreCycler YCruncher preset with 19-ZN2 ~ Kagari setting.

Changed the offset to +150MHz and redid my CO values from the beginning. Current CO values, yet unfinished, -14|-30|-18|-26|-22|-18. Core 2 which was stable at +200MHz CO -20 is now unstable with +150MHz CO -20. 
So my question is, do the CO values shift/change when changing the boost offset or am I misunderstanding something?


----------



## ManniX-ITA

Frosted racquet said:


> So my question is, do the CO values shift/change when changing the boost offset or am I misunderstanding something?


Yes & no.
It's not a change of CO value.
It's a change on the V/F curve; which means what the Core will attempt to do and will actually do.
Which is not always the same.

The Boost clock and the scalar will alter big time the behavior, the PBO limits too but less.
Usually if at the same count a Core is unstable with a lower boost clock there are 2 reasons.
Either you didn't detect the instability with at +200 or there's another Core unstable which is messing with it at +150.

If you are testing only with Kagari it's a waste of time.
You need to test also with Prime95 with SSE/AVX and AVX2 too.
Kagari will be quick to spot highly unstable AVX2. But that's all.
I've set today a couple of cores with unstable count.
2 minutes max to spot the instability on AVX2 with N32.
But only if the count was highly unstable.
With a slightly unstable count that fails SSE/AVX in the long run N32 Kagari went all over it for 45 minutes without erroring.
Same slightly unstable count went through 40 minutes Kagari all tests, no errors.


----------



## Frosted racquet

ManniX-ITA said:


> Either you didn't detect the instability with at +200 or there's another Core unstable which is messing with it at +150.


So it's better to test one core until you find a stable CO offset for it? Lets say, -30|0|0|0|0|0 test until Core 0 is stable, then test next core 0|-30|0|0|0|0 etc. and then combine all the individually tested CO values together.
I plan to test SSE and AVX as well, no worries there.


----------



## ManniX-ITA

Frosted racquet said:


> So it's better to test one core until you find a stable CO offset for it? Lets say, -30|0|0|0|0|0 test until Core 0 is stable, then test next core 0|-30|0|0|0|0


No, if you are starting from scratch find a baseline count.
Like -15, -20 for all cores.
They affect each other, especially when there's a big delta.
Testing with all other cores to zero is worse.

You already have a baseline.
If you smell something is not right, lower all the other cores by -2 to see if you missed something.
When you are sure a core it's stable and you had to adjust it, test again all the other with SSE.
Then move to AVX and AVX2.


----------



## cancel007

Hello all, 

I've had a 5800x since launch but I never really went deep into OC. I've only recently been interested in OCing my cpu and seeing what it could do. I've been playing with the curve optimizer for the past few days and been having trouble on how to test stability. I've started using OCCT as an initial stresser, and then I came across CC which I will be using shortly for sure! 

I have also read pretty much this entire 31 pg thread 😅. Lots of advanced things here that I don't know. So I'm a somewhat oc noob, please bear with me. So I have a few questions non CC related so I hope it is somewhat the venue. 

I noticed earlier a few screenshots between bebius and PJVol, where PJVol stated that PPT/TDC/EDC should not be 100% when running MC on CB23. However, when I run it using my current curve settings I do get 100% on EDC that comes out to 130A. But reading online, apparently default is 140A for a 105W tdp chip? Am I losing possible performance here? Should I increase it? Please note my limits of stock (auto or disabled whatever it is set I'm bios).

Second question, I'm testing out my curve optimizer settings without an offset so +0 mhz. But I might be interested in giving it another +100mhz later. Should I just stop now, add the offset and test instead of wasting my time? I keep thinking that if I get a baseline without the offset it'll be easier. But reading here and other forums/reddit I'm not sure anymore.

P.s. My bios settings are all auto/default stock settings other than curve negative values which I'm playing at. Also my cooler is Arctic LF ii 360, and my temps are maxing at usually at 70-72C.

Thanks in advance!


----------



## ManniX-ITA

cancel007 said:


> I noticed earlier a few screenshots between bebius and PJVol, where PJVol stated that PPT/TDC/EDC should not be 100% when running MC on CB23. However, when I run it using my current curve settings I do get 100% on EDC that comes out to 130A. But reading online, apparently default is 140A for a 105W tdp chip? Am I losing possible performance here? Should I increase it? Please note my limits of stock (auto or disabled whatever it is set I'm bios).


Depends on what you want to favor.
If you use a lot all-core higher limits ae better otherwise lower.
You should try.
My 5800X likes more EDC at 140A, both cases.
Also if you have a BIOS with an AGESA 1.2.0.5+ going over 140A will kill the processor performances.

For PPT/TDC test either 135/90 or 220/120.
I was using 135/90 cause the single core and light threaded boost was noticeably better.

For stress use y-cruncher together with OCCT.
12 cycles of stress test y-c all tests and you are sure it's rock solid.



y-cruncher - A Multi-Threaded Pi Program





cancel007 said:


> Second question, I'm testing out my curve optimizer settings without an offset so +0 mhz. But I might be interested in giving it another +100mhz later. Should I just stop now, add the offset and test instead of wasting my time? I keep thinking that if I get a baseline without the offset it'll be easier. But reading here and other forums/reddit I'm not sure anymore.


It's not the same as the single core speed is castrated, especially on the 5800X.
Why not +200? If it's a good binning can do it like a piece of cake.

I did set +200 and 135/90/140 and tested.
Later also set the Scalar to 4x, higher wasn't making much of a difference.

What I did is using BoostTester:






BoostTesterMannix.zip







drive.google.com





And PJVol's PBO2 Tuner:






Debug.7z







drive.google.com





HWInfo open (AMD Snapshot mode and pooling cycle 500ms) and BoostTester running.

Used PBO2 Tuner to change on the fly the CO counts to have all cores boosting at 5050 max effective and running those few seconds at 100% at least at steady 5000 MHz.
Almost all cores could do 5000 MHz sustained, only one was around 4990 MHz.

Then I started CC testing each core single in SSE.
Didn't went really far, tested only FFT 720-720, cause then my 5950X came back from RMA.
But since it's faulty I'll have to switch back again to it and do it again from scratch.
Forgot to save the CO settings for this 5800X


----------



## cancel007

ManniX-ITA said:


> Depends on what you want to favor.
> If you use a lot all-core higher limits ae better otherwise lower.
> You should try.
> My 5800X likes more EDC at 140A, both cases.
> Also if you have a BIOS with an AGESA 1.2.0.5+ going over 140A will kill the processor performances.
> 
> For PPT/TDC test either 135/90 or 220/120.
> I was using 135/90 cause the single core and light threaded boost was noticeably better.
> 
> For stress use y-cruncher together with OCCT.
> 12 cycles of stress test y-c all tests and you are sure it's rock solid.
> 
> 
> 
> y-cruncher - A Multi-Threaded Pi Program


Firstly, thanks for your reply!

I am an average user. I probably don't use a lot of all-core limits. My AGESA version is 1.2.0.2, it is the most stable version and have not experienced BSODs/crashes that early users experienced when the 5800x came out. Ever since I updated this last year, I have not crashed once so I definitely don't intend of updating my bios lol. So does this mean that EDC 140A is safe? If I don't have to change default PPT/TDC/EDC values, then there is no need. I was just wondering if increased EDC will actually improve performance (R23/Timespy scores, etc).




ManniX-ITA said:


> It's not the same as the single core speed is castrated, especially on the 5800X.
> Why not +200? If it's a good binning can do it like a piece of cake.
> 
> I did set +200 and 135/90/140 and tested.
> Later also set the Scalar to 4x, higher wasn't making much of a difference.
> 
> What I did is using BoostTester:
> 
> 
> 
> 
> 
> 
> BoostTesterMannix.zip
> 
> 
> 
> 
> 
> 
> 
> drive.google.com
> 
> 
> 
> 
> 
> And PJVol's PBO2 Tuner:
> 
> 
> 
> 
> 
> 
> Debug.7z
> 
> 
> 
> 
> 
> 
> 
> drive.google.com
> 
> 
> 
> 
> 
> HWInfo open (AMD Snapshot mode and pooling cycle 500ms) and BoostTester running.
> 
> Used PBO2 Tuner to change on the fly the CO counts to have all cores boosting at 5050 max effective and running those few seconds at 100% at least at steady 5000 MHz.
> Almost all cores could do 5000 MHz sustained, only one was around 4990 MHz.
> 
> Then I started CC testing each core single in SSE.
> Didn't went really far, tested only FFT 720-720, cause then my 5950X came back from RMA.
> But since it's faulty I'll have to switch back again to it and do it again from scratch.
> Forgot to save the CO settings for this 5800X


I have tried playing with static OC more than curve optimizer earlier on. I did not get good results compared to others. I always had higher voltages and couldnt get passed 4.65 ghz really. Also CTR assessed my cpu as silver. Therefore, I don't think I have the best silicon but not the worst. That is why I don't really want to try +200 mhz. I feel +100 mhz will be an acceptable boost for a middle quality silicon (based on a personal assessment lol).

For example when I run R23 single core, under bus clock the best effective core for my strongest core, it only reaches 4280 Mhz for a run I just did (keep in mind I have MS teams on for work right now but not sure if affects it that much). But under the core clocks, they all reach 4850 mhz. For multicore, it peaks at around 4625/4650 mhz for both effective clock and core clocks. Just to give you an indication of my cpu (whether that helps or not)

Also regarding the programs recommended - is the y-crunch software better/faster than corecycler? Should I use both or just y-crunch is enough? Secondly, can you explain what BoostTester and PBO2Tuner does? From what I understood is that BoostTest tests the amount of boost my silicon can have, and PBO2 Tuner is able to change the co count on the fly? What would be the purpose of PBO2 Tuner by changing it on the fly, shouldn't I change values in bios and then test? Sorry, I am obviously not understanding the purpose of these two programs. I do appreciate the assistance however!


----------



## ManniX-ITA

cancel007 said:


> So does this mean that EDC 140A is safe? If I don't have to change default PPT/TDC/EDC values, then there is no need. I was just wondering if increased EDC will actually improve performance (R23/Timespy scores, etc).


Yes is perfectly safe.
It should increase scores by a bit; if you are at 130A it's already very close.



cancel007 said:


> I have tried playing with static OC more than curve optimizer earlier on. I did not get good results compared to others. I always had higher voltages and couldnt get passed 4.65 ghz really. Also CTR assessed my cpu as silver. Therefore, I don't think I have the best silicon but not the worst. That is why I don't really want to try +200 mhz. I feel +100 mhz will be an acceptable boost for a middle quality silicon (based on a personal assessment lol).


There's really not much relation on what you can get from static OC and PBO Boost Clock.
If you got Silver from CTR then the silicon is pretty good.
Up to you, going up to 200 shouldn't be an issue but for sure 100 is more conservative and thus safer.



cancel007 said:


> lso regarding the programs recommended - is the y-crunch software better/faster than corecycler?


Use y-cruncher directly for all-core testing and CoreCycler is for single core testing.
You can either use as default Prime95 or also y-cruncher with CoreCycler.



cancel007 said:


> econdly, can you explain what BoostTester and PBO2Tuner does? From what I understood is that BoostTest tests the amount of boost my silicon can have, and PBO2 Tuner is able to change the co count on the fly?


BoostTester is running a very lightweight workload without special instructions set.
You can check the max and sustained effective clock with HWInfo.



cancel007 said:


> What would be the purpose of PBO2 Tuner by changing it on the fly, shouldn't I change values in bios and then test? Sorry, I am obviously not understanding the purpose of these two programs. I do appreciate the assistance however!


You can just leave at 0 in the BIOS and set the CO counts with PBO2 Tuner on the fly.
Open it while you have BoostTester running and HWInfo open (with the settings as above).

If you set max boost clock +100 your goal is to get the cores at 4950 MHz or close to it.

BoostTester will cycle through all the cores.
First will do a very short workload burst which will boost the core the max frequency.
You may have eg. Core 3 boosting max effective clock 4900.
Then there's a short load, about 6 seconds.
During this short load you have to observe the current effective clock.
It's probably going to be on average lower than the max clock, eg. 4850.
This is the sustained clock.

Now you can lower the count until you see the max clock at the next pass peaking 4950.
Then you can try to lower the count until also the sustained clock stays around 4950.

It's a very quick and fast way to have a starting baseline for CoreCycler.

More heavier workload will run at a lower clock.
So when you start with CoreCycler the single core boost will be lower.
You can then try to lower the counts more and see if you can pass.

Of course when you are done set the counts in the BIOS.


----------



## cancel007

ManniX-ITA said:


> BoostTester will cycle through all the cores.
> First will do a very short workload burst which will boost the core the max frequency.
> You may have eg. Core 3 boosting max effective clock 4900.
> Then there's a short load, about 6 seconds.
> During this short load you have to observe the current effective clock.
> It's probably going to be on average lower than the max clock, eg. 4850.
> This is the sustained clock.
> 
> Now you can lower the count until you see the max clock at the next pass peaking 4950.
> Then you can try to lower the count until also the sustained clock stays around 4950.
> 
> It's a very quick and fast way to have a starting baseline for CoreCycler.
> 
> More heavier workload will run at a lower clock.
> So when you start with CoreCycler the single core boost will be lower.
> You can then try to lower the counts more and see if you can pass.
> 
> Of course when you are done set the counts in the BIOS.


Firstly, I acknowledge the previous information above the quoted information. Thank you! I guess I could start at +200, I am just hesitant on wasting my time in case it's too much then having to revert back.

Secondly, ah I think I am starting to understand what you mean. So the effective clock should match the core clock during these short load bursts? Therefore, lower /increase curve values as needed. So R23 single core test is not an effective test eh? That makes sense. Definitely easier than restarting every time in order to change the values in bios!

Would you recommend to start at -15 all around and then start adjusting from there? Please keep in mind that my strongest cores right now are at -5 and I am not crashing yet. So not sure if I should just keep them at -5 or still start at -15.

Last few question regarding this:

1. When using BoostTest & PBO2 Tuner, what are the chances of my system crashing? Should I write down all the curve settings as I test it so in case it crashes, I can look at the WHEA error and just lower it? (same standard process I guess, except when something crashes you can just go back to BIOS and dial it back, no need to "write it down".)

2. Should I adjust PPT/TDC/EDC at this point? or should I leave it last once I find a good stable curve?

Thanks again!


----------



## ManniX-ITA

cancel007 said:


> Secondly, ah I think I am starting to understand what you mean. So the effective clock should match the core clock during these short load bursts? Therefore, lower /increase curve values as needed. So R23 single core test is not an effective test eh? That makes sense. Definitely easier than restarting every time in order to change the values in bios!


The effective clock should come as close as possible to the Fmax clock which for a 5800X with +200 is 5050 MHz.
The reference clock will go up as well while lowering the CO.



cancel007 said:


> So R23 single core test is not an effective test eh? That makes sense. Definitely easier than restarting every time in order to change the values in bios!


R23 single core test is to assess the performances, different story.
It will bounce between the two best cores usually.
As all the benchmarks run it before and after optimizing the CO.



cancel007 said:


> Would you recommend to start at -15 all around and then start adjusting from there? Please keep in mind that my strongest cores right not are at -5 and I am not crashing yet. So not sure if I should just keep them at -5 or still start at -15.


I wouldn't to be safe.
Start with 0 in BIOS and watch the result of the first pass of BoostTester.
Apply what makes sense. If your best core is already boosting at 5050 Mhz it's probably more than enough a -5.

If you have core deeply below, like 4900, go for -15 and then add another -5 at every round until you get the max.
If you see a Core that at -20 it runs at 4990 and it doesn't go further up with -25 or -30 better to go back to -20.
You can check with CoreCycler later if you can get it lower stable.
Lower the overall counts and better the all-core performances.
It's to set a starting point, often a core that doesn't respond with a higher frequency going down with the count means is border-line stable.



cancel007 said:


> 1. When using BoostTest & PBO2 Tuner, what are the chances of my system crashing?


If you start with 0 count very low.
You can take pictures from your mobile when you have made changes.
Then when you are done just type them in BIOS.



cancel007 said:


> 2. Should I adjust PPT/TDC/EDC at this point? or should I leave it last once I find a good stable curve?


No decide first what to use.
There's a slight change and while usually doesn't, it could make a difference.


----------



## cancel007

ManniX-ITA said:


> The effective clock should come as close as possible to the Fmax clock which for a 5800X with +200 is 5050 MHz.
> The reference clock will go up as well while lowering the CO.


Just to confirm of what I should look at - in HWinfo64, there are Core Clocks and Core Effective Clocks (which show the different cores). When you are saying the effective clock per core should come close as possible to the *Fmax, *are you referring Fmax to the Core Clock and *reference clock* to the Core Effective Clock?



ManniX-ITA said:


> I wouldn't to be safe.
> Start with 0 in BIOS and watch the result of the first pass of BoostTester.
> Apply what makes sense. If your best core is already boosting at 5050 Mhz it's probably more than enough a -5.
> 
> If you have core deeply below, like 4900, go for -15 and then add another -5 at every round until you get the max.
> If you see a Core that at -20 it runs at 4990 and it doesn't go further up with -25 or -30 better to go back to -20.
> You can check with CoreCycler later if you can get it lower stable.
> Lower the overall counts and better the all-core performances.
> It's to set a starting point, often a core that doesn't respond with a higher frequency going down with the count means is border-line stable.


That makes sense, very simple. I think this process is really much more simple than what I have read online elsewhere (start at -15 in bios, and go from there based on crashes/OCCT testing, etc). I felt at times that I was going around in circles in my head trying to figure out how to test this. So I really appreciate your input!!



ManniX-ITA said:


> Start with 0 in BIOS and watch the result of the first pass of BoostTester.


Lastly on this - should I start 0 in Bios, or should I disable PBO2 completely? Not sure if that will even make a difference or not. (That will of course mean that I won't be able to offset the coreclock).

Once again, thank you!


----------



## ManniX-ITA

cancel007 said:


> Just to confirm of what I should look at - in HWinfo64, there are Core Clocks and Core Effective Clocks (which show the different cores). When you are saying the effective clock per core should come close as possible to the *Fmax, *are you referring Fmax for the Core Clock and *reference clock* to the Core Effective Clock?


Not sure I understand sorry 
Don't look at the Core Clocks at all.
If you set +200 the max clock you need to use as a reference is 5050 MHz.

At the end after optimizing the COs, if you want to be sure all is working as expected you can check the Core Clocks.
You can compare the max with the effective clocks.
You should see the max Core Clock at 5050 MHz and the max Core Effective Clock something between 5000-5050. Or 5000 and 4950-5000.
If the delta is too big there's an issue, like 4950 effective and 5050 reference.
This delta should be no more than 50 MHz.



cancel007 said:


> That makes sense, very simple. I think this process is really much more simple than what I have read online elsewhere (start at -15 in bios, and go from there based on crashes/OCCT testing, etc). I felt at times that I was going around in circles in my head trying to figure out how to test this. So I really appreciate your input!!


It's a very simple method to get a good starting point especially with a single CCD.
But then you really need to test all is good with CoreCycler.
If you are fine with it, it's probably going to be very good already.
For sure using CoreCycler you can lower even more some cores and get even better results.
But then it's going to be very time consuming 



cancel007 said:


> Lastly on this - should I start 0 in Bios, or should I disable PBO2 completely? Not sure if that will even make a difference or not. (That will of course mean that I won't be able to offset the coreclock).


Start with 0 and enable PBO with the manual limits as above.
Without PBO2 enabled you can't set the boost clock at 200 usually.
You need to test it with the configuration you plan to use.


----------



## cancel007

ManniX-ITA said:


> Not sure I understand sorry
> Don't look at the Core Clocks at all.
> If you set +200 the max clock you need to use as a reference is 5050 MHz.
> 
> At the end after optimizing the COs, if you want to be sure all is working as expected you can check the Core Clocks.
> You can compare the max with the effective clocks.
> You should see the max Core Clock at 5050 MHz and the max Core Effective Clock something between 5000-5050. Or 5000 and 4950-5000.
> If the delta is too big there's an issue, like 4950 effective and 5050 reference.
> This delta should be no more than 50 MHz.


No worries  you just answered it for me!

Thanks for the help, I think that gave me a good start! I will try this method sometime this week! Thanks again!


----------



## ManniX-ITA

cancel007 said:


> Thanks for the help, I think that gave me a good start! I will try this method sometime this week! Thanks again!


You're welcome, let us know the outcome


----------



## cancel007

ManniX-ITA said:


> You're welcome, let us know the outcome


Will do! Might take a little longer since I need to find sometime to play around with the settings. But I will!


----------



## cancel007

ManniX-ITA said:


> And PJVol's PBO2 Tuner:
> 
> 
> 
> 
> 
> 
> Debug.7z
> 
> 
> 
> 
> 
> 
> 
> drive.google.com


Hey again. Out of curiosity where would I find the "official" copy of this? I didn't play with it yet, but I did execute it and it looks like an awesome tool. However, I cannot find it anywhere. I think this should be shared on a github somewhere.



ManniX-ITA said:


> For stress use y-cruncher together with OCCT.
> 12 cycles of stress test y-c all tests and you are sure it's rock solid.
> 
> y-cruncher - A Multi-Threaded Pi Program


Also for the y-cruncher, what would be the best settings for this? I am looking at the command lines txt and so much settings to choose from. I see some custom formulas pre-loaded in there too.

Thanks again!


----------



## ManniX-ITA

cancel007 said:


> Hey again. Out of curiosity where would I find the "official" copy of this? I didn't play with it yet, but I did execute it and it looks like an awesome tool. However, I cannot find it anywhere. I think this should be shared on a github somewhere.


It's a tool being developed by @PJVol 
There's no Github, he's sharing the download link here on OCN.



cancel007 said:


> Also for the y-cruncher, what would be the best settings for this? I am looking at the command lines txt and so much settings to choose from. I see some custom formulas pre-loaded in there too.


Just run it and you have a menu, select stress test, enable all tests, run

Otherwise you can use it via CoreCycler modifying the config.ini


----------



## cancel007

ManniX-ITA said:


> It's a tool being developed by @PJVol
> There's no Github, he's sharing the download link here on OCN.
> 
> 
> 
> Just run it and you have a menu, select stress test, enable all tests, run
> 
> Otherwise you can use it via CoreCycler modifying the config.ini


Too bad, this needs to be on github or somewhere. Super useful tool!

And alright sounds good on the y-cruncher. Will be playing with it this weekend for sure! Will post results once I get something decent. Thanks again and that was a very quick reply, appreciate it!


----------



## ManniX-ITA

cancel007 said:


> Too bad, this needs to be on github or somewhere. Super useful tool!
> 
> And alright sounds good on the y-cruncher. Will be playing with it this weekend for sure! Will post results once I get something decent. Thanks again and that was a very quick reply, appreciate it!


Made a video, hope it can help.
I'm not a "Youtuber" and neither a filmmaker so it's low quality... don't complain


----------



## cancel007

ManniX-ITA said:


> Made a video, hope it can help.
> I'm not a "Youtuber" and neither a filmmaker so it's low quality... don't complain


Great video, just watched it all! I haven't tried it yet but will play with it this weekend! I'm only worried about playing with +200mhz because currently I found a somewhat stable setting (previously to PBO2 tuber) that hasn't crashed in a few days but with +0mhz, and my 2 strongest cores are already at -5. So might not get good settings. 

My RAM is at 3200 mhz (XMP), do you know if it affects performance greatly vs a 3600 or 3800 mhz?


----------



## ManniX-ITA

cancel007 said:


> My RAM is at 3200 mhz (XMP), do you know if it affects performance greatly vs a 3600 or 3800 mhz?


I didn't test it with the 5800X.
Still Corecycling...
But yes on Ryzen the performances are tightly linked to memory.
On my 5950X just switching from the manually optimized profile to the horrible XMP profile leads to up to 20% decrease.
I'm not sure what is the impact on the 5800X.


----------



## cancel007

ManniX-ITA said:


> I didn't test it with the 5800X.
> Still Corecycling...
> But yes on Ryzen the performances are tightly linked to memory.
> On my 5950X just switching from the manually optimized profile to the horrible XMP profile leads to up to 20% decrease.
> I'm not sure what is the impact on the 5800X.


Oh wow. I would assume it will be similar to the 5800x. I think that's why I am so far away in the benchmarks from people with 3800 mhz or so. It's just an old RAM from my 5 3600 that I never bothered to upgrade. Thought of upgrading from 3200 to a 3600 a little bit of a side upgrade!

I will still try to use what I have and see what I get


----------



## ManniX-ITA

cancel007 said:


> I will still try to use what I have and see what I get


Are you sure isn't a Samsung B-die?
In that case you could be surprised about what it can do even if it's a 3200 MHz kit.


----------



## cancel007

ManniX-ITA said:


> Are you sure isn't a Samsung B-die?
> In that case you could be surprised about what it can do even if it's a 3200 MHz kit.


No it's a samsung c-die. DRAM calculator doesn't even have a c-die as an option so I never tried to overclock it.


----------



## ManniX-ITA

cancel007 said:


> No it's a samsung c-die. DRAM calculator doesn't even have a c-die as an option so I never tried to overclock it.


Ouch, C-Die is the worst


----------



## ArchStanton

cancel007 said:


> DRAM calculator doesn't even have a c-die as an option so I never tried to overclock it.


This video will demonstrate how to "import" the xmp file for a DIMM so that "manual" may be selected in the initial DCfR configuration. DCfR is still not 100% reliable, but this might be helpful if you pursue a memory overclock. How to Use the Ryzen DRAM Calculator 1.7.3 - YouTube


----------



## cancel007

ArchStanton said:


> This video will demonstrate how to "import" the xmp file for a DIMM so that "manual" may be selected in the initial DCfR configuration. DCfR is still not 100% reliable, but this might be helpful if you pursue a memory overclock. How to Use the Ryzen DRAM Calculator 1.7.3 - YouTube


Thanks good video! It's just that calculator doesn't have c-die in the option, so I don't even know how to get started with the numbers. At least if the option was there, I could get a base number and go off of that. But in my case nothing. Because mine is a c-die, I would probably just want to tighten the timings more than overclock the speed. But again, c-die is not an option


----------



## SneakySloth

First of all thank you for this amazing tool and for all the other tools linked in this thread, everyone here is absolutely amazing.

I upgraded from a 3600 -> 5900x and currently trying to see if I can find a curve that can help improve my performance a little. This is on the latest AGESA 1.2.0.5. Limits are set to PPT=190, TDC=140, EDC=160. I changed the limits to that based on cinebench r23 + Cpuz Bench results of stock limits vs various other combinations. My score went from 21,102 (stock) to 22,525(current limits) so I've stuck with those while tuning the CO.

My current curve is:










Current boost override is +50Mhz.

I tested that initially with a few iterations of CC with default settings and OCCT set to cycle cores (AVX2, Small, Extreme) every 2 minutes for a few hours.
As those initial tests didn't error out immediately I'm currently running CC with default settings but time per core changed to 10 minutes. That's been running for more than 11 hours now. Currently on the 6th iteration.

When I reach 12 hours I'm thinking of starting the Full FFT test for each core for each of SSE/AVX/AVX2 and maybe throw Y-cruncher in as well. Is that a decent plan to confirm stability?

This is what my Hwinfo looks like with the current settings and CC running.


----------



## ManniX-ITA

SneakySloth said:


> This is on the latest AGESA 1.2.0.5. Limits are set to PPT=190, TDC=140, EDC=160.


You are gaining something on all-core but at the expense of a massive loss on single core:










At over 140A the Core VIDs are limited below 1.4V.

I wouldn't spend so much time looking for counts in this scenario.


----------



## SneakySloth

ManniX-ITA said:


> You are gaining something on all-core but at the expense of a massive loss on single core:
> 
> View attachment 2551968
> 
> 
> At over 140A the Core VIDs are limited below 1.4V.
> 
> I wouldn't spend so much time looking for counts in this scenario.


Hm... my single core is the same on stock and with CO. Do you think there is anything else I can do to help improve the single core results?


----------



## ManniX-ITA

SneakySloth said:


> Hm... my single core is the same on stock and with CO. Do you think there is anything else I can do to help improve the single core results?


With that BIOS release you can only do it setting EDC at 140A in BIOS.
Then if you need also all-core the only option is to install Ryzen Master at set a higher EDC there.


----------



## SneakySloth

ManniX-ITA said:


> With that BIOS release you can only do it setting EDC at 140A in BIOS.
> Then if you need also all-core the only option is to install Ryzen Master at set a higher EDC there.


Would you suggest going back to BIOS with 1.2.0.3b and try CO with that AGESA? I'll try setting the EDC to 140 and see what my boosts/performance look like.


----------



## ManniX-ITA

SneakySloth said:


> Would you suggest going back to BIOS with 1.2.0.3b and try CO with that AGESA?


Unless it's a B2 stepping, 100% better 1.2.0.3b.


----------



## SneakySloth

ManniX-ITA said:


> Unless it's a B2 stepping, 100% better 1.2.0.3b.


It is B2 stepping. Is that a bad thing?


----------



## ManniX-ITA

SneakySloth said:


> It is B2 stepping. Is that a bad thing?


Try with 1.2.0.3b but there have been a lot of reports it doesn't work properly.


----------



## SneakySloth

I did a few tests with EDC at 140 and Core VID Effective is now going up to 1.5v. I'm boosting higher on all cores as well. Single core performance is a bit higher but nothing too drastic, multi core performance is higher than stock but slightly lower than before with EDC at 160.

I'll maybe just stick with EDC at 140 for now and try and optimize CO for this and see how well that works in the next 1-2 days. Otherwise, I'll just move back to stock and call it a day.

Currently testing FFT 16000-27000 based on what you said in the video you made in one of the previous posts (thank you for that). Gonna let that run overnight and see if any cores fail. Then maybe I'll start doing full FFTs for each of the Instructions.


----------



## ManniX-ITA

SneakySloth said:


> Currently testing FFT 16000-27000 based on what you said in the video you made in one of the previous posts (thank you for that).


Wonderful 



SneakySloth said:


> I'll maybe just stick with EDC at 140 for now and try and optimize CO for this and see how well that works in the next 1-2 days.


It's better to test with the full VID at EDC 140A.
I guess it's safe to say the CO counts will work also with VID capped.


----------



## Rujaza

ManniX-ITA said:


> Try with 1.2.0.3b but there have been a lot of reports it doesn't work properly.


What kind of problems? I'm on 1.2.0.3b with my 5900X B2 after some tests because newer AGESA gave me worst results.


----------



## SneakySloth

Rujaza said:


> What kind of problems? I'm on 1.2.0.3b with my 5900X B2 after some tests because newer AGESA gave me worst results.


Was it significantly worse or within a few percent points?


----------



## Rujaza

SneakySloth said:


> Was it significantly worse or within a few percent points?


CB20 MT @stock 8400pts vs 8100/8000pts, 100mhz to 150mhz slower all core in my case. Then I decided to work my curve on 1.2.0.3b.
Perhaps a different approach is needed to tune 1.2.0.4+ but since I hadn't any issue on 1.2.0.3b I kept it.


----------



## Owterspace

I gave up on my 5900X, its a real dud I think.. Dam core cycler lol..

I dropped in my 5600X and it blew right passed my 5900X that would throw an error within 10 minutes.

I only let it go for an hour or so..


----------



## ManniX-ITA

Rujaza said:


> CB20 MT @stock 8400pts vs 8100/8000pts, 100mhz to 150mhz slower all core in my case. Then I decided to work my curve on 1.2.0.3b.
> Perhaps a different approach is needed to tune 1.2.0.4+ but since I hadn't any issue on 1.2.0.3b I kept it.





Rujaza said:


> What kind of problems? I'm on 1.2.0.3b with my 5900X B2 after some tests because newer AGESA gave me worst results.


Couldn't test much my B2, blew my Windows install and had to send it back.
Mine was equally bad on both the old and new AGESA from what I've tested. 

But they told me bad boosting, stability issues, generally bad performances.
If the new one I'll get is a working one I'll test myself.


----------



## SneakySloth

I think my 5900x just isn't that great with CO. Although I can get it to boost higher in CB 23 and the results are 500-750 points better, but the amount of investment required to get this stable just doesn't seem worth it. In 3dmark the difference is at most 500 points. Single core is almost the same.

I just dialed in PBO settings and I'm just gonna go with that.

Thanks again for the tool though. I'm still going to use it to check if the processor is stable on stock settings.


----------



## cancel007

ManniX-ITA said:


> It's a tool being developed by @PJVol
> There's no Github, he's sharing the download link here on OCN.
> 
> 
> 
> Just run it and you have a menu, select stress test, enable all tests, run
> 
> Otherwise you can use it via CoreCycler modifying the config.ini


Hi again ManniX, 

I finally got the time to play with it. Messed around with it the whole end morning/afternoon. I followed your video and even used the same values in the config.ini as you had in yours. 

Using PBO2 Tuner and boost tester to match the effective clock with the reference clock was easy. I first tried at +200 mhz, then 150 mhz, all the way to +0 mhz (I had to change that in bios however, changing the boost using PBO2 Tuner was not working).

However, each time I would run corecycler with your settings (SSE, 2 min per core, 720-720) I would get errors immediately. Adjusting the curve would fix a few but the biggest issues I have were my two strongest cores. At +200, they would error out even at +0. So I kept going down with the core boost. My minimum curve values was making them at -5 for the strongest cores (core 5 and 7). If they would fail I would just lower my boost. 

At one point at 0 mhz (no boost), no curve values just 0. I got errors still. So I'm not sure if it's just a crappy silicon or not. Keep in mind at +0 mhz, I had curve values prior that I tested old school with just occt and cinebench and just everyday use and it seemed stable for 2 weeks until I started fresh today. I was at the -20,-25 values except my two strongest cores at -5.

I also tested using OCCT and cinebench after every curve change using pbo2 tuner, but had no errors or crashes. I tried y-cruncher by itself quickly too, I honestly didn't know what to fully choose but I ran it quickly with no issues (5-10 min). So corecycler is just making me fail. 

The only change to my system however is my RAM. I had to buy ram in another rig, so I figured I would buy a 3600 cl18 and put my old 3200s in the other rig. I bought corsair vengeance, two of them hoping that I will get a Samsung B-die, unfortunately I did not. I will return one. I got a hynix afr a-die, and a nanya a-die. Currently the nanya ram is in my PC at XMP 18-22-22-42.

So my questions I gusss are this:

1. What am I doing wrong? 
2. Can the new RAM be unstable for corecycler or in general? 
3. Attaining the effective clocks were easy. The lower the boost was the minimal curve values were. It makes me think that I can actually do +200 since I was reaching close to -5050 fine with -25,-20 and -5, -5 (on my two strongest cores) fine. At lower boost at +0 mhz, I reached 4850 with easy values of -5 and -10. What would happen if I go -25 for instance? It'll still reach the maximum 4850 but won't go over. However, cinebench scores do improve. 
4. I haven't tried the hynix a-die yet. Which ram would you recommend? The corsair kit with the nanya ram comes as AMD supported but the hynix kit comes with Intel supported which is why I didn't try it yet. 
5. Back to my problem, what am I doing wrong ? I don't want to be in the positive range of the curve to make it work. 

Edit: My ppt/tdc/edc are currently disabled in bios (testing them as default values first). 

Thank you,


----------



## PJVol

cancel007 said:


> At +200, they would error out even at +0


What bios your mb currently is running? Is it based on recent agesa versions, i.e. 1.2.0.4+ ?
Btw, changing PBO limits at runtime beyond the range set in BIOS is currently blocked by mb vendors, except Asrock, afaik.


----------



## ArchStanton

cancel007 said:


> 1. What am I doing wrong?


Possibly nothing, other than failing to set a + offset on the cores that are failing in CoreCycler. It is not unusual (in my experience) to have a core(s) that will fail 720k corecycler with both PBO2 DOCP disabled. This is technically "out of the box" instability, and AMD will honor an RMA if properly documented. The odds of receiving a replacement CPU back from the RMA that doesn't exhibit the same behavior? I cannot say. But of the 3 5950X's I had my hands on, 2 were unstable at stock (no DOCP/PBO2) and the third that I am currently using needs +3 on core0 to be stable at +0MHz (300PPT/160TDC/225EDC).

I would be 100% sure of my RAM *BEFORE *enabling PBO2, so that the variables in play are as limited as possible. Testmem5 (1usmusv3 config) x 25+ cycles plus some OCCT or y-cruncher (others can advise you better on RAM testing efficiency).

We'll see what the "pro" folks have to say. Best of luck with your tweaking .


----------



## cancel007

PJVol said:


> What bios your mb currently is running?


My bios is 1.2.0.2, running on a B450 board. I bought my 5800x at launch, and had major instability with it until this bios. So I never bothered to update it since stability was good.


----------



## cancel007

ArchStanton said:


> Possibly nothing, other than failing to set a + offset on the cores that are failing in CoreCycler. It is not unusual (in my experience) to have a core(s) that will fail 720k corecycler with both PBO2 DOCP disabled. This is technically "out of the box" instability, and AMD will honor an RMA if properly documented. The odds of receiving a replacement CPU back from the RMA that doesn't exhibit the same behavior? I cannot say. But of the 3 5950X's I had my hands on, 2 were unstable at stock (no DOCP/PBO2) and the third that I am currently using needs +3 on core0 to be stable at +0MHz (300PPT/160TDC/225EDC).
> 
> I would be 100% sure of my RAM *BEFORE *enabling PBO2, so that the variables in play are as limited as possible. Testmem5 (1usmusv3 config) x 25+ cycles plus some OCCT or y-cruncher (others can advise you better on RAM testing efficiency).
> 
> We'll see what the "pro" folks have to say. Best of luck with your tweaking .


Thanks for the response. I'll definitely test my ram with memtest86 first and perhaps other tools. I did test my old 3200 cl16 with memtest86 when I built this pc and it passed. Just didn't do it for this ram yet, kind of started playing with PBO2 without knowing if it's actually stable or not.

Could the system be generally stable with everyday use other than its failing 720 with corecycler? I'm curious whether my previous curve optimizer settings with my old ram would even pass. As it was pretty stable lol.


----------



## ManniX-ITA

cancel007 said:


> 4. I haven't tried the hynix a-die yet. Which ram would you recommend? The corsair kit with the nanya ram comes as AMD supported but the hynix kit comes with Intel supported which is why I didn't try it yet.


Buy a Samsung B-die kit, there are many at decent prices.
They are not cheap but I think it's worth.
Before buying anything check on B-die finder:






B-Die Finder


Find Samsung B-Die DDR 4 memory kits on Amazon, Newegg and many more.




benzhaomin.github.io





This is one pretty good:

F4-3600C14D-32GTZN 








G.SKILL Trident Z Neo Series 32GB (2 x 16GB) 288-Pin PC RAM DDR4 3600 (PC4 28800) Desktop Memory Model F4-3600C14D-32GTZN - Newegg.com


Buy G.SKILL Trident Z Neo Series 32GB (2 x 16GB) 288-Pin PC RAM DDR4 3600 (PC4 28800) Desktop Memory Model F4-3600C14D-32GTZN with fast shipping and top-rated customer service. Once you know, you Newegg!




www.newegg.ca







cancel007 said:


> 2. Can the new RAM be unstable for corecycler or in general?


Absolutely yes.
You need to be 1000% sure that memory is fine.

Run TM5 with 25 cycles:





TM5_1usmusv3_25cycles.zip







drive.google.com







cancel007 said:


> 3. Attaining the effective clocks were easy. The lower the boost was the minimal curve values were. It makes me think that I can actually do +200 since I was reaching close to -5050 fine with -25,-20 and -5, -5 (on my two strongest cores) fine. At lower boost at +0 mhz, I reached 4850 with easy values of -5 and -10. What would happen if I go -25 for instance? It'll still reach the maximum 4850 but won't go over. However, cinebench scores do improve.


That's the max boost clock.
Lower you can go and higher the sustained clock will be.
If you check the max clock you can reach with CoreCycler SSE FFT 720K it's probably going to be around 4900 MHz.
Lower you go and higher you can run heavier workloads.
And MT/all-core will be higher as well; more cores will have a more negative co and higher the common clock they'll settle.



cancel007 said:


> 1. What am I doing wrong?


From what you describe it's probably the mainboard or the settings.
What mainboard do you have?

It's easier to get stable an all-core with lower clock than a single core at a high clock.
You may need to bump up a lot of stuff.
Like VSOC and VDDG CCD/IOD.
If you have PWM phase/frequency settings bump them up, SOC may need a strong manual LLC, CPU maybe as well (depends on the board).
On ASUS is more tricky as there are many options for VRM and maxing some it's often more destabilizing than stabilizing.

You can save screenshots from the BIOS on a USB stick with F12, post them here in a spoiler.
Some mainboards are just not up to the task but if you say it's unstable at +0 then it's more likely a matter of settings.


----------



## cancel007

ManniX-ITA said:


> Buy a Samsung B-die kit, there are many at decent prices.
> They are not cheap but I think it's worth.
> Before buying anything check on B-die finder:
> 
> 
> 
> 
> 
> 
> B-Die Finder
> 
> 
> Find Samsung B-Die DDR 4 memory kits on Amazon, Newegg and many more.
> 
> 
> 
> 
> benzhaomin.github.io
> 
> 
> 
> 
> 
> This is one pretty good:
> 
> F4-3600C14D-32GTZN
> 
> 
> 
> 
> 
> 
> 
> 
> G.SKILL Trident Z Neo Series 32GB (2 x 16GB) 288-Pin PC RAM DDR4 3600 (PC4 28800) Desktop Memory Model F4-3600C14D-32GTZN - Newegg.com
> 
> 
> Buy G.SKILL Trident Z Neo Series 32GB (2 x 16GB) 288-Pin PC RAM DDR4 3600 (PC4 28800) Desktop Memory Model F4-3600C14D-32GTZN with fast shipping and top-rated customer service. Once you know, you Newegg!
> 
> 
> 
> 
> www.newegg.ca
> 
> 
> 
> 
> 
> 
> 
> Absolutely yes.
> You need to be 1000% sure that memory is fine.
> 
> Run TM5 with 25 cycles:
> 
> 
> 
> 
> 
> TM5_1usmusv3_25cycles.zip
> 
> 
> 
> 
> 
> 
> 
> drive.google.com
> 
> 
> 
> 
> 
> 
> 
> That's the max boost clock.
> Lower you can go and higher the sustained clock will be.
> If you check the max clock you can reach with CoreCycler SSE FFT 720K it's probably going to be around 4900 MHz.
> Lower you go and higher you can run heavier workloads.
> And MT/all-core will be higher as well; more cores will have a more negative co and higher the common clock they'll settle.
> 
> 
> 
> From what you describe it's probably the mainboard or the settings.
> What mainboard do you have?
> 
> It's easier to get stable an all-core with lower clock than a single core at a high clock.
> You may need to bump up a lot of stuff.
> Like VSOC and VDDG CCD/IOD.
> If you have PWM phase/frequency settings bump them up, SOC may need a strong manual LLC, CPU maybe as well (depends on the board).
> On ASUS is more tricky as there are many options for VRM and maxing some it's often more destabilizing than stabilizing.
> 
> You can save screenshots from the BIOS on a USB stick with F12, post them here in a spoiler.
> Some mainboards are just not up to the task but if you say it's unstable at +0 then it's more likely a matter of settings.


My board is B450 gaming plus max. Just shy away from a tomahawk max, pretty much the same board. 

I think you mentioned you have an msi board as well. Where in the bios would you like me to go exactly and take screenshots? 

Now is getting a Samsung B-die actually matters? If I know the RAM is stable, does it actually matter in terms of why I'm getting errors with cc? Keep in mind I'm running all stock settings other than PBO2 curve values and/or offset.


----------



## ManniX-ITA

cancel007 said:


> Now is getting a Samsung B-die actually matters? If I know the RAM is stable, does it actually matter in terms of why I'm getting errors with cc? Keep in mind I'm running all stock settings other than PBO2 curve values and/or offset.


It matters about performances. If the RAM is stable you will not get errors in CC for that.
The stock settings a re more likely the cause.



cancel007 said:


> I think you mentioned you have an msi board as well. Where in the bios would you like me to go exactly and take screenshots?


In the overclocking menu and DIGITALL.


----------



## cancel007

ManniX-ITA said:


> Run TM5 with 25 cycles:
> 
> 
> 
> 
> 
> TM5_1usmusv3_25cycles.zip
> 
> 
> 
> 
> 
> 
> 
> drive.google.com


I'm going to run it right now then I'll take a the bios screenshots.

I started running it as administrator, but it still gave me a notification as I opened it saying "to enable awe you must run with administrator privileges". A bit weird, but it still runs the tests as I click through the notifications. Hopefully it's still ok and I don't have to do anything else.



Thank you again


----------



## KedarWolf

cancel007 said:


> I'm going to run it right now then I'll take a the bios screenshots.
> 
> I started running it as administrator, but it still gave me a notification as I opened it saying "to enable awe you must run with administrator privileges". A bit weird, but it still runs the tests as I click through the notifications. Hopefully it's still ok and I don't have to do anything else.
> 
> 
> 
> Thank you again


After you open it, close it, reboot, and the error will be gone.


----------



## cancel007

KedarWolf said:


> After you open it, close it, reboot, and the error will be gone.


It's been running for about an hour and some now on cycle 10. It's still testing right?


----------



## KedarWolf

cancel007 said:


> It's been running for about an hour and some now on cycle 10. It's still testing right?


You really should reboot once for it to test right.


----------



## cancel007

ManniX-ITA said:


> TM5_1usmusv3_25cycles.zip
> 
> 
> 
> 
> 
> 
> 
> drive.google.com


The first run did not give me any errors. However, I also had this administrator privileges error prior to that. I have rebooted and will run it again overnight. But for now I do not have any errors with the RAM. So we can assume the RAM is not the issue.




ManniX-ITA said:


> You can save screenshots from the BIOS on a USB stick with F12, post them here in a spoiler.


Here you go as requested. Thank you!!



Spoiler: MSI Overclocking Menu

















Spoiler: MSI Overclocking Menu Continued

















Spoiler: DigitALL

















Spoiler: Advanced CPU Configuration Menu

















Spoiler: AMD CBS

















Spoiler: AMD Overclocking















Once again, I do greatly appreciate the help!! Thank you!


----------



## ManniX-ITA

cancel007 said:


> Once again, I do greatly appreciate the help!! Thank you!


What CCD and IOD are you running now?
Post a Zentimings screenshot too.
If you can't see it there check on HWInfo Summary for the CPU.


----------



## cancel007

ManniX-ITA said:


> What CCD and IOD are you running now?





Spoiler: ZenTimings















Here you go. Unfortunately, it does not load the VDDG CCD/IOD because the I/O driver cannot load. I read online it is because of the Valorant anti-cheat that I have installed. However, I did find those values in RyzerMaster.



Spoiler: RM RAM Timings / CCD & IOD


----------



## ManniX-ITA

cancel007 said:


> Here you go. Unfortunately, it does not load the VDDG CCD/IOD because the I/O driver cannot load. I read online it is because of the Valorant anti-cheat that I have installed. However, I did find those values in RyzerMaster.


Yep the voltages are messed up...

Start setting SOC Voltage to 1.2V, CCD to 1000mV and IOD to 1050mV.
SOC it's high but you can lower it down later.
Set manual VDDP to 900mV.
Check with Ryzen Master the values have been changed.

Consider that the Valorant anti-cheat could be a cause for CoreCycler failing as well.

Test with CoreCycler if with 0 CO count, +0 Boost clock and the 720K FFT it can pass.
If it's passing start testing with +100/+200 boost clock.

If it doesn't change in DIGITALL the CPU/SOC Over Current to Enhanced and Over/Under Voltage to max values.
Check again and if you can't pass try setting the CPU and SOC Loadline to Level 3.


----------



## cancel007

ManniX-ITA said:


> Yep the voltages are messed up..


Do you they are messed up because of the RAM or the motherboard? 



ManniX-ITA said:


> Consider that the Valorant anti-cheat could be a cause for CoreCycler failing as well.


I haven't played Valorant in forever. I actually always close it when I start windows. I might uninstall it and see what happens as well.



ManniX-ITA said:


> Start setting SOC Voltage to 1.2V, CCD to 1000mV and IOD to 1050mV.
> SOC it's high but you can lower it down later.
> Set manual VDDP to 900mV.


Just confirming - I should change these settings in bios?



ManniX-ITA said:


> Check again and if you can't pass try setting the CPU and SOC Loadline to Level 3.


Just confirming as well - There is CPU Load line and CPU NB load line. You are just referring to the CPU LCC correct? I do want to mention that when I set a static voltage with Ryzen master as a test, the vcore in hwinfo64 is always a little higher. In addition the +12 rail is not 12.00V, its around 12.096V.


----------



## ManniX-ITA

cancel007 said:


> Do you they are messed up because of the RAM or the motherboard?


No it's the Auto voltages, it's an AMD issue.



cancel007 said:


> I haven't played Valorant in forever. I actually always close it when I start windows. I might uninstall it and see what happens as well.


Better to uninstall it, at least the anti-cheat.
You can re-install it easily if you need it.



cancel007 said:


> Just confirming - I should change these settings in bios?


Yes



cancel007 said:


> Just confirming as well - There is CPU Load line and CPU NB load line. You are just referring to the CPU LCC correct? I do want to mention that when I set a static voltage with Ryzen master as a test, the vcore in hwinfo64 is always a little higher. In addition the +12 rail is not 12.00V, its around 12.096V.


Both of them.
SOC is usually the first that can create an issue if Auto.
Static is a completely different beast. Also the 12V rail.
Try first with the voltages and then go on with the rest if you still not pass.
It's better to know what is limiting if you can achieve a pass.


----------



## cancel007

ManniX-ITA said:


> Start setting SOC Voltage to 1.2V


In bios, this has two options. If I set CPU NB/Soc voltage to override mode, it'll let me change CPU NB/Soc, if I choose "AMD overclocking" it'll let me change SOC voltage. Do I choose AMD overclocking for this?


----------



## SneakySloth

Do it through the CPU NB/SOC voltage entry.


----------



## cancel007

SneakySloth said:


> Do it through the CPU NB/SOC voltage entry.


I tried both. The CPU NB/SOC entry made it worse (more cores failed) .



ManniX-ITA said:


> Start setting SOC Voltage to 1.2V, CCD to 1000mV and IOD to 1050mV.
> SOC it's high but you can lower it down later.
> Set manual VDDP to 900mV.
> Check with Ryzen Master the values have been changed.
> 
> Consider that the Valorant anti-cheat could be a cause for CoreCycler failing as well.
> 
> Test with CoreCycler if with 0 CO count, +0 Boost clock and the 720K FFT it can pass.
> If it's passing start testing with +100/+200 boost clock.
> 
> If it doesn't change in DIGITALL the CPU/SOC Over Current to Enhanced and Over/Under Voltage to max values.
> Check again and if you can't pass try setting the CPU and SOC Loadline to Level 3.


Alright I did everything. Just for your awareness, the valorant anti-cheat didn't do anything or fix the I/O driver issue with the zentimings. I also passed the TM5 25 cycles with no issues again this morning.

Everything up to the LCC didn't do much. The strongest 2 cores (5 and 7) are my trouble cores. They both failed almost immediately, and the rest of the cores failed too, some passed but after 3-4-5 consecutive fails I just stopped CoreCycler. This is with +0 boost. I didn't try more than that before +0 was failing. 

However, using the CPU SOC entry (AMD Overclocking) and LCC 3 for both NB and CPU, everything passed BUT core 7. I did two runs. When I changed the CPU NB/SOC entry to 1.2V, they were failing, so I switched back and again only core 7 passed. Should I increase the LCC value?

Just to note, when I changed the voltage values, verifying with RM, they are a tad bit off, not sure if that is normal. Here are the screenshots of the setup. Again thanks for the help!



Spoiler: CoreCycler Set-up Values

















Spoiler: Voltage values with SOC only

















Spoiler: Voltage values with SOC/NB

















Spoiler: DigitALL without LCC

















Spoiler: DigitALL with LCC

















Spoiler: RM values confirmation


----------



## ManniX-ITA

cancel007 said:


> Just to note, when I changed the voltage values, verifying with RM, they are a tad bit off, not sure if that is normal. Here are the screenshots of the setup. Again thanks for the help!


That's normal



cancel007 said:


> However, using the CPU SOC entry (AMD Overclocking) and LCC 3 for both NB and CPU, everything passed BUT core 7. I did two runs. When I changed the CPU NB/SOC entry to 1.2V, they were failing, so I switched back and again only core 7 passed. Should I increase the LCC value?


I don't understand...
Can you explain?
What passed with?

If VSOC is a problem lower it, go to 1.15V.
You may need to adjust CCD voltage.
Try with 950mV and 1050mV.
LLC 3 for CPU should be enough.
Considering you see an issue with VSOC try to set NB LLC to 2.


----------



## cancel007

ManniX-ITA said:


> I don't understand...
> Can you explain?
> What passed with?


In bios, this has two options when change CPU SOC. If I set CPU NB/Soc voltage to "override mode" , it'll let me change "CPU NB/SOC" , if I choose "AMD overclocking" it'll let me change "SOC voltage". Choosing AMD overclocking and changing the SOC voltage only rather than NB/SOC made all cores pass except core 7. My two strongest cores are 5 and 7 based on Ryzen master and the hwinfo64 core orders. Those two always failed pretty much immediately and together. 

With LLC and SOC voltage (as mentioned above), only core 7 fails. I still can't pass fully one iteration with CoreCycler though 😔. Still better than before. 



ManniX-ITA said:


> If VSOC is a problem lower it, go to 1.15V.
> You may need to adjust CCD voltage.
> Try with 950mV and 1050mV.
> LLC 3 for CPU should be enough.
> Considering you see an issue with VSOC try to set NB LLC to 2.


At this point as I'm still failing. What should I adjust first, VSOC? And if it keeps failing, go back to 1.2V change CCD?


----------



## ManniX-ITA

cancel007 said:


> At this point as I'm still failing. What should I adjust first, VSOC? And if it keeps failing, go back to 1.2V change CCD?


Try increasing LLC for SoC and test 1.15V and 1.225V.
I'm not sure if it's helping more or less.
AMD OC usually sets a higher VSOC in feeding than OC, maybe wants more.
But 1.2V should be plenty enough.
Could be something weird about the B450 chipset.

Could also be that the Core 7 is failing for another issue and the VSOC is perfectly fine.
Try with the LLC and if not check if Core 7 can pass with a different CCD voltage.


----------



## cancel007

ManniX-ITA said:


> Try increasing LLC for SoC and test 1.15V and 1.225V.
> I'm not sure if it's helping more or less.
> AMD OC usually sets a higher VSOC in feeding than OC, maybe wants more.
> But 1.2V should be plenty enough.


I changed the CPU LLC to mode 4 and it passed both core 7 and 5. This is only at +0 mhz and as as per the settings you mentioned earlier: VSOC 1.2V, CCD 1000mV, IOD 1050mV, VDDP 900mV and CPU NB mode 3.

Are there any adjustments now that I should do so the voltages are not too much before I start finding the right co curve? Or should I test higher offset first as well?

Should I also leave CPU NB LLC at mode 3 or change it back to auto?

Thank you again, I know I keep saying it but much appreciated! At least now I passed one iteration lol 😁

EDIT: I let it run for 2 iterations, it did fail core 7 but during the second iteration. How many iterations should I see this pass before I can deem this "Stable" and carry on with finding curve settings. 

Also, Prime95 is running in the background and when you open it, everything has "passed" there are no errors. Is this normal that CoreCycle is showing an error but Prime95 does not?


----------



## ArchStanton

cancel007 said:


> Is this normal that CoreCycle is showing an error but Prime95 does not?


This is tangential to your question (that I will not attempt to answer), be aware that CoreCycler will keep a log file for both itself and prime95.


----------



## ManniX-ITA

cancel007 said:


> I changed the CPU LLC to mode 4 and it passed both core 7 and 5. This is only at +0 mhz and as as per the settings you mentioned earlier: VSOC 1.2V, CCD 1000mV, IOD 1050mV, VDDP 900mV and CPU NB mode 3.


Try with the CCD voltage adjustments and check also with IOD at 1100mV, even if it's unlikely, 1050mV should be enough.
For the SOC LLC you can try again with Auto but will probably make it worse.
I'd try with LLC 2 or 4 to see what happens.

Move to 10 minutes runtime for CoreCycler, 2 minutes it's only for a very quick check.

Before you go down with voltages you need to test fully the cores.


----------



## cancel007

ManniX-ITA said:


> Try with the CCD voltage adjustments and check also with IOD at 1100mV, even if it's unlikely, 1050mV should be enough.
> For the SOC LLC you can try again with Auto but will probably make it worse.
> I'd try with LLC 2 or 4 to see what happens


Just confirming - when you say SOC LLC do you refer to CPU LLC and not CPU NB LLC correct? Because currently my CPU LLC is set to 4, and it passed one iteration. If I go to auto it'll fail because I tried it earlier when it was auto. I haven't tried 2 yet.

So for trying out changing IOD and CCD, am I trying to change to pass a 10 min per core if I can't with the current settings?


----------



## ManniX-ITA

cancel007 said:


> So for trying out changing IOD and CCD, am I trying to change to pass a 10 min per core if I can't with the current settings?


Yes, aim to pass 10 minutes.
If you want to shorten time test only 3 and 7 and another core, best would be 0.



cancel007 said:


> Just confirming - when you say SOC LLC do you refer to CPU LLC and not CPU NB LLC correct? Because currently my CPU LLC is set to 4, and it passed one iteration. If I go to auto it'll fail because I tried it earlier when it was auto. I haven't tried 2 yet.


SOC LLC is CPU NB LLC.


----------



## sp00n82

ManniX-ITA said:


> SOC LLC is CPU NB LLC.


Maybe for a deeper understanding and to minimize confusion in the future:
"NB" stands for NorthBridge, which was a dedicated chipset on motherboards a couple of years ago. Nowadays it is integrated into the CPU itself, as a "System on a Chip" = SoC.
So effectively the CPU NorthBridge settings (CPU NB) are now the System on a Chip (SOC) settings. Some motherboard manufacturers name it one way, some the other.


----------



## PJVol

sp00n82 said:


> Maybe for a deeper understanding and to minimize confusion in the future:


To minimize it better ask MSI(or AMD) not to give ambigous/legacy/deprecated names to the BIOS menu entries. ASRock bios doesn't mention "NB" anywhere.


----------



## ManniX-ITA

PJVol said:


> To minimize it better ask MSI(or AMD) not to give ambigous/legacy/deprecated names to the BIOS menu entries. ASRock bios doesn't mention "NB" anywhere.


You are both wrong 
For a B450 that's not legacy, it's a mainboard which was meant to support up to Ryzen 2000.
Not an MCM but a Monolithic CPU with integrated NorthBridge and SouthBridge.
Ryzen 3000 and 5000 have replaced the NB and more with the cIOD which has been named SOC in BIOS (without much sense in my opinion).
So the setting is inherited from legacy but the convention NB is the right one for that motherboard and earlier.


----------



## cancel007

ManniX-ITA said:


> Try with the CCD voltage adjustments and check also with IOD at 1100mV, even if it's unlikely, 1050mV should be enough.
> For the SOC LLC you can try again with Auto but will probably make it worse.
> I'd try with LLC 2 or 4 to see what happens.
> 
> Move to 10 minutes runtime for CoreCycler, 2 minutes it's only for a very quick check.
> 
> Before you go down with voltages you need to test fully the cores.


Alright so when I do the 10 min run time, core 7 fails almost instantly. I had it run for 30 min the first try, the cores after that passed so core 7 is my trouble maker.

I have tried IOD 1.1V, CCD 950 mV and 1050 mV. I tried SOC LLC 2 and then 4. I even tried CPU LLC 5. I also tried vSOC 1.15V. All those settings did not change the outcome of core 7 to fail pretty much instantly.


----------



## ArchStanton

cancel007 said:


> All those settings did not change the outcome of core 7 to fail pretty much instantly.


Chin up my man, I salute you and Mannix both for your efforts on this particular quandary .


----------



## ManniX-ITA

cancel007 said:


> Alright so when I do the 10 min run time, core 7 fails almost instantly. I had it run for 30 min the first try, the cores after that passed so core 7 is my trouble maker.


Yes at this point I think that nothing can be done for Core 7.
Only hope is to have it pass with a positive CO.
Than you can try adding MHz to the boost clock and see if the others are still passing.


----------



## cancel007

ArchStanton said:


> Chin up my man, I salute you and Mannix both for your efforts on this particular quandary .


Yeah it's frustrating! At least not all cores fail to this time. So still an improvement! I do definitely appreciate his assistance and patience with me! 




ManniX-ITA said:


> Yes at this point I think that nothing can be done for Core 7.
> Only hope is to have it pass with a positive CO.
> Than you can try adding MHz to the boost clock and see if the others are still passing.


Do you think at this point its just my silicon, my MB or a combo of both?

I will try positive co on that core and see if I can get a pass. Best case scenerio if I do manage to get a pass, which voltages are too high at the moment for 24/7 PBO2 that I should drop down a bit (and test again of course)?

Once again thank you for the help! I wish it this small journey would of been easier lol.


----------



## ManniX-ITA

cancel007 said:


> Do you think at this point its just my silicon, my MB or a combo of both?


More likely silicon.
You should try to measure the performances to see how Core 7 is performing.
It could be faster with positive CO than any other with negative CO.
Try to find where it works and how much high you can go with boost clock.
Then see if it's boosting lower than Core 3, the other best, or same/better.

Could be also the motherboard but I'm not really sure, less likely.

For voltages 950/1000mV CCD and 1000/1050mV with 1.12-1.16V could be enough.
My suggestion is to check with benchmarks.
When you are done with these voltages and got all stable with CC run GeekBench 5 and CB23.
With GB5 you can upload the score and set it as baseline in the online browser.
Then you can lower first CCD, then IOD, then VSOC.
Each time run GB5 and CB23 MT to see if you are loosing performances.
If you see lower perf don't scale down.

Of course once you have scaled down you need to do again a check with CC that all is good and not failing.
Maybe not the whole FFT but at least 128K, 720K and 16000-27000K.


----------



## PJVol

ManniX-ITA said:


> You are both wrong



There's no NB outside of CPU package since Zen.


----------



## ManniX-ITA

PJVol said:


> There's no NB outside of CPU package since Zen.


Yeah that's what I said 



ManniX-ITA said:


> For a B450 that's not legacy, it's a mainboard which was meant to support up to Ryzen 2000.
> Not an MCM but a *Monolithic CPU with integrated NorthBridge and SouthBridge.*


The NB reference is about the NorthBridge in the CPU package.
Old boards don't get settings labels updated for the new CPUs and new boards don't get labels considering the old CPUs (NB instead of SOC).
For a B450 using NB is as intended.


----------



## ArchStanton

cancel007 said:


> Do you think at this point its just my silicon, my MB or a combo of both?


Or AMD's imperfect and often overly optimistic process for generating the per core factory v/f curves that Curve Optimizer is only modifying?

Edit: No, I'm serious. Sometimes they just get it wrong. There are plenty of other posters here on OCN running AMD rigs with CPU's that have cores that AMD classified as the "best", but that are actually the 2nd or even 3rd/worse performers after tuning and verifying performance. I think there are a number of people that pay very close attention to the setting of "CPPC" and "CPPC preferred cores" in light of this.


----------



## cancel007

ManniX-ITA said:


> More likely silicon


Prior to trying out your settings. I had everything on stock settings/auto. I had some curve settings that seemed stable since I didn't crash for a few weeks. And I did it the other method which was looking at WHEA errors and seeing which core crashes. Then I changed the negative curve values by - 5 until it stopped crashing and was stable. And so I thought it was! I'm sure it would of failed CoreCycler lol. 




ManniX-ITA said:


> Maybe not the whole FFT but at least 128K, 720K and 16000-27000K


My current enemy is the 720k FFT 😄, I think once I can pass this one I'll move on unless you think otherwise lol.



ManniX-ITA said:


> More likely silicon.
> You should try to measure the performances to see how Core 7 is performing.
> It could be faster with positive CO than any other with negative CO.
> Try to find where it works and how much high you can go with boost clock.
> Then see if it's boosting lower than Core 3, the other best, or same/better.


Too bad I'm having this issue but it was fun playing with it! I'll definitely try positive curve and see if core 7 passes. But the settings that I have right now got rid of all the others core failing so at least the problem got narrowed down a little. 

At this point, I will leave the original settings that made me pass the 2 min CC for core 7 since it seemed the "most' stable (your initial voltage suggestions, SoC LLC at 3, and CPU LLC 4) and start using positive co numbers to hopefully make core 7 pass! 

I do very much appreciate your help and patience! Based on this forums discussions and assistance to others and myself, I definitely appreciate this community!

When I get something stable I'll post an update! (hopefully it'll be good news lol 😊)


----------



## cancel007

ArchStanton said:


> Or AMD's imperfect and often overly optimistic process for generating the per core factory v/f curves that Curve Optimizer is only modifying?


Majority of people that I know and have seen, they did not attempt to find a curve with this method (PBO2 tuner, CoreCycler, etc). They do it the classic method of setting everything to -15 and adjust based in WHEA errors. Majority claim to have their system "stable", but I bet if they try CoreCycler they will fail.

I'm sure for everyday use, I could probably do the same thing and have a system that I claim "stable". But I'll now always have that thought at the back of my head that it is not because I can't pass one 10m CoreCycler iteration.


----------



## cancel007

ManniX-ITA said:


> More likely silicon


One more thing - do you think my agesa version could have anything to do with this?


----------



## ArchStanton

cancel007 said:


> Majority of people that I know and have seen, they did not attempt to find a curve with this method (PBO2 tuner, CoreCycler, etc). They do it the classic method of setting everything to -15 and adjust based in WHEA errors. Majority claim to have their system "stable", but I bet if they try CoreCycler they will fail.
> 
> I'm sure for everyday use, I could probably do the same thing and have a system that I claim "stable". But I'll now always have that thought at the back of my head that it is not because I can't pass one 10m CoreCycler iteration.


I 100% agree. Also, see my edit of post #696. I have alternate BIOS profiles for certain benchmarks if I want to try to have a big "epeen". For day-to-day use, I want 100% stable (and that turned out to be a lot more work for a little less gain than a newb like me would have initially guessed, but the journey was/is enjoyable/educational) .


----------



## ManniX-ITA

cancel007 said:


> One more thing - do you think my agesa version could have anything to do with this?


There's a chance yes but not that high.
How many options you have for that board?


----------



## cancel007

ArchStanton said:


> I 100% agree. Also, see my edit of post #696. I have alternate BIOS profiles for certain benchmarks if I want to try to have a big "epeen". For day-to-day use, I want 100% stable (and that turned out to be a lot more work for a little less gain than a newb like me would have initially guessed, but the journey was/is enjoyable/educational) .


Yeah I would definitely like to see what my chip is capable of. If it just keeps failing the test, I'll either just go back to stock or just find a curve that is stable enough for everyday use (again, I still rather have 100% stability) lol. It's just that once you get a taste of a benchmark that was improved and scores are higher, you kind of don't want to go back even though you don't actually feel it for normal use. It is what it is 😊


----------



## cancel007

ManniX-ITA said:


> There's a chance yes but not that high.
> How many options you have for that board?


The next version currently above 1.2.0.2 is 1.2.0.5. I'm hesitant of updating it (as well as the amd chipset) because I'm finally not getting any crashes. Initially when I got the 5800x, I've experienced stability issues like the many complaints I've seen online. Until I updated to 1.2.0.2 and the amd chipset at that time. I haven't experienced any WHEA crashes or just crashes overall since other than when I'm tinkering with settings. 

I have been seeing some instability comments from the new agesa so it doesn't make enthusiastic about updating.

EDIT: I have recently built another PC. It uses a B450 tomahawk max. Essentially the same board as mine, except the vram is probably slightly better. Don't think it's worth the hassle changing it to my main PC because it is still a B450 board, and almost identical.


----------



## cancel007

ManniX-ITA said:


> Yes at this point I think that nothing can be done for Core 7.


Hello again!

I will be trying positive curve value for core 7 today and see how it works out. I did have a look at the CoreCycler log, and I noticed that it could not set a speed for core 7 at all. In the begining before I was changing bios settings, it set speed tested it and failed but the fatal error is because the CPU usage is too low and it throws an error. Any thought on this? Should I be trying a different FFTsize? I have copied pasted the log from CoreCycler below:



Spoiler: Core 7 CoreCycler (Log)



11:00:15 - Set to Core 7 (CPU 14)
+ Setting the affinity to 16384
+ Successfully set the affinity to 16384
Running for 10 minutes...
+
+ 11:00:15 - Getting new log file entries
+ The stress test log file doesn't exist yet
+
+ 11:00:25 - checking CPU usage: 0%
+ 11:00:25 - ...the CPU usage was too low, waiting 2000ms for another check...
+ Process Id: 12860
+ 11:00:25 - checking CPU usage again (#1): 0%
+ still not enough usage (#1)
+ 11:00:25 - ...the CPU usage was too low, waiting 2000ms for another check...
+ Process Id: 12860
+ 11:00:25 - checking CPU usage again (#2): 0%
+ still not enough usage (#2)
+ 11:00:25 - ...the CPU usage was too low, waiting 2000ms for another check...
+ Process Id: 12860
+ 11:00:25 - checking CPU usage again (#3): 0%
+ still not enough usage, throw an error
+ There has been an error with the stress test program!
+ Error type: CPULOAD
+ 11:00:39 - The stress test program is Prime95, trying to look for an error message in the results.txt
+ 11:00:39 - Getting new log file entries
+ Getting new log entries starting at position 0 / Line 0
+ The new log file entries:
+ - [Line 1] [Fri Mar 25 11:00:15 2022]
+ - [Line 2] FATAL ERROR: Rounding was 0.5, expected less than 0.4
+ - [Line 3] Hardware failure detected running 720K FFT size, consult stress.txt file.
+ New file position: 158 / Line 3
+
+ 11:00:39
+ Now found an error in the new entries of the results.txt!
ERROR: 11:00:39
ERROR: Prime95 seems to have stopped with an error!
ERROR: At Core 7 (CPU 14)
ERROR MESSAGE: FATAL ERROR: Rounding was 0.5, expected less than 0.4
+ The maximum FFT size is within the range where we can still make an educated guess about the failed FFT size
+ No results.txt exists yet, assuming the error happened on the first FFT size


----------



## PJVol

ManniX-ITA said:


> The NB reference is about the NorthBridge in the CPU package.
> Old boards don't get settings labels updated for the new CPUs and new boards don't get labels considering the old CPUs (NB instead of SOC).
> For a B450 using NB is as intended.


Yeah, I see. I mean there's no NB inside Zen either  
"NB" is iirc from Family 15h, and i didn't know Buldozer CPUs are supported on B450 boards.


----------



## ManniX-ITA

cancel007 said:


> I did have a look at the CoreCycler log, and I noticed that it could not set a speed for core 7 at all. In the begining before I was changing bios settings, it set speed tested it and failed


What do you mean with set a speed for the core?



cancel007 said:


> but the fatal error is because the CPU usage is too low and it throws an error. Any thought on this? I have copied pasted the log from CoreCycler below:


From what I see in the logs the script is detecting that Prime95 wasn't running anymore and then parsed the P95 and found the error in results.txt:

_+ 13:35:18 - The stress test program is Prime95, trying to look for an error message in the results.txt

13:35:18 - Getting new log file entries
Getting new log entries starting at position 0 / Line 0
The new log file entries:
- [Line 1] [Fri Mar 25 13:34:54 2022]
- [Line 2] FATAL ERROR: Rounding was 0.5, expected less than 0.4
- [Line 3] Hardware failure detected running 720K FFT size, consult stress.txt file.
New file position: 158 / Line 3 
_

At 13:35:18 a script error CPULOAD was triggered cause the usage load on the core was consistently too low.
The error happened in P95 at 13:34:54 which is the same time P95 was started, immediately.


----------



## ManniX-ITA

PJVol said:


> Yeah, I see. I mean there's no NB inside Zen either


I don't get it 
Zen is a monolithic design with NB and SB inside AFAIK.
What is your understanding of NB?

I mean Zen based CPUs: Ryzen 1000/2000 in this case


----------



## ArchStanton

ManniX-ITA said:


> the same time P95 was started, immediately.


And presumably the time for initial "maximum boost" before any form of throttling can kick?


----------



## ManniX-ITA

ArchStanton said:


> And presumably the time for initial "maximum boost" before any form of throttling can kick?


Yes but considering it's boost clock +0 and single core load the throttling should be minimal.
Crashing so quickly means it's very unstable unfortunately.


----------



## cancel007

ManniX-ITA said:


> What do you mean with set a speed for the core?


So +10 co on core7 passes the 2 min in CoreCycler (I have not tried 10m yet). I did it a few times to make sure it was not a one time thing (I went back to +5 but it failed). The following log is what I see, and you can see it is able to set a speed to the core so it can test it vs the other log where it cannot even set a speed because usage is considered "too low"?



Spoiler: core 7 pass log



13:57:26 - Set to Core 7 (CPU 14)
+ Setting the affinity to 16384
+ Successfully set the affinity to 16384
Running for 2 minutes...
+
+ 13:57:26 - Getting new log file entries
+ The stress test log file doesn't exist yet
+
+ 13:57:37 - checking CPU usage: 6.25%
+ ...current CPU frequency: ~4600 MHz (121.01%)
+
+ 13:57:38 - Getting new log file entries
+ The stress test log file doesn't exist yet
+
+ 13:57:48 - checking CPU usage: 6.25%
+ ...current CPU frequency: ~4639 MHz (122.06%)
+
+ 13:57:49 - Getting new log file entries
+ Getting new log entries starting at position 0 / Line 0
+ The new log file entries:
+ - [Line 1] [Fri Mar 25 13:57:41 2022]
+ - [Line 2] Self-test 720K passed!
+ New file position: 52 / Line 2
+
+ 13:57:59 - checking CPU usage: 6.24%
+ ...current CPU frequency: ~4613 MHz (121.38%)
+
+ 13:58:00 - Getting new log file entries
+ Getting new log entries starting at position 52 / Line 2
+ The new log file entries:
+ - [Line 3] Self-test 720K passed!
+ New file position: 76 / Line 3
+
+ 13:58:10 - checking CPU usage: 6.29%
+ ...current CPU frequency: ~4636 MHz (121.97%)
+
+ 13:58:11 - Getting new log file entries
+  No file size change for the log file
+
+ 13:58:21 - checking CPU usage: 6.25%
+ ...current CPU frequency: ~4639 MHz (122.05%)
+
+ 13:58:22 - Getting new log file entries
+ Getting new log entries starting at position 76 / Line 3
+ The new log file entries:
+ - [Line 4] Self-test 720K passed!
+ New file position: 100 / Line 4
+
+ 13:58:32 - checking CPU usage: 6.25%
+ ...current CPU frequency: ~4639 MHz (122.04%)
+
+ 13:58:33 - Getting new log file entries
+ Getting new log entries starting at position 100 / Line 4
+ The new log file entries:
+ - [Line 5] Self-test 720K passed!
+ New file position: 124 / Line 5
+
+ 13:58:43 - checking CPU usage: 6.24%
+ ...current CPU frequency: ~4649 MHz (122.3%)
+
+ 13:58:44 - Getting new log file entries
+ No file size change for the log file
+
+ 13:58:54 - checking CPU usage: 6.25%
+ ...current CPU frequency: ~4647 MHz (122.25%)
+
+ 13:58:55 - Getting new log file entries
+ Getting new log entries starting at position 124 / Line 5
+ The new log file entries:
+ - [Line 6] [Fri Mar 25 13:58:49 2022]
+ - [Line 7] Self-test 720K passed!
+ New file position: 176 / Line 7
+
+ 13:59:05 - checking CPU usage: 6.25%
+ ...current CPU frequency: ~4675 MHz (123%)
+
+ 13:59:06 - Getting new log file entries
+ Getting new log entries starting at position 176 / Line 7
+ The new log file entries:
+ - [Line 8] Self-test 720K passed!
+ New file position: 200 / Line 8
+
+ 13:59:16 - checking CPU usage: 6.25%
+ ...current CPU frequency: ~4640 MHz (122.06%)
+
+ 13:59:17 - Getting new log file entries
+ No file size change for the log file
+
+ 13:59:25 - checking CPU usage: 6.25%
+ ...current CPU frequency: ~4637 MHz (122.01%)
+ One last CPU usage check before finishing this core
+ 13:59:26 - checking CPU usage: 6.25%
13:59:27 - Completed the test on Core 7 (CPU 14)


----------



## ManniX-ITA

cancel007 said:


> So +10 co on core7 passes the 2 min in CoreCycler (I have not tried 10m yet). I did it a few times to make sure it was not a one time thing (I went back to +5 but nothing). The following log is what I see, and you can see it is able to set a speed to the core so it can test it vs the other log where it cannot even set a speed.


That's not setting the speed, it's reading it.
For Core 7 it doesn't detect it because it's crashing immediately.
If you see the first step is detect the load and for Core 7 it fails there so it doesn't go to the next step checking for the frequency.


----------



## ArchStanton

ManniX-ITA said:


> Yes but considering it's boost clock +0


Aye, and I keep thinking in terms of my own 5950X instead of his actual CPU, which is not trying to hit that 5050MHz target I am accustomed to. It has been a big flaw in my thinking regarding his circumstances.


----------



## cancel007

ManniX-ITA said:


> That's not setting the speed, it's reading it.
> For Core 7 it doesn't detect it because it's crashing immediately.
> If you see the first step is detect the load and for Core 7 it fails there so it doesn't go to the next step checking for the frequency.


Ah I see. Oh well 😊 thanks again!

+10 on core7 did work. And using BoostTester it still boosted to 4850 effective clock at first try. I did +100mhz boost just to try and +10 on core 7 did not fail either. I think I'm going to try and get a curve with +100mhz and see how it is, then try +200mhz. I guess it'll have to be a positive number. Thank you again 😊


----------



## PJVol

ManniX-ITA said:


> Zen is a monolithic design with NB and SB inside AFAIK.
> What is your understanding of NB?


I mean there's no such entities in a Zen architecture called NB or SB, i.e. they stopped using term NB, instead there are devices 18h pci bus 0 (and up) for each node for accessing its configuration space.
In family 15h cpus, NB was refered to as packet routing block + L3 cache + registers.

Thats why it seems confusing to me. They didn't use "nb" anywhere in the block schemes or articles, but still referred to by mb vendors in bios here and there.


----------



## ManniX-ITA

PJVol said:


> I mean there's no such entities in a Zen architecture called NB or SB.
> In family 15h cpus, NB was refered to as packet routing block + L3 cache + registers.


NB and SB are pretty generic terms in computing.
They are used also in many other concepts, like database or network architectures.
It really depends on how the term is being used.

In CPUs are used for the die parts handling I/O, NB for memory I/O and SB for peripherals I/O.
A lot of time ago those functions were handled by the board chipset which only had one single bus connection to the CPU.
AMD can decide to not use the term or use something different like IOD or SOC.
But the soup is always the same 

Zen CPUs have them in the die so it's more a classic NB/SB design.
In Zen2+, those which are MCM, they are on different dies interconnected via the IF.
Zen has the UMC as NB and IO Hub Controller as SB while on Zen2+ MCM they are both packed in the cIOD.

This is the description of Zen from Wikichip (Zen - Microarchitectures - AMD - WikiChip):

_All Zen-based mainstream consumer microprocessors utilizes AMD's Socket AM4, a unified socket infrastructure. All those processors are a complete system on a chip integrating the northbridge (memory controller) and the southbridge including 16 PCIe lanes for the GPU, 4 PCIe lanes for the NVMe/SATA controllers as well as USB 3.0. The chipset, however, extends the processor with a number of additional connections beyond that offered by the SoC._


----------



## cancel007

@ManniX-ITA 

So I was playing with the curve the whole day pretty much, at +100mhz. Managed to get a 10m CC pass. Current curve: -15|-5|-5|-5|-15|-5|-15|10.

I am getting mediocre scores but it is what it is. In R20 I cannot pass the 6000 mark, im hovering around 5900. In R23 I'm at 15221. In Timespy I am at 11300. My effective cores are close to the 4950 mhz mark except core 7 which is really far behind. At this point, do you think it would be better to go back to +0 or even try +50? Not sure if I would get better performance then since I will be able to get better numbers with the curve.

Below is a screenshot of the effective cores after I ran the BoostTester.



Spoiler: Effective Cores HWinfo64


----------



## ManniX-ITA

cancel007 said:


> At this point, do you think it would be better to go back to +0 or even try +50? Not sure if I would get better performance then since I will be able to get better numbers with the curve.


I'm not sure you can get lower counts or better performances.
The +10 is really a big let down.
You can try with +50 but I think you wouldn't be able to gain much.
At +0 not sure makes sense since Core 7 can reach 4900 MHz.

What you can try as last resort is to play with Scalar and offset.
Test with Scalar 10x, it will add a bit of voltage to the VIDs.
You may be able to get Core 7 between 2 to 4 counts down.
Try always with +100.

Then go to Overclocking menu and change the CPU vCORE Voltage from Auto to Offset.
Set a positive offset, add one bin at a time and test, eg. 0.0125 mV then 0.0250 mV etc.
After a certain positive offset the benchmarks scores will tank down, depends on sample.
Since you have -15 as the lowest count you could be able to get -30 where it was -15.
And Core 7 could end up in the 0 to -5 range.

If it succeed, this will improve the Core 7 performances and greatly improve all-core.


----------



## sp00n82

Depending on the BIOS version, setting a vCore offset might not work together with PBO on MSI boards. I don't know if or when they fixed it, but it didn't work for my MSI Tomahawk x570 when I started writing CoreCycler. It would just be stuck at base clock then.


----------



## cancel007

ManniX-ITA said:


> Test with Scalar 10x, it will add a bit of voltage to the VIDs.


I've read mixed things about scalar and degradation. I've seen people use auto or 1-2x max. Will 10x degrade the cpu faster?

Should I also adjust the power limits anyhow? 



ManniX-ITA said:


> Then go to Overclocking menu and change the CPU vCORE Voltage from Auto to Offset.
> Set a positive offset, add one bin at a time and test, eg. 0.0125 mV then 0.0250 mV etc.
> After a certain positive offset the benchmarks scores will tank down, depends on sample.
> Since you have -15 as the lowest count you could be able to get -30 where it was -15.
> And Core 7 could end up in the 0 to -5 range


I will give the scalar and vcore offset a try today! (assuming vcore offset works as sp00n82 said it might not, but will still try it).


----------



## PJVol

ManniX-ITA said:


> NB and SB are pretty generic terms in computing


Yes, hence the reason for confusing volatge labels, and I have to admit, the term "NB" itself became too generous, since NB functionality is fully integrated on-chip.



ManniX-ITA said:


> Zen CPUs have them in the die so it's more a classic NB/SB design.
> In Zen2+, those which are MCM, they are on different dies interconnected via the IF.
> Zen has the UMC as NB and IO Hub Controller as SB while on Zen2+ MCM they are both packed in the cIOD.


I think this is not quite correct, just like the wiki's interpretation is too loose. I meant, how Zen differes from Zen2 and Zen3 in this regard architecture wise, aside from the on-package IF routing? All Zen CPU have more or less the same functional blocks. SB now is FCH, NB no longer exist in its original purpose and designation.
Therefore its not quite clear, how B450

My thoughts on it, following the AMD's own use of "NB" in docs, SDF plane seem to fit this term best. According to T.Burd in “Zeppelin”: An SoC for Multichip Architectures, IEEE JOURNAL OF SOLID-STATE CIRCUITS, 2018


> scalable data fabric (SDF) provides coherent data
> transport between cores, memory controllers, and IO, and can
> do so within the same die, across dies within the same pack-
> age, or between packages in a two-socket system.


Of course, you may add memory controller, i.e.the whole IO die, including the FCH (former SB)


----------



## ManniX-ITA

cancel007 said:


> I've read mixed things about scalar and degradation. I've seen people use auto or 1-2x max. Will 10x degrade the cpu faster?


Unlikely, unless we are talking over dozens of years, the added voltage is minimal.



cancel007 said:


> Should I also adjust the power limits anyhow?


Yes, set something better than stock like 160/100/140.
See how it goes.



cancel007 said:


> (assuming vcore offset works as sp00n82 said it might not, but will still try it)


Really depends on the board, try it.
On my Unify-X works properly.


----------



## ManniX-ITA

PJVol said:


> Yes, hence the reason for confusing volatge labels, and I have to admit, the term "NB" itself became too generous, since NB functionality is fully integrated on-chip.


Yes but still, either integrated in the monolithic die or in the cIOD when MCM it does have its own separate voltage feeding pins.



PJVol said:


> I think this is not quite correct, just like the wiki's interpretation is too loose. I meant, how Zen differes from Zen2 and Zen3 in this regard architecture wise, aside from the on-package IF routing? All Zen CPU have more or less the same functional blocks. SB now is FCH, NB no longer exist in its original purpose.


I'm not sure, from the architecture side more or less the same for Zen and Zen2+ monolithic like the APU.
The NB is the UMC part, either in the die or in the cIOD.
It's a bit confusing but the principles are still there.

SDF or Infinity Fabric is an interconnect bus/interposer.
It doesn't provide directly I/O access to external resources like the UMC or FCH.
More an intermediate layer.
I don't think it's a candidate for an NB or SB role.
eg. "_transport between cores, memory controllers, and IO"_ 
Means between them not from the memory to the DIMMs or from the SoC to the USB peripherals.
NB/SB in the architecture are bridges going out of the core domain, the fabric is what connects the elements in the core domain.


----------



## cancel007

ManniX-ITA said:


> Really depends on the board, try it.
> On my Unify-X works properly


I will today thank you 😊

What's your AGESA bios version by any chance ?


----------



## ManniX-ITA

cancel007 said:


> What's your AGESA bios version by any chance ?


Right now 1.2.0.1 but since I got back the 5950X and it's a B2 will probably witch to 1.2.0.3 tomorrow


----------



## ArchStanton

ManniX-ITA said:


> since I got back the 5950X


looking forward to your updates with this latest sample


----------



## cancel007

ManniX-ITA said:


> Right now 1.2.0.1 but since I got back the 5950X and it's a B2 will probably witch to 1.2.0.3 tomorrow


Got back meaning you RMA'd it? How come?


----------



## ManniX-ITA

cancel007 said:


> Got back meaning you RMA'd it? How come?


Yes I had a problem with my decent B0 which was crashing/slow with SVM enabled.
They sent me a B2 that was poor and with a core failing CC at stock.
At some point started BSOD and corrupted my Windows install.
Now I got another B2... let's see.


----------



## cancel007

ManniX-ITA said:


> They sent me a B2 that was poor and with a core failing CC at stock.


Mine probably will fail stock lol seeing how it fails at +0 CO. Don't even want to try it.

Good luck with the chip!


----------



## PJVol

ManniX-ITA said:


> The NB is the UMC part, either in the die or in the cIOD.
> It's a bit confusing but the principles are still there.
> 
> SDF or Infinity Fabric is an interconnect bus/interposer.
> It doesn't provide directly I/O access to external resources like the UMC or FCH.
> More an intermediate layer.


It does, via NBIO, and to the UMC directly (attached zen2 diagram from PPR)
I admit it's more of a conceptual term nowadays, but still I'd go with how AMD themselves defined NВ:


> _BKDG for AMD Family 15h Models 00h-0Fh Processors _
> Each node includes a single *northbridge *that provides the _interface_ to the local core(s), the _interface_ to system
> memory, the _interface_ to other processors, and the _interface_ to system IO devices.
> ...
> _The NB of each node is responsible for routing transactions sourced from cores and links to the appropriate
> core, cache, DRAM, or link._





> _PPR for AMD Family 17h _
> Scalable Data Fabric. This provides the data path that connects the compute complexes, the I/O interfaces,
> and the memory interfaces *to each other*.





ManniX-ITA said:


> ... the fabric is what connects the elements in the core domain.


Sorry, are you sure about that?


----------



## ManniX-ITA

PJVol said:


> I admit it's more of a conceptual term nowadays, but still I'd go with how AMD themselves defined NВ:


This is a description of the computing core:

_The NB of each node is responsible for routing transactions *sourced from cores* and links to the appropriate
core, cache, DRAM, or link._ 

They have their own NB which is I guess that big SerDES part connecting to the IF/SDF.
For the SoC NB it's different, the NB side is the memory bus.

_Scalable Data Fabric. This provides the data path that connects the compute complexes, the I/O interfaces,
and the memory interfaces *to each other*._

Exactly, it connects the internal component to each other.
NB and SB interfaces are by definition bridges to the outside of the core domain.
SDF/IF it's an internal transport.
eg. On an SQL cluster the NB is toward an upstream SQL server and the SB toward the downstream.
They must be interfaces connected to the outside.
Considering SDF an NB would be like considering the cluster interconnect interfaces like an NB.



PJVol said:


> Sorry, are you sure about that?


This block diagram doesn't look like a good candidate 
It's just showing the SDF/SCF inter connections.

What is NB or SB is defined by its connection to the outside.
On the old Intel CPUs they had their own specific die space, here they are more scattered thanks to the flexibility of the fabric.
But still on an MCM I think this stuff is all packed in the cIOD.


----------



## PJVol

ManniX-ITA said:


> This is a description of the computing core:


I believe this statement may have misled you. Idk what you mean under "computing core" (didn't find it in AMD docs), but it was literally the description of NB, one for each node (attached pics from Fam.15h below).
With Zen architecture (as I see it)

L3 moved to a CCX
transaction routing is done in SDF
the rest of per node functionality moved to NBIO
MCT & DCT became UMC and is not part of NB anymore.
SB is System Controller HUB (SCH)
Node is 2CCX(or CCD) + IF + IO(and other uncore), i.e. fully functioning processor.











ManniX-ITA said:


> Exactly, it connects the internal component to each other.
> NB and SB interfaces are by definition bridges to the outside of the core domain.
> SDF/IF it's an internal transport.


Internal relative to what? And I still can't understand what is core domain? If you mean CCX/CCD, how SDF could be internal then?
SDF literally means "scalable", so it's designed with scaling in mind within big compute clusters. And btw, CCM (that big SerDes) could well be considered as part of not-existing-anymore NB


----------



## ManniX-ITA

PJVol said:


> I believe this statement may have misled you. Idk what you mean under "computing core" (didn't find it in AMD docs), but it was literally the description of NB, one for each node (attached pics from Fam.15h below).


I mean the CPU Core Complex as it's named in that Fabric block diagram.
From my understanding SCH is only a part of the SB.
Why you consider the IO HUB as "NBIO"?
It's definitely not a NorthBridge but a SouthBridge part. USB, Eth, Audio, are all SB interfaces.
The UMC is the only NB interface I see there.



PJVol said:


> Node is 2CCX(or CCD) + IF + IO(and other uncore), i.e. fully functioning processor.


Node is the core complex, it does have IF interfaces (SerDES) toward IO/MEM but it doesn't "include" them.
It's not a fully functioning processor, it's a "computing core".
The processor is defined as a package that contains one or more nodes.
That description seems to be coming from some old pre-Epyc arch, Opteron?
The CCD in Zen doesn't have a memory interface and it's not DDR3.

From what you said I understand you consider that NB as the NBIO in the block diagram but maybe I got it wrong.
The concept is the same, that NB is inside the CCD/node and provides I/O toward the outside of it.
It does make communicate the compute units with the L3 which is inside the CPU Core Complex, not outside.


----------



## ManniX-ITA

I think it's easier with this Zeppelin die shot to explain what I mean.
The 1,2 are the NB interfaces (GPU, memory) the 3,4,5 the SB interfaces.


----------



## PJVol

ManniX-ITA said:


> From my understanding SCH is only a part of the SB.
> Why you consider the IO HUB as "NBIO"?
> It's definitely not a NorthBridge but a SouthBridge part. USB, Eth, Audio, are all SB interfaces.


Guilty, Your Honor, it's not me 

















(PPR for AMD Family 17h Models 01h,08h B2)



ManniX-ITA said:


> Node is the core complex, it does have IF interfaces (SerDES) toward IO/MEM but it doesn't "include" them.
> It's not a fully functioning processor, it's a "computing core".


No.


ManniX-ITA said:


> The concept is the same, that NB is inside the CCD/node and provides I/O toward the outside of it.
> It does make communicate the compute units with the L3 which is inside the CPU Core Complex, not outside.


...and no.


ManniX-ITA said:


> I think it's easier with this Zeppelin die shot to explain what I mean.
> The 1,2 are the NB interfaces (GPU, memory) the 3,4,5 the SB interfaces.


Within the old concept it's definitely true. But you have to add to it routing functionality, which was part of NB on an equal basis with interfaces.

PS: regarding node being the fully functioning processor, I may have exagerrated a bit, and technically it isn't, but "vitrually" if it were possible to cut IOD into four working pieces, it is.


----------



## ManniX-ITA

PJVol said:


> Guilty, Your Honor, it's not me


I see now, this is another AMD BS 
Doesn't make sense at all, they made their own "special" definitions of NB and SB.
Guess someone was offended by the Intel's heritage of this topic...

Why you say the Node in that definition (Opteron?) is not the core complex?
I don't think that NB definition is the same as they later defined the NBIO, there's no IOHUB, SYSHUB or PCIe.

Anyway the original point was why they were using NB instead of SOC.
I think cause the VDDCR_SOC was used to power the NB parts as in the Zeppelin die.
Later they moved all the NB/SB stuff in the IOD and just renamed it as SOC Voltage.
Maybe cause it's also powering the interposer, more "generic" name?
But I'm starting to think what they called "NB" maybe was already more an NB/SB thing...


----------



## snorlaxgangs

I have a noob questions. Most of my C0s passed prime large FFT SSE test but eventually failed when change mode to AVX/AVX2 or y-cruncher kagari. Why not go to the extreme test from the beginning instead? And are COs stable SMT off is also stable when SMT on?


----------



## ArchStanton

snorlaxgangs said:


> I have a noob questions.


I am also a newb, but I think the eventual answer you will arrive at is something like "If you are overclocking, you MUST test EVERY possible configuration if you want to be 100% sure of your settings". However, personally I like to start testing CO counts with 720-720 SSE mode for 5 minutes per core in Corecycler with SMT on. This seems to do a pretty good job of roughing in the settings. Later, I will expand the fft range to "heavy" or even "all" in all three modes (SSE/AVX/AVX2). So yeah, as far as a newb like me has discovered, there is no "quick" way to confidence in stability when using PBO2/CO. 🤷‍♂️

P.S. Why does fft size 720k more quickly expose instabilities compared to other sizes of fft? I have absolutely no idea.


----------



## snorlaxgangs

ArchStanton said:


> I like to start testing CO counts with 720-720 SSE mode for 5 minutes per core in Corecycler with SMT on. T


Do you test with 1 thread or 2?


----------



## ArchStanton

snorlaxgangs said:


> Do you test with 1 thread or 2?


I leave SMT on in BIOS, but I generally test with 1 thread (per the settings in the config file for CoreCycler itself), as I think many instabilities are related to a core switching from idle to peak boost, and that peak boost is higher if only using 1 thread (however am not 100% certain this is accurate, this is only my impression). Again, at the end of the day, we can only gain confidence in our settings if we test with ALL possible permutations of the parameters available to us. 🤷‍♂️


----------



## ManniX-ITA

snorlaxgangs said:


> Do you test with 1 thread or 2?


Better 1 thread with 2 the boost clock will go down


----------



## snorlaxgangs

@ArchStanton I'm gonna to find the baseline first then test them all one by one then  I always thought that if it passed all the extreme stress tests then the light ones should be considered done.



ManniX-ITA said:


> Better 1 thread with 2 the boost clock will go down


So if it's passed then should I retest with 2 threads or no need to do it? ty


----------



## ManniX-ITA

snorlaxgangs said:


> So if it's passed then should I retest with 2 threads or no need to do it? ty


No need to re-test with 2 cores


----------



## des2k...

looks like heaven bench is the most reliable at pushing peak freq 4975-5100 since those can't be tested

assuming you shouldn't get bsod whea when your games hit those peak freq if this passes 8h loop overnight











*edit nop... 5100 freq doesn't like CO with games, dropped down to 5050 to get Destiny to work

I guess CO is crazy unstable on the top freq


----------



## paih85

Hi @PJVol,

PBO2 Tuner can set auto on startup? i need that for my 5800x3d due tu AMD disable/hide that features on bios. CO working good but need to reapply every reboot. thanks


----------



## PJVol

paih85 said:


> PBO2 Tuner can set auto on startup?


IMHO applying settings in bios is hardly a good practice for any 3rd party soft. But you may try the latest Ryzen Master build (2.9.0), it has CO tuning functionality now.


----------



## paih85

PJVol said:


> IMHO applying settings in bios is hardly a good practice for any 3rd party soft. But you may try the latest Ryzen Master build (2.9.0), it has CO tuning functionality now.


ok will try.


----------



## paih85

paih85 said:


> ok will try.


not working. CO setting not exist for 5800x3d. only ram oc part.


----------



## sp00n82

AMD specifically disabled overclocking features for the 5800X3D due to the new technology (they may or may not enable it in the future for chips with a 3D cache).
Some boards with an external clock generator allow for BCLK overclocking, but that's about it for the 5800X3D.


----------



## paih85

sp00n82 said:


> AMD specifically disabled overclocking features for the 5800X3D due to the new technology (they may or may not enable it in the future for chips with a 3D cache).
> Some boards with an external clock generator allow for BCLK overclocking, but that's about it for the 5800X3D.


yup. for now this the only tool working for CO tuning. -30 all core fully stable.


----------



## Dijati

paih85 said:


> yup. for now this the only tool working for CO tuning. -30 all core fully stable.
> 
> View attachment 2557924


Same for me. -30 on all cores stable and -13 to -15 degrees…. Just an Autostart feature would be great 😊


----------



## Yuriewitsch

IDK for sure, but what about creating a Basic Task to start program at start up in Task Scheduler?
Or it don't remembers those CO values and you have to reapply at every start?


----------



## Dijati

Yuriewitsch said:


> IDK for sure, but what about creating a Basic Task to start program at start up in Task Scheduler?
> Or it don't remembers those CO values and you have to reapply at every start?


Thats what i was thinking too. But you need to manually apply the values after the reboot


----------



## PJVol

Yuriewitsch said:


> Or it don't remembers those CO values and you have to reapply at every start?


Initially I wasn't aware of the Read PSM command code, and tuner just stored the last CO input in application settings file to let the user reapply it on next start.
Later when I implemented direct read of CO values from PSMs, it was no longer needed.

Another reason to aviod "autoloading saved CO" is that for proper functioning offsets should be applied before BTC (boot time calibration), otherwise you have to make sure the ambient temp on every boot is not much different from what it was when the final curve was defined.
Although, the extent to which this delta *t**°* affects stability may vary significantly due to a bunch of other factors.


----------



## Dijati

PJVol said:


> Initially, since I wasn't aware of the Read PSM command code, tuner just stored the last CO input in app user settings.
> Later when I implemented direct read CO values from PSMs, it was no longer needed.


Can you change that again or make it possible that it stores settings after reboot?


----------



## PJVol

Dijati said:


> Can you change that again or make it possible that it stores settings after reboot?


I'll think about it. The thing is to get it back without messing with the initial CO readout from the hardware.


----------



## Blameless

PJVol said:


> IMHO applying settings in bios is hardly a good practice for any 3rd party soft. But you may try the latest Ryzen Master build (2.9.0), it has CO tuning functionality now.


I don't want software applying persistent firmware changes either, but some form of automation for PBO2 Tuner would be appreciated.

I'd be content with a scheduled task that simply executed a command that told the app to apply a COs at user log in. If I knew what to put in the config files and/or how to execute the app without the GUI, that's all I'd need.


----------



## Dijati

Blameless said:


> I don't want software applying persistent firmware changes either, but some form of automation for PBO2 Tuner would be appreciated.
> 
> I'd be content with a scheduled task that simply executed a command that told the app to apply a COs at user log in. If I knew what to put in the config files and/or how to execute the app without the GUI, that's all I'd need.


Yeah would be great


----------



## yzonker

Blameless said:


> I don't want software applying persistent firmware changes either, but some form of automation for PBO2 Tuner would be appreciated.
> 
> I'd be content with a scheduled task that simply executed a command that told the app to apply a COs at user log in. If I knew what to put in the config files and/or how to execute the app without the GUI, that's all I'd need.


I don't fully understand everything PJVol is saying, but adding a command line call would be all that is necessary, unless that just doesn't work for some reason. You can paste the string it echo's out (-30|-30|-30|-30|-30|-30|-30|-30) in to the config file and that works for a while to re-populate the input boxes, but eventually ends up as an error on starting the app. Seemed like from changing bios settings, but I haven't tested enough to verify.


----------



## BHS1975

paih85 said:


> yup. for now this the only tool working for CO tuning. -30 all core fully stable.
> 
> View attachment 2557924


Do you any negative offset in bios as well?


----------



## Dijati

BHS1975 said:


> Do you any negative offset in bios as well?


i have also -30 and no negative offset cause temps are super cold.


----------



## Blameless

yzonker said:


> I don't fully understand everything PJVol is saying, but adding a command line call would be all that is necessary, unless that just doesn't work for some reason.


I don't know if it works or not because I don't know what command to call.

I'd expect to be able to use rundll32 ZenStates-Core.dll (somethingsomethingblahblahblah), but I'm not a coder and I haven't read the documentation on any of these underlying apps.

_Edit:_ The rest of the app could be calculating the curves that map to the CO values, but even then, starting the executable, automatically populating the boxes, automatically applying the vaules, then closing the app should do exactly the same thing it does when I make a few clicks and ctrl+v a few times.



yzonker said:


> You can paste the string it echo's out (-30|-30|-30|-30|-30|-30|-30|-30) in to the config file and that works for a while to re-populate the input boxes


Can you show me what this looks like?

I tried putting that output in app.config and PBO2 tuner.exe.config and it didn't do anything.


----------



## Dijati

Blameless said:


> I don't know if it works or not because I don't know what command to call.
> 
> I'd expect to be able to use rundll32 ZenStates-Core.dll (somethingsomethingblahblahblah), but I'm not a coder and I haven't read the documentation on any of these underlying apps.
> 
> 
> 
> Can you show me what this looks like?
> 
> I tried putting that output in app.config and PBO2 tuner.exe.config and it didn't do anything.


Yeah. Whats the cmd??? Then we could create a batch file at startup with delay to execute the cmd in the task sheduler


----------



## yzonker

Blameless said:


> I don't know if it works or not because I don't know what command to call.
> 
> I'd expect to be able to use rundll32 ZenStates-Core.dll (somethingsomethingblahblahblah), but I'm not a coder and I haven't read the documentation on any of these underlying apps.
> 
> _Edit:_ The rest of the app could be calculating the curves that map to the CO values, but even then, starting the executable, automatically populating the boxes, automatically applying the vaules, then closing the app should do exactly the same thing it does when I make a few clicks and ctrl+v a few times.
> 
> 
> 
> Can you show me what this looks like?
> 
> I tried putting that output in app.config and PBO2 tuner.exe.config and it didn't do anything.


in the "PBO2 tuner.exe.config" file. But like I said, this doesn't work permanently. 

Edit: I just tried it and it didn't survive a reboot. Error message when I run it again. I was thinking it did survive reboots yesterday, but I was thrashing on this quite a while so maybe I forgot.



Code:


<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
    <sectionGroup name="userSettings" type="System.Configuration.UserSettingsGroup, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
        <section name="PBO2Tuner.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowExeDefinition="MachineToLocalUser" requirePermission="false" />
    </sectionGroup>
</configSections>
<startup><supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.8"/></startup>
    <userSettings>
        <PBO2Tuner.Properties.Settings>
            <setting name="curveData" serializeAs="String">
                <value -20|-20|-20|-20|-20|-20|-20|-20/>
            </setting>
        </PBO2Tuner.Properties.Settings>
    </userSettings>
</configuration>


----------



## paih85

BHS1975 said:


> Do you any negative offset in bios as well?


nope. only negative CO set by PJVol tool.


----------



## PJVol

Blameless said:


> I don't want software applying persistent firmware changes either, but some form of automation for PBO2 Tuner would be appreciated.


@paih85 @Dijati et al )
Can you try this binary:
(it should accept CO values in command line. This is test version, so the main application window may appear before exit)
Debug-CLI.7z


Code:


'path-to-a-binary\PBO2 tuner.exe' 1 2 3 4 5 6 7 8 (for the 5800's)

Args number should be equal to the active cores count (i.e. 8 in case of 5800x3d)


----------



## Dijati

PJVol said:


> You (and anyone else with the 5800x3d) can try this binary.
> It should accept CO values in command line. This is test version, so the main application window may appear before exit.
> Debug-CLI.7z
> 
> 
> Code:
> 
> 
> 'path-to-a-binary\PBO2 tuner.exe' 1 2 3 4 5 6 7 8 (for the 5800's)
> 
> Args number should be equal to the active cores count (i.e. 8 in case of 5800x3d)


Can you explain a bit further? Just use the new PBOTuner.exe file or do some things via Windows CMD?


----------



## PJVol

@Dijati
You can try to add binary at the windows startup with the CO values passed as arguments.

But *before* that, you may check if values are applied if entered in a command line correctly (see above post) - it should apply values and then close itself.
When starting app from CMD or PS, if arguments are not passed it will run as the usual GUI app. If arguments are passed but invalid - it just closes.


----------



## Dijati

PJVol said:


> @Dijati
> Try to add binary at the windows startup with the CO values passed as arguments.


I honestly dont understand


----------



## sp00n82

Dijati said:


> I honestly dont understand


Add a new shortcut to your Startup (Autostart) folder to the .exe file he posted, and add the CO values as the arguments.


Alternatively create a batch file (.bat) with the relevant command he posted and add that as a shortcut to the Startup folder. The advantage is that you can manually test the batch file beforehand to check if it works correctly.


----------



## Blameless

PJVol said:


> @paih85 @Dijati et al )
> Can you try this binary:
> (it should accept CO values in command line. This is test version, so the main application window may appear before exit)
> Debug-CLI.7z
> 
> 
> Code:
> 
> 
> 'path-to-a-binary\PBO2 tuner.exe' 1 2 3 4 5 6 7 8 (for the 5800's)
> 
> Args number should be equal to the active cores count (i.e. 8 in case of 5800x3d)


This works. Thanks.


----------



## Blameless

sp00n82 said:


> Add a new shortcut to your Startup (Autostart) folder to the .exe file he posted, and add the CO values as the arguments.
> 
> 
> Alternatively create a batch file (.bat) with the relevant command he posted and add that as a shortcut to the Startup folder. The advantage is that you can manually test the batch file beforehand to check if it works correctly.


I like scheduled tasks:









Note, never run random applications from strangers as SYSTEM with highest privileges, not without taking a good look at what it does first and scanning it for malware.


----------



## sdmf74

Anybody had much sucess using this tool on Intel CPU's? Just not sure if I wanna spend that much more time tuning my 11900k as I already have spent many hours tuning & testing & have a stable 54x6 53x7 52x8 OC. Not sure I would be able to squeeze much more out of it but it would be great to know which cores are the most powerful besides Intel telling me that its Cores 4 & 5. I havent yet been able to find stability with 1 core at 55x on custom watercooling (tried both 4 & 5) but maybe this tool would find a different core that can.


----------



## nikobobich

sp00n82 said:


> Over the last couple of days resp. weeks I've been working with the Curve Optimizer for Ryzen processors a bit more, but I hadn't found a good way to test the settings for stability. CineBench single threaded almost always worked fine, and getting Prime95 stable with load on all cores was also relatively quick. Waiting for crashes while idling or while playing a game wasn't so appealing either, and on Reddit someone even suggested using the Windows Repair as some kind of stability test... that didn't seem like a good idea to me.
> 
> So this sparked the idea for this tool. It's a PowerShell script which starts up an instance of Prime95 with only a single worker thread, stressing only a single physical CPU core. And it cycles through all the available cores after an adjustable time, so that you can run this tool e.g. over night, and then the next day you can check which cores have run fine and which ones have thrown an error in Prime95.
> 
> By now it looks polished enough for a release, however so far I'm the only one who has tested it, so additional reports are welcome.
> 
> You can find it here:
> 
> 
> 
> 
> 
> 
> 
> 
> Releases · sp00n/corecycler
> 
> 
> Stability test script for PBO & Curve Optimizer stability testing on AMD Ryzen processors - sp00n/corecycler
> 
> 
> 
> 
> github.com
> 
> 
> 
> 
> 
> 
> To execute it, simply double click the "Run CoreCycler.bat".
> And be sure to read the included readme.txt as well as the config.ini (resp. config.default.ini) to get a grasp of what settings you can change.
> (Note: the config.ini will be auto-generated on the first start from the config.default.ini)
> 
> 
> Screenshots of the script in action:
> View attachment 2481473
> View attachment 2481474
> 
> 
> And here's an example for a summary, this is how the testing went for me during development. As you can see, this still takes quite some time to get stable. (And no, the summary will not be generated automatically, you'll still have to do this yourself ):
> View attachment 2481475
> 
> 
> 
> Here's an excerpt from the readme.txt
> 
> This little script will run Prime95 with only one worker thread and sets the affinity of the Prime95 process alternating to each physical core, cycling through all of them. This way you can test the stability of your Curve Optimizer setting for each core individually, much more thoroughly than e.g. with Cinebench or the Windows Repair, and much easier than manually setting the affinity of the process via the Task Manager.
> It will still need a lot of time though. If for example you're after a 12h "prime-stable" setup which is common for regular overvlocks, you'd need to run this script for 12x12 = 144 hours on a 5900X with 12 physical cores, because each core is tested individually, and so each core also needs to complete this 12 hour test individually. Respectively, on a 5600X with its 6 physical cores this would be "only" 6x12 = 72 hours.
> Unfortunately such an all-core stress test with Prime95 is not effective for testing Curve Optimizer settings, because the cores cannot boost as high if all of them are stres tested, and therefore you won't be able to detect instabilities that occur at a higher clock speed. For example, with my CPU I was able to run a Prime95 all-core stress test for 24 hours with an additional Boost Override of +75 MHz and a Curve Optimizer setting of -30 on all cores. However, when using this script, and with +0 MHz Boost Override, I needed to go down to -9 on one core to have it run stable (on the other hand, another core was still happy with a -30 setting even in this case).
> 
> When you start the script for the first time, it will copy the included config.default.ini to config.ini, in which you then can change various settings, e.g. which mode Prime95 should run in (SSE, AVX, AVX2, CUSTOM, where SSE causes the highest boost clock, because it's the lightest load on the processor of all the settings), how long an individual core should be stressed for before it cycles to the next one, if certain cores should be ignored, etc. For each setting there's also a description in the config.ini file.
> 
> As a starting point you could set the Curve Optimizer to e.g. -15 or -20 for each core and then wait and see which core runs through fine and which throws an error. Then you could increase the setting for those that have thrown an error by e.g. 2 or 3 points (e.g. from -15 to -13) and decrease those that were fine by 2 or 3 further into the negative (-15 to -17). Once you've crossed a certain point however there is no way around modifying the value by a single point up/down and letting the script run for a long time to find the very last instabilities.
> 
> By the way, it is intended that only one thread is stressed for each core if Hyperthreading / SMT is enabled, as the boost clock is higher this way, compared to if both (virtual) threads would be stressed. However, there is a setting in the config.ini to enable two threads as well.



On your chart what are the numbers under the cores that range from lik 140 to 180? are the the cruncher numbers?


----------



## ManniX-ITA

sdmf74 said:


> Anybody had much sucess using this tool on Intel CPU's? Just not sure if I wanna spend that much more time tuning my 11900k as I already have spent many hours tuning & testing & have a stable 54x6 53x7 52x8 OC. Not sure I would be able to squeeze much more out of it but it would be great to know which cores are the most powerful besides Intel telling me that its Cores 4 & 5. I havent yet been able to find stability with 1 core at 55x on custom watercooling (tried both 4 & 5) but maybe this tool would find a different core that can.


I didn't see much use of it on Intel CPUs but the tool is CPU agnostic.
It will not help you find which cores are the most powerful, it's not a benchmark.
What it does is helping you to run stress testing in a highly customizable way to validate the cores are working properly.
Which is more likely to end finding out what you considered a stable OC not being stable.


----------



## sp00n82

nikobobich said:


> On your chart what are the numbers under the cores that range from lik 140 to 180? are the the cruncher numbers?


These are the values provided by CoreTunerX, which is included in the /tools folder. There's also a .txt file explaining what it does.


----------



## nikobobich

sp00n82 said:


> These are the values provided by CoreTunerX, which is included in the /tools folder. There's also a .txt file explaining what it does.


I have one more question are you running it with you EDC, TDC and PPT already dialed in? or does that even matter because I've already found 2 errors on core 1 and 7 which im not surprised they are my 2 best cores and I had to lower the negative already on them. I can set the limits to motherboard if thats best? Then dial in the values later? Im not sure how that part works? Should I set the power (edc ppt etc to default) or just leave them dialed in for what its clocking at already,?


thanks for this program it really does work


----------



## nikobobich

nikobobich said:


> I have one more question are u running it with ur edc tdc and ppt already dialed in? or does that even matter because I've already found 2 errors on core 1 and 7 which im not surprised they are my 2 best cores and I had to lower the negative already on them. Should I set the power (edc ppt etc to default) or just leave them dialed in for what its clocking at already,? thanks for this program it really does work


im running 6 minute cycles right now im going to move them to 30 min cycles when I sleep and I figure ill get WHEA errors at times and have to scale down my cores anyways


----------



## nikobobich

nikobobich said:


> im running 6 minute cycles right now im going to move them to 30 min cycles when I sleep and I figure ill get WHEA errors at times and have to scale down my cores anyways


AMD says u should scale the cores in 2s or I think -3 at a time until prime stable. I just want to do this correct so I can leave it set up and never have to worry about it again. I know doing it this way core by core is most optimal and pays off the most


----------



## Luggage

nikobobich said:


> I have one more question are you running it with you EDC, TDC and PPT already dialed in? or does that even matter because I've already found 2 errors on core 1 and 7 which im not surprised they are my 2 best cores and I had to lower the negative already on them. I can set the limits to motherboard if thats best? Then dial in the values later? Im not sure how that part works? Should I set the power (edc ppt etc to default) or just leave them dialed in for what its clocking at already,?
> 
> 
> thanks for this program it really does work


MB limits probably too hot and will limit boost.
PBO limits too low will also throttle boost.
Tune limits with regard to cooling and workload.


----------



## nikobobich

Luggage said:


> MB limits probably too hot and will limit boost.
> PBO limits too low will also throttle boost.
> Tune limits with regard to cooling and workload.


Ya I have my EDC TDC PPT set so my processor doesnt go over 70 per core.. I can crank it up more but ill leave it here for now until I figure out my curve


----------



## des2k...

Has anyone here actually tested if their -CO value work under 100% load ?

If I take the good cores that pass 8h corecycler like -28 -25 and do Prime95 blend 24t (5900x) it's insta crash.

To get that to pass, values need to be -12 or -6. I just don't see how -28(140mv) undervolt would survive a heavy load on the cpu when pushed to 200w+

Maybe it's my cpu, but any CO changes on 1 core has the potential to crash any 11 cores which already passed on prev test.


----------



## nikobobich

I have so many questions but im learning ... I will get this right


----------



## Frosted racquet

des2k... said:


> Has anyone here actually tested if their -CO value work under 100% load ?


In my experience, if you test with CoreCycler long enough you'll also be stable at all core loads. 8h for 12 cores is not nearly enough to test stability.
What settings for CoreCycler were you using and what were the settings used for all core load in Prime95? (SSE or AVX2?)


----------



## nikobobich

Let me ask you guys something, Is it better to find your stable curve before you say add +100 or +150 boost override? wouldnt it be logical to find the curve 1st if the curve is stable the boost override will work right>?


----------



## Frosted racquet

No, if you add +50MHz to your previous curve you'll need to retest because the curve is tied to the frequency offset. Do +200MHz and work on your curve.


----------



## des2k...

Frosted racquet said:


> No, if you add +50MHz to your previous curve you'll need to retest because the curve is tied to the frequency offset. Do +200MHz and work on your curve.


Depends of the cpu. I know Auto OC +0 to +200 doesn't change the freq steps I hit with corecycler.

Those Auto OC max freq(5 - 5.1 on the 5900x) will happen on very light load: boosttester (array shuffle), 3dmark loops, games, etc and not corecycler.


----------



## Frosted racquet

Right, but then you're limited by some other variable like temps, PPT/TDC/EDC if your frequency doesn't go to the set offset. If you can't get any more frequency out of the chip by tweaking PPT/TDC/EDC then focus on lowering the CO offsets, that way you can get more MHz for loads that don't rely on single core boosting.

Strictly speaking for the question before, increasing _effective_ clock requires a modification to the CO curve. I guess that's the more correct way of putting it.


----------



## nikobobich

Frosted racquet said:


> In my experience, if you test with CoreCycler long enough you'll also be stable at all core loads. 8h for 12 cores is not nearly enough to test stability.
> What settings for CoreCycler were you using and what were the settings used for all core load in Prime95? (SSE or AVX2?)


Im reading and seeing from other benchmarks its not really a difference with boost override unless ur using single cores.. its alot better for gaming without boost override and just curve only.. there's others with benchmarks that prove it.

Ive just been cycling Y-Cruncher and CoreCycler already found 4 errors.. just as I was typing this my computer crashed APC 24 Whea Error (core 12) gotta bring it down by -1 LOL.... haha...

The YCruncher Kagari script works good

Gonna feed my excel spread sheet and put histograms in there for you guys as I go and show the progress over the next few weeks! Already working on a nice one I have years of excel experience from work. Keeping screenshots and a Dialogue of everything as I go.

Thanks everyone for the help


----------



## ArchStanton

@nikobobich I think the @ManniX-ITA method might help regarding +MHz vs CO counts. Find peak boost without clock stretching, and then proceed. His video describing his methodology: Zen 3 Curve Optimizer Tuning with PJVol's PBO Tuner, BoostTester, HWInfo, CoreCycler - YouTube.


----------



## nikobobich

ArchStanton said:


> @nikobobich I think the @ManniX-ITA method might help regarding +MHz vs CO counts. Find peak boost without clock stretching, and then proceed. His video describing his methodology: Zen 3 Curve Optimizer Tuning with PJVol's PBO Tuner, BoostTester, HWInfo, CoreCycler - YouTube.


Thanks for the information ill definitely watch the video and learn what I can. another error on Core Cycler over the past hour im just running it on auto small SSE


----------



## nikobobich

does PBO2 Tuner Automatically update the bios when you apply similar to Ryzen Master? You just have to reboot for it to plug the settings in? I can use PBO2 tuner like ryzen master right? if I want to Test my power limits?


----------



## nikobobich

you guys will never guess what happened from a few of these crashes lately.. my system got alittle messed up and somehow kept switching to another profile I had on ryzen master ...like an idiot I put ryzen master on my cpu kept changing my profile back to another one everytime I ran cinebench and never kept my custom profile..Lesson learned dont use ryzen master..

I had to reset my cmos and reload the pbo profile. You only need hwinfo and pbo tuner.. ryzen master is really glitched out dont use the newest version it crashes all the time and screws with ur bios..its annoying removing ryzen master they like force you to use it .. u have to literally deep scrub it off your computer


----------



## Blameless

nikobobich said:


> Let me ask you guys something, Is it better to find your stable curve before you say add +100 or +150 boost override? wouldnt it be logical to find the curve 1st if the curve is stable the boost override will work right>?


I need radically different curves for different boost overrides on my 5800X because overboosting (or undervolting too far), even for a fraction of a second, can cause instability. Maxing out boost override is often completely counter productive.


----------



## tc9566

Ok I'm finding that core cycler is stable with HWinfo running as long as I'm using my comp. Within 10 minutes of it idle crashes and the core number is random. It will run for hours as long as I'm using it and event viewer shows the crash as...
Faulting application name: HWiNFO64.EXE, version: 7.22.4731.0, time stamp: 0x62445990
Faulting module name: HWiNFO64.EXE, version: 7.22.4731.0, time stamp: 0x62445990
Exception code: 0xc0000005
Fault offset: 0x0000000000264c25
Faulting process id: 0x3104
Faulting application start time: 0x01d85ca5cd0027cc
Faulting application path: C:\Program Files\HWiNFO64\HWiNFO64.EXE
Faulting module path: C:\Program Files\HWiNFO64\HWiNFO64.EXE
Report Id: ab35efc9-5b54-4f60-ab0f-95e8b844577f


----------



## Luggage

des2k... said:


> Depends of the cpu. I know Auto OC +0 to +200 doesn't change the freq steps I hit with corecycler.
> 
> Those Auto OC max freq(5 - 5.1 on the 5900x) will happen on very light load: boosttester (array shuffle), 3dmark loops, games, etc and not corecycler.


With enough cooling you will hit boost limits.
This is why hot builds can run stable -30, they don't boost enough to get unstable because of thermals.


http://imgur.com/l59VdWl


----------



## ManniX-ITA

Luggage said:


> With enough cooling you will hit boost limits.


Yes I could go over the base boost limit of my 5950X B0, 5050 MHz, with CoreCycler.
This even with air cooling, topping up to 5060-5080 MHz

The important factor is the FFT size and instructions set.
Lower FFT size, lower clock, more heat.
SSE will boost higher than AVX/AVX2.

That's why it's important to first test with smaller FFT sizes first and then go up.
Best for me is FFT range 16000-27000 which will trigger the highest clock and complete in 5 minutes.
If you test first with 720K it's less likely the CPU will reset if unstable.


----------



## sp00n82

ManniX-ITA said:


> Yes I could go over the base boost limit of my 5950X B0, 5050 MHz, with CoreCycler.
> This even with air cooling, topping up to 5060-5080 MHz
> 
> The important factor is the FFT size and instructions set.
> Lower FFT size, lower clock, more heat.
> SSE will boost higher than AVX/AVX2.
> 
> That's why it's important to first test with smaller FFT sizes first and then go up.
> Best for me is FFT range 16000-27000 which will trigger the highest clock and complete in 5 minutes.
> If you test first with 720K it's less likely the CPU will reset if unstable.


Wait, you're contradicting yourself here. First you say it's important to test with smaller FFT sizes, but then you say 16000 - 27000 are best, which are far from the small FFT sizes. You should probably correct yourself to not confuse anyone seeking advice.

To reiterate:
Small FFT sizes will put enormous stress on the CPU, which will likely cause thermal or electric limitation of the maximum boost clock speed.
Large FFT sizes will cause less stress on the CPU, while still utilizing it 100%, but with more thermal and electric headroom, so the boost clock can go higher. Which could bring it into territory where the boost clock is so high that it becomes unstable.

The same underlying principle is in effect for SSE & AVX(2). AVX & AVX2 uses "more" of the CPU (there are dedicated transistors for these instructions), generating more heat, using more power, so it can't boost as high as the "lighter" SSE instructions.

In the end it's important to remember that you need to test both (resp. all) scenarios though.


----------



## ManniX-ITA

sp00n82 said:


> Wait, you're contradicting yourself here. First you say it's important to test with smaller FFT sizes, but then you say 16000 - 27000 are best, which are far from the small FFT sizes. You should probably correct yourself to not confuse anyone seeking advice.


Sorry maybe I wasn't clear.
This is a recommendation to avoid wasting time.

The order is what matters.
Best of course is to test all with all instructions set.
Hammering the 720K is very effective but I'd recommend to test all sizes if possible.
Different conditions, different samples, will fail at different sizes.

If the CPU is unstable at the set CO count while testing a small FFT will most likely error without a CPU reset; black screen and reboot.
Usually just fails the Prime calculation.
The core frequency clock will peak at about 4800-4900 MHz.

When you test with a larger FFT the clock will peak much higher, well over 5000 MHz if you have a good sample.
That's the case where very frequently, instead of just P95 failing, the CPU will reset; instead of Prime failing you get a black screen and reboot.
It's a very unfriendly "protection mechanism" from AMD to avoid you can run at high clock frequency an unstable core.

If you test first with smaller FFT and find a likely stable count then the probability of a CPU reset while testing later the larger FFTs is greatly reduced.
It can always happen but much less likely.

When you fail to test properly large FFTs very often the result is the CPU stable in (almost) everything but resetting while browsing internet or in idle.

I've got an incommensurable amount of resets testing my old 5950X.
Once I've realized that I should have first tested the small FFT and later the large, the resets when down to almost none.

In the video where I check for counts on the 5800X, boosting at +200 on almost all cores, I've got just one reboot during the whole process.

There's also the unfortunate exception of Core 0 of course.
It runs most of the critical Windows processes so if it's unstable you can easily get a CPU reset even when testing small FFTs or just doing nothing.


----------



## PJVol

sp00n82 said:


> In the end it's important to remember that you need to test both (resp. all) scenarios though.


Regardess of whichever you test first, small or large, the steady, consistent load is not good for the stability testing, unless you get to the very conservative curve as a result. Besides the ability to handle sustained heavy load, there could be other factors potentially driving people mad.

What's annoying is they originated both from architecture specifics and hw/fw issues.
Among the first i'd mention the undervalued impact C-state boost and EDC limit has on core/ccx stability.

On the other hand, in DDR4 thread, I gave an example where CPU may sometimes (1:3) fail to complete OCCT benchmark, and this always happening at the ST > MT transition (no matter, SSE or AVX) due to incorrect target frequency set by SMU (could be 100-150mhz higher than required to pass MT), - this is 100% reproducible with my current setup. As a possible explanation, for some reason EDC throttler doesn't always keep up with the big activity spike, thus not adjusting EDC threshold properly.


----------



## ManniX-ITA

PJVol said:


> Regardess of whichever you test first, small or large, the steady, consistent load is not good for the stability test, unless you get to the very conservative curve as a result.


I tend to disagree 
Consistent load is very good for the stability test; it needs to be complemented with some real workload but it's more than enough to get a very high confidence.
Gaming is the best to validate but I prefer to get there at a point where it's unlikely I have issues.
From my experience testing with CoreCycler completely killed random reboots and instabilities, like Visual Studio hanging in the void while compiling.

Plus CoreCycler it's not really a consistent load like OCCT, it's frequently switching the FFTs and you can configure a pause in between.

But yes I tend to agree about all the rest, there are other issues with C-state and EDC which are often mixing up with CO counts instabilities.
When this happens is very difficult to understand where the issue is coming from...


----------



## PJVol

ManniX-ITA said:


> Consistent load is very good for the stability test; it needs to be complemented with some real workload but it's more than enough to get a very high confidence.


Yeah, the discourse thus moves into the personal preferences area, which is as useful as debating theology, or like the age-old question, - how stable the "stability" should be.
Though have to admit, switching workloads while cycling cores could brings some sense to it


----------



## ManniX-ITA

PJVol said:


> Yeah, the discourse thus moves into the personal preferences area, which is as useful as debating theology, or like the age-old question, - how stable the "stability" should be.


Yes, there's a huge degree of variance in what is considered stable or not by each one of us.
I'm pretty draconian in the definition but then there's always a difference between practice and theory.
Didn't trouble me to run for long time at IF 2000 with wheas in background 
I prefer to be more conservative considering I'm overclocking whatever I can.
But still, like while I'm driving, a few shortcuts and speeding over the limits is an acceptable risk 

I can say that from my experience testing with CC proved to be worthwhile and reliable.
I've also tried to run this trashy 5950X with its best core at +1 instead of +2.
It was failing only after a very long time with CoreCycler.
And again in less than one week I got a black screen and reboot.
Went back to +2 and so far so good.


----------



## nikoli707

5800x3d
Im using PBO2 Tuner from PJVol... blessings. It seems to be working beautiful, +400 on my C23 scores, drops my temps by about 8c(88c to 80c), and looking at my effective clocks it is holding all cores 43.5-43.9ghz, 4.40ghz reported. Prime is different because of avx, i forget. Anyways, since im totally locked out of OC, this is decent.

As others have done, using PBO2 Tuner, im trying to have it load at windows and apply the max -30 all cores. I have it set up in task scheduler at user login, eight -30's added as arguments, also went into "PBO2 tuner.exe.config" and set "<value /> -30|-30|-30|-30|-30|-30|-30|-30/>".

PBO2 Tuner is definitely loading at startup as expected (i see it in task manager) but its definitely not applying the CO via the strings/arguments that i have set as the temps are back up, cores drop 100-200mhz, and my C23 scores are down. As also expected, if i then manually apply -30 CO again, im back where i want to be.

What exactly am i doing wrong? I wish it could just load and minimize to the system tray.


----------



## KedarWolf

nikoli707 said:


> 5800x3d
> Im using PBO2 Tuner from PJVol... blessings. It seems to be working beautiful, +400 on my C23 scores, drops my temps by about 8c(88c to 80c), and looking at my effective clocks it is holding all cores 43.5-43.9ghz, 4.40ghz reported. Prime is different because of avx, i forget. Anyways, since im totally locked out of OC, this is decent.
> 
> As others have done, using PBO2 Tuner, im trying to have it load at windows and apply the max -30 all cores. I have it set up in task scheduler at user login, eight -30's added as arguments, also went into "PBO2 tuner.exe.config" and set "<value /> -30|-30|-30|-30|-30|-30|-30|-30/>".
> 
> PBO2 Tuner is definitely loading at startup as expected (i see it in task manager) but its definitely not applying the CO via the strings/arguments that i have set as the temps are back up, cores drop 100-200mhz, and my C23 scores are down. As also expected, if i then manually apply -30 CO again, im back where i want to be.
> 
> What exactly am i doing wrong? I wish it could just load and minimize to the system tray.











CoreCycler - tool for testing Curve Optimizer settings


I don't fully understand everything PJVol is saying, but adding a command line call would be all that is necessary, unless that just doesn't work for some reason. I don't know if it works or not because I don't know what command to call. I'd expect to be able to use rundll32...




www.overclock.net





Debug-CLI.7z Need to use this version of PBO Tuner though in the Drive link.


----------



## nikoli707

KedarWolf said:


> CoreCycler - tool for testing Curve Optimizer settings
> 
> 
> I don't fully understand everything PJVol is saying, but adding a command line call would be all that is necessary, unless that just doesn't work for some reason. I don't know if it works or not because I don't know what command to call. I'd expect to be able to use rundll32...
> 
> 
> 
> 
> www.overclock.net
> 
> 
> 
> 
> 
> Debug-CLI.7z Need to use this version of PBO Tuner though in the Drive link.


thanks that definitely did it ))


----------



## KedarWolf

nikoli707 said:


> thanks that definitely did it ))


----------



## nada324

Hey all, i just got a reset and idk atm which core is probably 0, i tested for the past two days:
(5600x +200MHZ 4.85ghz SC, running motherboard limit for the pbo)
These range i got from @ManniX-ITA video of 5800x.


4-720 SSE tested only
720-720 SSE tested only
16000-27000 SSE tested only
720-32768 SSE and AVX2 tested
All in SSE and didnt got any reset or error, should i test them in AVX or in AVX2? 

To try to find the core that cause instability 
Thank you


----------



## ManniX-ITA

nada324 said:


> 720-720 SSE tested only


For how long did you test 720K on a single core?


----------



## nada324

ManniX-ITA said:


> For how long did you test 720K on a single core?


Tested 9h straitgh, a night, no single error detected
Can reset maybe be because FCLK (1900 with no single whea 19) not stable or RAM issue? Although tested ram OC while back and was stable


----------



## ManniX-ITA

nada324 said:


> Tested 9h straitgh, a night, no single error detected


Yes but how long, how many minutes, was the cycle on a single core?


----------



## nada324

ManniX-ITA said:


> Yes but how long, how many minutes, was the cycle on a single core?


With 10min for each core, having this numberOfThreads = 1 set to 1, but i have SMT enabled, should i put this to 2?


----------



## ManniX-ITA

nada324 said:


> With 10min for each core, having this numberOfThreads = 1 set to 1, but i have SMT enabled, should i put this to 2?


No better 1 thread only.
Try to make a couple of round with 20mins for each core.
I had once one core failing only after 12 minutes.
It's rare but it can happen.
Otherwise you have to test more FFTs to try to catch the offender.


----------



## nada324

ManniX-ITA said:


> No better 1 thread only.
> Try to make a couple of round with 20mins for each core.
> I had once one core failing only after 12 minutes.
> It's rare but it can happen.
> Otherwise you have to test more FFTs to try to catch the offender.


720K-720K sse 20min each core SC not luck :/


----------



## ManniX-ITA

nada324 said:


> 720K-720K sse 20min each core SC not luck :/


I would first check if it could be something else.
Like the DF C-state in AMD CBS, should be disabled in Auto try with enabled.
Or changing the SOC/vCore OCP/OVP settings in the VRM section if available.
Otherwise try going over the FFTs with AVX.
It's not exactly the same testing with AVX2.


----------



## nada324

ManniX-ITA said:


> I would first check if it could be something else.
> Like the DF C-state in AMD CBS, should be disabled in Auto try with enabled.
> Or changing the SOC/vCore OCP/OVP settings in the VRM section if available.
> Otherwise try going over the FFTs with AVX.
> It's not exactly the same testing with AVX2.


I have a asus board and it does let me disable it, so i disabled it, was on auto before:
Also i put power supply control to typical current idle 
Lets see.


----------



## ManniX-ITA

These are the options that usually helps me fixing CPU resets with tight CO counts:










CPU and SOC LLC is really very specific to the board.
With the AORUS Master the best results are always with a strong CPU LLC (High/Ultra) and SOC LLC )Medium/High).
For the MSI it's almost always better to keep Auto, especially the CPU.
Otherwise the scores will go down, especially CB R21.
On the ASUS unfortunately I don't remember what I've set for the 5800X 
Think I had to leave it to Auto but I'm not sure.

The PWM switching frequency is of course very important and very dependent on VRM section quality.
The 5950X on my Unify-X at 700 kHz and below is unstable.
Both CPU and SOC are equally important. Slight difference in frequency can help with coil whine.
Cheap boards with low-end VRM can limit the CO counts you can reach stable and limit the performances.
The poor ASUS B550 TUF Gaming can run my 5800X stable but with a -100 ST and -1000 MT point is Geekbench 5.
I guess trying to run the 5950X there would seriously limit the CO counts.

CPU Over Voltage & Current protections are one of the main reasons for CPU resets, especially in idle.
When there's a single/low-threaded boost, especially in idle, there's a massive spike for the VRM.
Unfortunately AFAIK this is something not available on ASUS boards, at least the cheap ones.
OVP always maxed at 400mV.
On Gigabyte it's usually better OCP Medium/High.
MSI, at least mine and others I've seen, better Enhanced only on CPU. 
If SOC is not Auto will cause random CPU resets.

Then there's the special Digi+ VRM from ASUS:









Here I couldn't really find a pattern on the B550 TUF...
I've run the 3600XT, 3800X and 5800X.
Had to struggle a lot with the 3800X and 5800X.
Every CPU needed different settings.
Stability testing was a tragedy; 8 hours of synthetic tests like y-cruncher and OCCT, etc etc stable and my niece would BSOD in less than an half hour gaming....

I always max out both SOC and LLC frequencies.
ASUS uses the dual/tri MOSFET setup for phase so the frequency is low; there should be no need to keep the SOC a bit lower.
Not sure what Current Capability is doing, maybe it's some sort of OCP.
I test it at 110/120% which one is the best, going at 130% usually ends up in an unstable system.
Not sure also about Duty and Phase control, depends on the CPU. They can easily end up as well with an unstable system.
Normally I set them exactly as in this screenshot.
But for a more juicy CPU with a better board could be better a different setup.


----------



## sp00n82

BTW, I've finally came around to updating to version 0.9.0.0, which now also supports Prime95 30.7 and 30.8, and 30.8b15 is included by default.










Release v0.9.0.0 · sp00n/corecycler


Added support for Prime95 versions 30.7 and above. Also updated the included Prime95 version to 30.8b15. For more recent Prime95 versions the FFT size where an error happened is provided in the log...




github.com


----------



## wazer

PJVol said:


> @Dijati
> You can try to add binary at the windows startup with the CO values passed as arguments.
> 
> But *before* that, you may check if values are applied if entered in a command line correctly (see above post) - it should apply values and then close itself.
> When starting app from CMD or PS, if arguments are not passed it will run as the usual GUI app. If arguments are passed but invalid - it just closes.



Hey I have a 5950x on ROG Crosshair VIII Hero & a 5900x on ROG Strix X570-I Gaming

The latter ROG Strix X570-I Gaming cannot see/read info in PBO2 Tuner limits window, but curve does show up info, any support for that ?










PBO2_tuner_RZgMnhB8h9.mp4


Watch "PBO2_tuner_RZgMnhB8h9.mp4" on Streamable.




streamable.com


----------



## PJVol

wazer said:


> cannot see/read info in PBO2 Tuner limits window


That could happen due to me being too lazy to implement code for waiting for the pp_table is ready 
In such a case just close and reopen app should help.


----------



## wazer

PJVol said:


> That could happen due to me too lazy to implement code waiting for the pp_table is ready
> In such a case just close and reopen app should help.


I tried many times restarting the app, same issue every time.


----------



## PJVol

@wazer 
What is the bios/agesa version on strix?


----------



## wazer

PJVol said:


> @wazer
> What is the bios/agesa version on strix?



I tested on both 1.2.0.6b and now 1.2.0.7 which is


ROG STRIX X570-I GAMING BIOS 4403 
"Update AMD AM4 AGESA V2 PI 1.2.0.7


----------



## homework

How do you get pbo tuner to just work every time you start your pc?

EDIT: you have to use the CLI modded version, post #765.


----------



## izallica

hi all i got error after few hours 5600x +200MHZ ppt 76 tdc 60 edc 90 |-20|-10|-30|-30|-20|-25|
tested 720 -720 sse
core 0 is the fastest core, do I have to repeat this test again until the 6th iteration after lowering the CO offsets core 0 ?


----------



## sp00n82

It's random at which iteration an error can occur, especially if you're only running a single FFT size. Of course there is a tendency that the more unstable an overclock is, the faster an error will happen, but you can't pinpoint this to an exact number of iterations.
This means that you can't be 100% sure that your setting is stable yet just because it passed the amount of iterations where it threw an error the last time. The next error may just wait for you in the next iteration.
However 20 minutes x 6 are 2 hours of stress testing per core, generally speaking this is already a pretty good baseline for further optimization. Just don't stick to 720 FFT only.


----------



## Frosted racquet

I think I'm done with stability testing. Big thanks to @PJVol for PBO2Tuner as I was away from the PC for the majority of testing, connecting via TeamViewer and changing the CO on the fly was very convenient. If anyone's interested in the testing log I'll post it in a spoiler, as it's long.

My notes on the testing and some recommendations, pretty much a summary of things I learned in this thread:
1. make sure temperatures are in check, higher temps decrease effective clock and in turn can lead to a false sense of stability in a particular CO offset.
2. as people suggested in this thread, first try to guess which CO offset is stable for all cores, i.e all cores can sustain -10 CO and start working your way from there. Min/maxing the CO (-30,0,0,0 etc.) can lead to one core affecting the stability of another, which would lead you to modify the CO of a core that could be stable if the other core wasn't negatively affecting it.
3. In my case, yCruncher Kagari profile _without_ SMT isn't more difficult to pass compared to Kagari _with_ SMT. My ambient temps were below 15°C and watercooled during tests, so the temps were in check in both cases. Whether SMT on is more difficult than SMT off I cannot say, as I tested with SMT on first, SMT off later.
yCruncher Kagari in my opinion is very difficult to pass, consider using it in conjunction with Prime95 SSE.

I decided to use Kagari with SMT on as a clock stretching test as well, although unrealistic I could spot some differences in core boosting.

One funny (and sad) note is that I crashed twice at 90ish iterations, which was frustrating as you'd imagine.



Spoiler: test log



Testing procedure
Motherboard limits for PPT/TDC/EDC produce higher multi-core scores, while 130/90/130 produces better single-core scores. CO set to -10 for all cores as a starting "stable" point.

-10|-10|-10|-10|*-17*|-10
Core 4 crashed with -18 CO, stable with -17 CO (~15h Kagari with SMT), clock stretching ~30MHz. Core 1,2,3 also have slight clock stretching (~15MHz)- increase their CO

-10|*-16|-16|-16*|-17|-10
Passed 25 cycles Kagari with SMT, Core 1,2,3 no longer have clock stretching, still clock stretching on Core 4, seems slightly less than previously.
LinpackXtreme 10GB 264GFlops peak score with 130/90/130 limits. 268GFlops with motherboard limits
Passed Prime95 SSE single threaded for ~16h

*-15*|-16|-16|-16|-17|-10
Core 0 passed -15 CO ~8h Kagari without SMT, -16 CO crashes

-15|-16|-16|-16|-17|*-22*
Core 5 passed -22 CO ~6h Kagari without SMT, -24 CO crashes

-15|-24|-16|-16|-17|-22
Cores 1, 2, 3 seem to pass -24 CO by themselves, although it seems those values interfere with other cores’ stability, judging by previous attempts to stabilize.
-15|-18|-18|-18|-17|-22 with 130/90/130 limits for PPT/TDC/EDC

Testing single core:
-Prime95 All-SSE: -15|-18|-18|-18|-17|-22 passed ~56h (8 iterations)
-Prime95 All-AVX: -15|-18|-18|-18|-17|-22 passed ~72h (5 iterations)
-YCruncher 10 min-Kagari with SMT: -8|-18|-16|-18|-16|-12 passed ~207h (200 iterations) (offsets changed from -15|-18|-18|-18|-17|-22 to -8|-18|-16|-18|-16|-12 to stabilize)
-YCruncher 10 min-Kagari: -8|-18|-16|-18|-16|-12 passed ~191h (190 iterations)
-YCruncher 10 min-x86-00: -8|-18|-16|-18|-16|-12 passed ~101h (100 iterations)
-OCCT: -8|-18|-16|-18|-16|-12 passed 1h of OCCT CPU stress test

Testing all cores:
-YCruncher: -8|-18|-16|-18|-16|-12 passed 45h
-Prime95 small FFT FMA3: -8|-18|-16|-18|-16|-12 passed 12h
-LinpackXtreme 10GB: -8|-18|-16|-18|-16|-12 passed 1000 cycles
-OCCT: -8|-18|-16|-18|-16|-12 passed 1h of OCCT CPU stress test



My CPU after testing:








EDIT: if we can create a leaderboard for amount of time stress testing CO values I'd be grateful


----------



## PJVol

@Frosted

It'd nice to share the core CPPC ranking.
And may be a couple of screenshots of hwinfo while in allcore workload


----------



## Frosted racquet

Here's the info from HWInfo. At the moment I'm running a box cooler, RMAd the watercooler, don't know how temps affect the CPPC ratings.

















> And may be a couple of screenshots of hwinfo while in allcore workload


LinpackXtreeme 10GB stress and yCruncher with all test enabled.


----------



## PJVol

As far as i see, very aggressive Load-Line slope is set on your VRM. I myself set it to ~ 50-63 mv Vdroop for such workloads. This could help to increase performance but most likely ruin your current CO settings.


----------



## Frosted racquet

I left the LLC on Auto, but will play around to see if there's any performance benefit.

P.S Snapshot CPU polling is enabled in HWINFO, just incase it matters on voltage readouts.


----------



## PJVol

Hmm ... i've got MSI board at the office and IIRC lvl 4 or 5 is fine.


Frosted racquet said:


> just incase it matters on voltage readouts.


Not quite. Can you run y-crucher Super pi test (0->1->7) ? And increase the PPT limit by 5W. You are hitting it in Linpack.
Here are my tests with a Load-line set to ~50-60mv vdroop for the CPU VR, and memory running 3600 CL16 (though RAM speed didn't affect much the Linpack score)


----------



## Frosted racquet

Unfortunately the Box cooler I have ATM will not be able to cool down the CPU in those tests with 130+ PPT, I can run them when I get my AIO back from RMA.
I have done a yCruncher SuperPi 1b test in Bench mate previously when I still had the AIO installed, if it helps. This is with RAM 3600 14-8-14-14-22-36 2T


----------



## PJVol

Frosted racquet said:


> I have done a yCruncher SuperPi 1b test


Yeah. It looks okay. Mine for 1b ~ same:


----------



## Frosted racquet

PJVol said:


> Yeah. It looks okay. Mine is ~ same:


Thanks for looking into it, appreciate it.  Feeling better that voltages and performance are OK-ish
Don't know if RAM timings have some influence on the result in SuperPi, since I tweaked the timings compared to your CL16...


----------



## PJVol

Frosted racquet said:


> Don't know if RAM timings have some influence on the result in SuperPi


I don't think so. IMHO its purely computational, i.e. most of the temporal results are not leaving L2/L3, though may be wrong here.
Hope your AIO will be ok.


----------



## Teussi

Blameless said:


> I like scheduled tasks:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Note, never run random applications from strangers as SYSTEM with highest privileges, not without taking a good look at what it does first and scanning it for malware.


I just cannot get this automatic startup to working. Downloaded to CLI file, tried both ways, this scheduled tasks and other one

"Add a new shortcut to your Startup (Autostart) folder to the .exe file he posted, and add the CO values as the arguments."

Still no luck. rebooted and tested and no curve is applied. Have to manually open and enter values and then its working. Dont understand. Anyone have tips to get this working.
EDIT: task manager says "The task has not yet run" after reboot


----------



## KedarWolf

Teussi said:


> I just cannot get this automatic startup to working. Downloaded to CLI file, tried both ways, this scheduled tasks and other one
> 
> "Add a new shortcut to your Startup (Autostart) folder to the .exe file he posted, and add the CO values as the arguments."
> 
> Still no luck. rebooted and tested and no curve is applied. Have to manually open and enter values and then its working. Dont understand. Anyone have tips to get this working.
> EDIT: task manager says "The task has not yet run" after reboot


Did you use the version that accepts the startup command? I believe there are two versions, the regular one and the modded one.

You need the modded one.


----------



## Teussi

KedarWolf said:


> Did you use the version that accepts the startup command? I believe there are two versions, the regular one and the modded one.
> 
> You need the modded one.


Yes, the modded one: 



PJVol said:


> @paih85 @Dijati et al )
> Can you try this binary:
> (it should accept CO values in command line. This is test version, so the main application window may appear before exit)
> Debug-CLI.7z
> 
> 
> Code:
> 
> 
> 'path-to-a-binary\PBO2 tuner.exe' 1 2 3 4 5 6 7 8 (for the 5800's)
> 
> Args number should be equal to the active cores count (i.e. 8 in case of 5800x3d)


----------



## KedarWolf

Teussi said:


> Yes, the modded one:


Google how to use Task Scheduler and make sure you set it up right. Or check the post again that shows how to set it up.

Here.









CoreCycler - tool for testing Curve Optimizer settings


I don't fully understand everything PJVol is saying, but adding a command line call would be all that is necessary, unless that just doesn't work for some reason. I don't know if it works or not because I don't know what command to call. I'd expect to be able to use rundll32...




www.overclock.net





Do you have it to run as System?


----------



## Teussi

KedarWolf said:


> Google how to use Task Scheduler and make sure you set it up right. Or check the post again that shows how to set it up.
> 
> Here.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> CoreCycler - tool for testing Curve Optimizer settings
> 
> 
> I don't fully understand everything PJVol is saying, but adding a command line call would be all that is necessary, unless that just doesn't work for some reason. I don't know if it works or not because I don't know what command to call. I'd expect to be able to use rundll32...
> 
> 
> 
> 
> www.overclock.net
> 
> 
> 
> 
> 
> Do you have it to run as System?


Will double check it again and see if i messed something with Task scheduler.

EDIT2: Managed to get it working, thanks a lot Kedar, it was the system thing and trigger


----------



## KedarWolf

Teussi said:


> Will double check it again and see if i messed something with Task scheduler.
> 
> EDIT2: Managed to get it working, thanks a lot Kedar, it was the system thing and trigger


----------



## I K E T K I D K E

PJVol said:


> @paih85 @Dijati et al )
> Can you try this binary:
> (it should accept CO values in command line. This is test version, so the main application window may appear before exit)
> Debug-CLI.7z
> 
> 
> Code:
> 
> 
> 'path-to-a-binary\PBO2 tuner.exe' 1 2 3 4 5 6 7 8 (for the 5800's)
> 
> Args number should be equal to the active cores count (i.e. 8 in case of 5800x3d)


Hello!

Just started tinkering on the 5800X3D and your version was working wonderfully. A rock solid -50 offset on all cores! I had it set up with task scheduler to run when I log in and it was working great yesterday and this morning.

I was running a few more benchmarks comparing my manual offset, stock, and CO settings to get a clearer picture and it stopped applying on log in.

I cannot manually launch your version of PBO2 Tuner either. I get an error that says "Error Opening WinRing Driver". 

I have no idea what changed to cause this.

Do you have any insight?

Thanks!


----------



## Luggage

I K E T K I D K E said:


> Hello!
> 
> Just started tinkering on the 5800X3D and your version was working wonderfully. A rock solid -50 offset on all cores! I had it set up with task scheduler to run when I log in and it was working great yesterday and this morning.
> 
> I was running a few more benchmarks comparing my manual offset, stock, and CO settings to get a clearer picture and it stopped applying on log in.
> 
> I cannot manually launch your version of PBO2 Tuner either. I get an error that says "Error Opening WinRing Driver".
> 
> I have no idea what changed to cause this.
> 
> Do you have any insight?
> 
> Thanks!


CO Values only go to 30.


----------



## Owterspace

Is there any program that uses the cpu like core cycler does? I don’t mean a stress test or anything like that. So far I have not come across anything that runs the cpu like core cycler.


----------



## Luggage

Owterspace said:


> Is there any program that uses the cpu like core cycler does? I don’t mean a stress test or anything like that. So far I have not come across anything that runs the cpu like core cycler.


No - there is no reason a program would stress all the cores one core at a time.
Except for stress testing - so occt has a similar function. Don’t know any other common programs.

But windows scheduler can assign a workload to any core - especially if you run with CPPC Preferred Cores turned off - so you want all cores stable.


----------



## KedarWolf

PJVol said:


> @paih85 @Dijati et al )
> Can you try this binary:
> (it should accept CO values in command line. This is test version, so the main application window may appear before exit)
> Debug-CLI.7z
> 
> 
> Code:
> 
> 
> 'path-to-a-binary\PBO2 tuner.exe' 1 2 3 4 5 6 7 8 (for the 5800's)
> 
> Args number should be equal to the active cores count (i.e. 8 in case of 5800x3d)


How do you get it to set the Limits etc. at boot?


----------



## PJVol

KedarWolf said:


> How do you get it to set the Limits etc. at boot?


It doesn't, since I don't know if any other mb vendor besides asrock, allows them to be overriden.
Afaik MSI doesn't allow for sure.


----------



## KedarWolf

PJVol said:


> It doesn't, since I don't know if any other mb vendor besides asrock, allows them to be overriden.


I think it works on my X570S Unify-X Max.

If I manually set the limits and set the Boost Clock to 5150 I shave over .100s off my y-cruncher with is a significant difference.

Before/after, below. Go by Total Computation Time, not Start To End.

Running the exact same PBO and RAM settings.


----------



## I K E T K I D K E

Luggage said:


> CO Values only go to 30.


It lets me put in -50 but only does -30? 

Well that's silly. 

I suppose it's doing nothing right now though unless I can get that error resolved. The temp drop with a manual offset is pretty awesome but it comes at a sizable performance loss.


----------



## Gegu

Hi guys,
Got some problem with brand new 5950X.

I have 5950X - stock settings, no PBO, no CO. Motherboard Crosshair VIII Extreme (AGESA 1.2.0.3c, default BIOS settings, XMP profile) But Core Cycler (720-720 or Moderated preset) is throwing errors on core0 no matter what. 

Does it mean I have defective core in my CPU?


----------



## ManniX-ITA

Gegu said:


> I have 5950X - stock settings, no PBO, no CO. Motherboard Crosshair VIII Extreme (AGESA 1.2.0.3c, default BIOS settings, XMP profile) But Core Cycler (720-720 or Moderated preset) is throwing errors on core0 no matter what.
> 
> Does it mean I have defective core in my CPU?


Same for my 5950X B2 (the 2nd).
Welcome to the fantastic world of B2 stepping, worse than the previous...

Had to enable PBO and CO and set +2 on my best core to avoid failure on this one.
Had strong discussions with the AMD rep with 1st one but it was so badly faulty that at the end even with the positive CO it did destroy my Windows install.
The 2nd is the same but it's reliable with the positive CO.
Of course the performances are below average.
But I'm fed up of swapping CPUs, have stuff to do so I kept it.
Don't let the AMD rep bully you saying it's your system which is faulty.

Forgot: yes, it's faulty

Don't tell the AMD Rep you have set XMP profile it's OC for them... you have set RAM to 2133 MHz for testing.


----------



## Gegu

ManniX-ITA said:


> Same for my 5950X B2 (the 2nd).
> Welcome to the fantastic world of B2 stepping, worse than the previous...
> 
> Had to enable PBO and CO and set +2 on my best core to avoid failure on this one.
> Had strong discussions with the AMD rep with 1st one but it was so badly faulty that at the end even with the positive CO it did destroy my Windows install.
> The 2nd is the same but it's reliable with the positive CO.
> Of course the performances are below average.
> But I'm fed up of swapping CPUs, have stuff to do so I kept it.
> Don't let the AMD rep bully you saying it's your system which is faulty.
> 
> Forgot: yes, it's faulty
> 
> Don't tell the AMD Rep you have set XMP profile it's OC for them... you have set RAM to 2133 MHz for testing.


Hah, you see ... I tested this even on diagnostic mode with SPD speed 2133mhz like you said and this error happened in Core Cycler.
Bios on default settings, no PBO, no boost, no Curve Optimizer. And it still happen.

BTW this CPU sample is B0. 

And what's (not) interesting ... it's my second defective 5950X in a row 

The first one is shutting down my PC during benchmarks on PBO without Curve Optimizer - it has fckin unstable PBO. 
Of course AMD is trying to say it's my system fault  But will discuss with them.


----------



## ManniX-ITA

Gegu said:


> BTW this CPU sample is B0.


Oh you are really unlucky then.
Be pushy cause they are not so willing to replace a 5950X, especially in Europe.
The AMD rep dared to tell me when he authorized the 1st B2 RMA that that he was not going to authorize another RMA if also the 2nd was faulty...


----------



## Gegu

ManniX-ITA said:


> Oh you are really unlucky then.
> Be pushy cause they are not so willing to replace a 5950X, especially in Europe.
> The AMD rep dared to tell me when he authorized the 1st B2 RMA that that he was not going to authorize another RMA if also the 2nd was faulty...


Yea.

And tell me, is it possible that a faulty motherboard can cause such errors? (although I also had a 5900X on this board and it worked perfectly)

CPU 1 (5950X B0) - unstable PBO in any form. With PBO enabled (even with Curve Optimizer disabled) during Cinebench R23 and Y-Cruncher 2.5b benchmarks the computer sometimes shuts down without warning. No BSOD's or WHEA's.

CPU 2 (5950X B0) - Core 0 faulty when testing Core Cycler (720-720 or Moderate preset) core 0 throws errors. This happens with PBO enabled, but even with CPU and BIOS stock settings. Also with every possible ram configuration.

I tested ram memory in TestMem5 - I did 25 cycles with 1usmus v3 preset - zero errors. Windows 10 up-to-date Latest drivers, etc. The best power supply I could buy.


----------



## ManniX-ITA

Gegu said:


> And tell me, is it possible that a faulty motherboard can cause such errors? (although I also had a 5900X on this board and it worked perfectly)


Yes it could have been a motherboard or PSU issue in the case of the first one but considering the 5900X working fine, the 2nd 5950X different behaviour and the excellent and oversized PSU... no way.


----------



## dkuster

Gegu said:


> Hi guys,
> Got some problem with brand new 5950X.
> 
> I have 5950X - stock settings, no PBO, no CO. Motherboard Crosshair VIII Extreme (AGESA 1.2.0.3c, default BIOS settings, XMP profile) But Core Cycler (720-720 or Moderated preset) is throwing errors on core0 no matter what.
> 
> Does it mean I have defective core in my CPU?


To get my (B2) 5950x stable and WHEA-Error free I had to initially set my Curve Optimizer offsets to:

+10, +5, -9, -12, -1, -25, -15, -21, -30, -30, -30, -27, -30, -24, -30, -22

But then I disabled 'Global C-States' in the BIOS and my stable CO settings became:

-2, -1, -17, -20, -8, -30, -22, -30, -30, -30, -30, -30, -30, -26, -30, -30

Both single-core and multi-core benchmarks improved slightly. Not sure if there are any downsides to disabling global C-states(?)

Anyway, I'm sure it's just psychological but I 'feel better' with this sample now that it doesn't require positive CO on certain cores to be stable.


----------



## Gegu

dkuster said:


> To get my (B2) 5950x stable and WHEA-Error free I had to initially set my Curve Optimizer offsets to:
> 
> +10, +5, -9, -12, -1, -25, -15, -21, -30, -30, -30, -27, -30, -24, -30, -22
> 
> But then I disabled 'Global C-States' in the BIOS and my stable CO settings became:
> 
> -2, -1, -17, -20, -8, -30, -22, -30, -30, -30, -30, -30, -30, -26, -30, -30
> 
> Both single-core and multi-core benchmarks improved slightly. Not sure if there are any downsides to disabling global C-states(?)
> 
> Anyway, I'm sure it's just psychological but I 'feel better' with this sample now that it doesn't require positive CO on certain cores to be stable.


Good for you 

On which FCLK do you have stable ram?


----------



## dkuster

Gegu said:


> Good for you
> 
> On which FCLK do you have stable ram?


1900 FCLK. I'm happy with that and don't feel the need to push it any further...


----------



## CubanB

PJVol said:


> It doesn't, since I don't know if any other mb vendor besides asrock, allows them to be overriden.
> Afaik MSI doesn't allow for sure.


I'm new to using your program and also to PBO2, it's only been a few days of learning/testing for me. But I've been using your program to reduce the values with the aim of achieving a quieter/effecient system, rather than peak gaming performance. For example long render times.

It's an MSI board. But what I've been doing is setting higher PPT or other limits in the BIOS. And then reducing them in real time in Windows and monitoring scores, wattage at the wall with a meter etc. For example with 5950X, reducing max boost to 4950Mhz, or reducing PPT, EDC to lower values etc. It won't let me increase above the setting in the BIOS (I guess this is what you meant by overriding) but it will let me reduce them and the wall meter reflects the difference. Even the BIOS won't let me reduce MaxBoost to below 5050Mhz, so for this alone your tool is very useful. Even if it's just to experiment.

When I find the right PPT or EDC values, I put them in the BIOS and don't get the same results after the restart. I get higher wattage at the wall and lower scores.

I can't explain why this is. It's only been a few days of learning. But if there could be a way to automate the settings on each login that would be really helpful. I don't know how many people would need or use this feature, but something like..

'path-to-a-binary\PBO2 tuner.exe' PPT 180, TDC 140, EDC 140, MaxBoost 4950 etc.. would be extremely useful for those of us out there experiencing superior performance (or lower wattage) for using your tool in Windows vs inputting these settings in the BIOS.

In terms of CO.. -30 etc, this has worked flawlessly both in BIOS and in the tool (same performance). But I've just been changing the values in real time, then inputting those values in the BIOS and it's worked well after the restart. The ideal situation would be an MSI Afterburner style tickbox in the UI of the tool itself, "apply settings on system startup", but I imagine this could be a lot of work to implement. Thanks very much for your tool, it's made tweaking this new CPU a lot of fun. To understand what is making the scores or temps go up or down.


----------



## sp00n82

@PJVol
I've finally taken a look at PBO2 Tuner now, and I think it would make great sense to include it in the tools directory within CoreCycler. Do I have your permission to include it in the zip file? I couldn't find any license file.

And by the way, despite all my work on CoreCycler, I've decided to run a fixed overclock/undervolt without PBO for over a year now, and when I open PBO2 Tuner it displays these values for the CO: 😅










This is the debug version from Debug.7z


----------



## PJVol

sp00n82 said:


> PBO2 Tuner it displays these values for the CO:


I think reading psm voltages isn't supported till agesa 1.2.0.0, since the mailbox interface version has changed.
Regarding using my utility, do whatever you want, I absolutely don't mind.


----------



## Owterspace

Just curious.. if windows doesn’t use the CPU like core cycler does, and no other program uses the cpu like core cycler does, then why run it?


----------



## sp00n82

PJVol said:


> I think reading psm voltages isn't supported till agesa 1.2.0.0, since the mailbox interface version has changed.
> Regarding using my utility, do whatever you want, I absolutely don't mind.


My BIOS version is 1.5, which according to CPU-Z and the MSI homepage has ComboAM4PIV2 1.2.0.0. I could update to 1.9 though, which includes ComboAm4v2PI 1.2.0.6c (or the beta version with 1.2.0.7), but I didn't want to change a running system.

Thanks for the permission, I'll probably push an update soon.


----------



## ManniX-ITA

sp00n82 said:


> My BIOS version is 1.5, which according to CPU-Z and the MSI homepage has ComboAM4PIV2 1.2.0.0. I could update to 1.9 though, which includes ComboAm4v2PI 1.2.0.6c (or the beta version with 1.2.0.7), but I didn't want to change a running system.


Good thinking don't update to anything above 1.2.0.3


----------



## ManniX-ITA

Owterspace said:


> Just curious.. if windows doesn’t use the CPU like core cycler does, and no other program uses the cpu like core cycler does, then why run it?


Doesn't really matter the type or workload.
If a core it's stable with CoreCycler the chances that core will fail with another workload are close to zero.
In practice, if you fully test all cores the reboots in idle will be gone.


----------



## Owterspace

ManniX-ITA said:


> Doesn't really matter the type or workload.


Ahh.. I thought it did. Only a few programs that I know of can get all of the cores moving up to the top of the boost range. Though not at the same time.



ManniX-ITA said:


> If a core it's stable with CoreCycler the chances that core will fail with another workload are close to zero.


Interesting.



ManniX-ITA said:


> In practice, if you fully test all cores the reboots in idle will be gone.


Again, interesting. I don't get idle reboots, so that's good. I don't get any reboots, whea, no problems. Doesn't pass core cycler though.


----------



## ManniX-ITA

Owterspace said:


> Again, interesting. I don't get idle reboots, so that's good. I don't get any reboots, whea, no problems. Doesn't pass core cycler though.


The most obvious issue is the idle reboot. 
But there are other instabilities that can arise if the cores are unstable.
Sporadic crashes, programs not starting or dying or stalling.
I use Visual Studio and if the cores are unstable sometimes when compiling it never finishes.
Depending on settings and the power profile it's less or more evident.


----------



## PJVol

CubanB said:


> (I guess this is what you meant by overriding)


Yep, this perhaps is more accurate. Not being a native english speaker, I wonder can the word "override" unambiguously mean exceeding some limit? 


CubanB said:


> I can't explain why this is. It's only been a few days of learning. But if there could be a way to automate the settings on each login that would be really helpful. I don't know how many people would need or use this feature, but something like..


This is due to the CPU running a bunch of self-tests at boot time to adjust its internal operating points, i.e. BTC AC and DC (boot time calibration for the desktops and battery power source), using the restrictions set in BIOS. So there's not much sense to launch it when OS starts - basically it's too late )).
It's their way to take into account various factors, such as silicon ageing or changes in ambient temps. And because of BTC accomplished way before the OS starts, theres no way to exactly reproduce the conditions your applications run at. So take this tool as the way to approximately simulate the real execution environment.


----------



## Owterspace

ManniX-ITA said:


> The most obvious issue is the idle reboot.
> But there are other instabilities that can arise if the cores are unstable.
> Sporadic crashes, programs not starting or dying or stalling.
> I use Visual Studio and if the cores are unstable sometimes when compiling it never finishes.
> Depending on settings and the power profile it's less or more evident.



For my system, it was SuperPi 32M that would be the most reliable to cause a reboot, at least with my settings. Once I figured out how to get 32M to run at top boost, getting it everything but core cycler stable was easy lol. I ran 32M on each core/thread individually using task manager for affinity control 

To get core cycler stable I have to dial things waaay back.. and for what I do I just don't see the need for it..


----------



## CubanB

PJVol said:


> Yep, this perhaps is more accurate. Not being a native english speaker, I wonder can the word "override" unambiguously mean exceeding some limit?
> 
> This is due to the CPU running a bunch of self-tests at boot time to adjust its internal operating points, i.e. BTC AC and DC (boot time calibration for the desktops and battery power source), using the restrictions set in BIOS. So there's not much sense to launch it when OS starts - basically it's too late )).
> It's their way to take into account various factors, such as silicon ageing or changes in ambient temps. And because of BTC accomplished way before the OS starts, theres no way to exactly reproduce the conditions your applications run at. So take this tool as the way to approximately simulate the real execution environment.


Thanks for your reply. You're English is very good, better than some people I know.. where it is their only language. 

There's a few different aspects where the tool is useful. With what you are saying, adjusting the settings in the OS is bypassing some built in safe guards at POST, when it does a self test.. and when adjusting the limits after these tests are completed, it is bringing some additional gains. It sounds like this would come with downsides, but I haven't noticed any instability or negatives from this so far. 

Manual OC has always been best for all core workloads for highest scores and lowest wattage, but with that you sacrifice boost behavior. With my current values, I've approached something close to having the best of all 3 aspects.. idle clocks and good idle power saving.. good 100% load and all core and also good boost when half the cores are loaded. Without needing to use ASUS Dark Hero Dynamic OC feature. I haven't noticed any downsides from this so far, but even if turns out that it's best to avoid this method and set the values in the BIOS, there's other benefits from your tool in my use case.

I am on an older OS, therefore Ryzen Master doesn't work. I use a lot of legacy stuff, and the older OS works for some of these things. I'll be running a dual boot situation with a modern OS later on, but for now.. trying to dial in the older OS. For this situation, the ability to adjust PPT on the fly is another great feature, without needing to reboot. For example.. if doing a 12 hour render.. lowering the PPT to keep noise and temps down. But if playing a high fps game.. increase PPT for better 1% lows in games and higher clocks. I understand that this is a rare use case, and probably most people use Ryzen Master for this and this isn't what the tool was intended for. But it's been a fortunate thing for me, that this tool was created and still has the ability to do these things.

One of the positives of the tool is that it's very light weight and simple. There's no telemetry or resource intensive aspects to it, no bloat etc. But if there was ever any future versions, I'm just trying to share some ideas for what could expand the functionality. For example, the ability to store presets in an ini file, or have profiles. For example profile 1 - stock power limits, profile 2 - power effecient PBO (long all core workloads), profile 3 - max performance PBO (high fps gaming or low core count workloads). Maybe for someone else it would be different profiles for different intensive simulation softwares etc. Like a different profile for each software. Or having different MaxBoost values or Max Temp for different situations. The ability to automatically run when Windows starts, or run at all times in the background with a tray icon. A reset or default settings button to revert settings to stock.

I understand that it's not what the tool was intended for, and it may never be updated anymore.. but just trying to share some ideas, if you ever wanted to expand the tool further. If there were a few of us in this situation, and you are busy or short on time, maybe we could make a donation, if it could help make that easier. If it stays as it is now, all I can do is say thanks for sharing it, because it's already been a big time saver and has offered a lot of useful functionality. I didn't even know MaxBoost could be reduced below stock value until trying your tool, in some use cases with the right settings, it does improve scores a little. I guess it reduces clock stretching. Also, the adjustment of PPT on the fly also works really well, in terms of finding the sweet spot for a specific all core workload.


----------



## Luggage

ManniX-ITA said:


> The most obvious issue is the idle reboot.
> But there are other instabilities that can arise if the cores are unstable.
> Sporadic crashes, programs not starting or dying or stalling.
> I use Visual Studio and if the cores are unstable sometimes when compiling it never finishes.
> Depending on settings and the power profile it's less or more evident.


The new OCCT stability test actually made me reduce CO on two new cores compared with earlier "stable" settings - 1 reboot and 1 software error. no whea.








Cpu Gold stability certificate - 6/6/2022 2:16:59 AM - Luggage


This is a very thorough 6h stability test : 1h CPU Large Extreme, 1h CPU Large, 1h CPU Medium, 1h Small Extreme, 1h Linpack v2021, 1h CPU Large ( 1 thread, cycling )




www.ocbase.com


----------



## ManniX-ITA

Luggage said:


> The new OCCT stability test actually made me reduce CO on two new cores compared with earlier "stable" settings - 1 reboot and 1 software error. no whea.


There's always the chance to miss something even testing all FFTs with all instructions set with CoreCycler.
Plus should be done both on single and all core and much more than one single pass.
It's almost impossible to really achieve a 100% coverage; you would need to spend a whole year to test a 5950X 
I always add a long session with OCCT and y-cruncher.
More you test, better the results. But at some point you need to stop testing and start using it...


----------



## KedarWolf

Luggage said:


> The new OCCT stability test actually made me reduce CO on two new cores compared with earlier "stable" settings - 1 reboot and 1 software error. no whea.
> 
> 
> 
> 
> 
> 
> 
> 
> Cpu Gold stability certificate - 6/6/2022 2:16:59 AM - Luggage
> 
> 
> This is a very thorough 6h stability test : 1h CPU Large Extreme, 1h CPU Large, 1h CPU Medium, 1h Small Extreme, 1h Linpack v2021, 1h CPU Large ( 1 thread, cycling )
> 
> 
> 
> 
> www.ocbase.com


What test and settings you use in OCCT?

I ran it overnight a few days ago using the latest Beta, no errors.

Running it again today


Luggage said:


> The new OCCT stability test actually made me reduce CO on two new cores compared with earlier "stable" settings - 1 reboot and 1 software error. no whea.
> 
> 
> 
> 
> 
> 
> 
> 
> Cpu Gold stability certificate - 6/6/2022 2:16:59 AM - Luggage
> 
> 
> This is a very thorough 6h stability test : 1h CPU Large Extreme, 1h CPU Large, 1h CPU Medium, 1h Small Extreme, 1h Linpack v2021, 1h CPU Large ( 1 thread, cycling )
> 
> 
> 
> 
> www.ocbase.com


Had to lower three cores by 1 point.

Here is my new for OCCT.


----------



## KedarWolf

KedarWolf said:


> What test and settings you use in OCCT?
> 
> I ran it overnight a few days ago using the latest Beta, no errors.
> 
> Running it again today
> 
> 
> Had to lower three cores by 1 point.
> 
> Here is my new for OCCT.
> 
> View attachment 2563194


Spoke too soon. Got errors on physical core 11.


----------



## PJVol

CubanB said:


> the ability to store presets in an ini file, or have profiles


It would certainly make sense if mb vendors didn't start capping (upper-bounding) the limits requested from OS (i beleive since 1.2.0.x agesa). The simple workaround is to set them to maximum values in advance (in BIOS) which is the possible source of instability or performance deficit as a result of a user changed infrastructure limits post-calibration.
The other way is somehow up the SMN trust level derived from the originating IP, so that SMU requests (routed through SMN) are considered trusted by PSP.
Asrock seems not to follow strict recomendations and except Max Boost Frequency, all limits are unlocked. Unfortunately this doesn't seem to be the case with other vendor's firmware, which makes profiles of little use.


----------



## Luggage

KedarWolf said:


> What test and settings you use in OCCT?
> 
> I ran it overnight a few days ago using the latest Beta, no errors.
> 
> Running it again today
> 
> 
> Had to lower three cores by 1 point.
> 
> Here is my new for OCCT.
> 
> View attachment 2563194


The stability certificate test, gold 6h - didn’t have time for 12h platinum test.
Bought a license before he started with the patron support…


----------



## ManniX-ITA

Luggage said:


> The stability certificate test, gold 6h - didn’t have time for 12h platinum test.
> Bought a license before he started with the patron support…


Did the CPU tonight:









Cpu Gold stability certificate - 6/8/2022 5:02:35 AM - ManniX


This is a very thorough 6h stability test : 1h CPU Large Extreme, 1h CPU Large, 1h CPU Medium, 1h Small Extreme, 1h Linpack v2021, 1h CPU Large ( 1 thread, cycling )




www.ocbase.com





No errors.
But after weeks of apparent stability this dummy 5950X B2 last week rebooted at idle with a double WHEA 18 on Core 0 and 14.
Reduced by 2 the counts for those cores.


----------



## KedarWolf

ManniX-ITA said:


> Did the CPU tonight:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Cpu Gold stability certificate - 6/8/2022 5:02:35 AM - ManniX
> 
> 
> This is a very thorough 6h stability test : 1h CPU Large Extreme, 1h CPU Large, 1h CPU Medium, 1h Small Extreme, 1h Linpack v2021, 1h CPU Large ( 1 thread, cycling )
> 
> 
> 
> 
> www.ocbase.com
> 
> 
> 
> 
> 
> No errors.
> But after weeks of apparent stability this dummy 5950X B2 last week rebooted at idle with a double WHEA 18 on Core 0 and 14.
> Reduced by 2 the counts for those cores.


I passed the Gold Certification and I let Platinum run overnight while I slept. When I left for work was on the Linpack 2 hour test and from my experience, if it gets that far, it'll pass.

I want to run the memory tests next though.

Edit: I had to lower the curve on several cores to get it to pass though. I'll share it when I get home.


----------



## KedarWolf




----------



## VPII

ManniX-ITA said:


> Good thinking don't update to anything above 1.2.0.3


If I may ask, why do you say this. I'm asing as on my MSI Mag X570 Ace I am using Agesa 1.2.0.7 without any issues, clock speeds good using PBO advance with CO set in bios for my 5950X, obviously mine not as great as those you get in the USA, but still not to bad as it would hover between 4.6 and 4.5ghz while running CB23, which I understand is not a true indication for real work load.


----------



## ManniX-ITA

VPII said:


> If I may ask, why do you say this. I'm asing as on my MSI Mag X570 Ace I am using Agesa 1.2.0.7 without any issues


As far as I know there's still the VID limit to 1.425V above 140A EDC.
It does hurt dramatically performances in MT (clocks are higher of course due to the low power).
Unless there's a specific reason (like the tFPM stuttering bug fix for Win11), better to run lower than 1.2.0.4.


----------



## KedarWolf

Six-hour memory test while I slept.


----------



## VPII

ManniX-ITA said:


> As far as I know there's still the VID limit to 1.425V above 140A EDC.
> It does hurt dramatically performances in MT (clocks are higher of course due to the low power).
> Unless there's a specific reason (like the tFPM stuttering bug fix for Win11), better to run lower than 1.2.0.4.


Well I'm busy getting to install WIndows 10 on another drive as I want to tes the benchmarks I run to see the difference, I am however struggling with stability it seems as my CO set in bios will work great and then on another restart it would fail running CB23.


----------



## CubanB

PJVol said:


> It would certainly make sense if mb vendors didn't start capping (upper-bounding) the limits requested from OS (i beleive since 1.2.0.x agesa). The simple workaround is to set them to maximum values in advance (in BIOS) which is the possible source of instability or performance deficit as a result of a user changed infrastructure limits post-calibration.
> The other way is somehow up the SMN trust level derived from the originating IP, so that SMU requests (routed through SMN) are considered trusted by PSP.
> Asrock seems not to follow strict recomendations and except Max Boost Frequency, all limits are unlocked. Unfortunately this doesn't seem to be the case with other vendor's firmware, which makes profiles of little use.


I wanted to wait a few days to reply, to get more experience with everything. I didn't want to keep bugging you about this tool, requesting too many things etc. But I've now spent the last few days finishing the CO curve, and have now used the tool for many hours.

With this MSI X570S Carbon Max board, like you said, I have to set max limits in BIOS and then reduce them in Windows. The only exceptions are the Temp limit, and also FIT Scalar (but I don't use that). So for Temp Limit, I can set it to 80C in the BIOS, and it will still let me go to 90C in windows. The rest of them I set in the BIOS. But I set 150EDC in BIOS, and lower it to 120EDC in Windows. If I set 120EDC in BIOS, the performance is poor. If I leave it at 150EDC after login and don't open PBO2 Tuner, performance is ok. But it improves a few hundred points in CB R20 for example, to lower it to 120EDC. This is with AGESA 1.2.0.3C. There is a further improvement after putting the computer to sleep and waking it up. It's strange, maybe it's a motherboard bug with voltages or something. I know it sounds random but these things are consistent and repeatable. In x264 FHD Benchmark after sleep.. it goes from 72-76fps to 86-92 fps. CB R20, 10750 to 11040. All of this with the same wattage readings from the wall meter (238W max). So far, I haven't had any instability. Only in OCCT, with WHEA core cache failure reboot, or calculation errors. These are fixed by adjusting the CO curve further. I can push max wattage higher but it starts to get hotter and is no longer quiet (Noctua air cooling). Max sustained effective clock 5020mhz core 1 in Cinebench R20 with SC 648. SC 690 in CPU-Z. Max SC voltage 1.444 (-0.0500 UV). Max temps in Cinebench.. SC 60C, AC 68C with 22C ambient.

When the PC goes to sleep and wakes up, after the login.. all of the PBO2 limits are reverted to BIOS settings. So I need to figure out a way to auto load PBO2 Tuner after every login, probably with Task Scheduler or Startup folder. If this is the last version of this tool, I'll try to figure out an AutoHotkey script to automate the input of the values. There is a way to move the window off screen, automatically use keyboard presses like tab and the numbers to input the values, and then close the window. One other idea I didn't mention before was that it could be useful to have the values stored in the input box, similar to the CO section. Instead of the blank box, and typing them out every time but it's only a small thing. Or even a command line option for PPT, TDC, EDC would be useful.

I plan to use this tool, similar to how others use Ryzen Master. If it's summer to change the Temp limit, or adjust the settings per workload. It's working really well so far, it's just a small pain to have to manually input the values after every login. Anything that makes that process easier or more efficient is a positive.

I didn't know of this tool until a week ago, and it's been the happiest surprise to find it, when optimizing this 5950X build. 16 cores is a lot of cores to optimize but the tool has helped shape the curve into a really accurate/efficient one. I started with -30 on every core, -1 after every error, and now in OCCT, I can run 60 mins AVX2 Variable Extreme Large and isolate every core without errors. No problems so far with all core workloads or idle reboots. No Infinity Fabric WHEA errors. It's a fantastic tool, I'm just happy to be able to adjust PBO2 while in Windows. It has helped create a very cool and quiet system but still faster than stock. Stock scores were a bit bad, I think L2 and L3 cache runs a little bit slower in Windows 7 compared to 10 or 11 or it could just be a bug with AIDA64. Best I can do with L3 is 14.3 ns. RAM is Micron Rev B 64GB @ 3800Mhz CL16 at 1.35V.


----------



## PJVol

CubanB said:


> If this is the last version of this tool


I was planning to add Curve control for the Cezanne CPUs, but got stuck in a vain effort to figure out the Fmaxboost control via mp1 or rsmu, hence no update. So I think, I save it for later then.
Will look into adding cli options for the pbo limits.



CubanB said:


> But it improves a few hundred points in CB R20 for example, to lower it to


CBR23 is much less sesitive to higher EDC.
With regards to some inconsistency after wake up, I'd stay away from the sleep mode, or better disable S3 wherever you see it.


----------



## Saiger0

@PJVol I was wondering if theres also a way to set custom PBO limits on start up using your amazong pbo2 tuner tool. Would putting them after the co vallues work?
like 'path-to-a-binary\PBO2 tuner.exe' 1 2 3 4 5 6 7 8 ppt tdc edc. Or would you have to fill out the others aswell like
path-to-a-binary\PBO2 tuner.exe' 1 2 3 4 5 6 7 8 ppt maxboost tdc templimit edc ?


----------



## PJVol

Saiger0 said:


> if theres also a way


 and @CubanB
you can try binary linked below.
Use the following arguments order
1 2 3 4 5 6 7 8 ppt tdc edc fmax
All four limits are required, use 0 to not override.
e.g. to set only EDC limit to 320A


Code:


'path-to-a-binary\PBO2 tuner.exe' 1 2 3 4 5 6 7 8 0 0 320 0'







Debug-cli.7z







drive.google.com


----------



## Saiger0

@PJVol Your awesome man it works!
I created a task triggered by user login with the following arguments "-30 -30 -30 -30 -30 -30 -30 -30 95 60 90 0" and it applied like charm on my 5800x3d.
Thank you.


----------



## 2080tiowner

Saiger0 said:


> @PJVol Your awesome man it works!
> I did a task triggered by user login with the following arguments "-30 -30 -30 -30 -30 -30 -30 -30 95 60 90 0" and it applied like charm on my 5800x3d.
> Thank you.


Just perfect, thanks !


----------



## KedarWolf

PJVol said:


> and @CubanB
> you can try binary linked below.
> Use the following arguments order
> 1 2 3 4 5 6 7 8 ppt tdc edc fmax
> All four limits are required, use 0 to not override.
> e.g. to set only EDC limit to 320A
> 
> 
> Code:
> 
> 
> 'path-to-a-binary\PBO2 tuner.exe' 1 2 3 4 5 6 7 8 0 0 320 0'
> 
> 
> 
> 
> 
> 
> 
> Debug-cli.7z
> 
> 
> 
> 
> 
> 
> 
> drive.google.com


Can we get it to set Temp Limit as well? I know I can set it in the BIOS but on my board, it never works when set in BIOS. 

Edit: And Scalar too. My board with it disabled in the CBS menu sets it to 1, I'd like to set it with PBO Tuner to 0.


----------



## ManniX-ITA

KedarWolf said:


> Edit: And Scalar too. My board with it disabled in the CBS menu sets it to 1, I'd like to set it with PBO Tuner to 0.


There's no Scalar 0, minimum value and default is 1.


----------



## KedarWolf

ManniX-ITA said:


> There's no Scalar 0, minimum value and default is 1.


Weird, PBO Tuner says it sets it to 0.


----------



## ManniX-ITA

KedarWolf said:


> Weird, PBO Tuner says it sets it to 0.


Zero is when it's not readable

Edit: you can get a reliable reading form HWInfo summary


----------



## TimeDrapery

ManniX-ITA said:


> Zero is when it's not readable
> 
> Edit: you can get a reliable reading form HWInfo summary


I dunno dude... Set it to 0 using the tool and monitor max clocks with a boost tester... I think @KedarWolf is correct


----------



## Saiger0

KedarWolf said:


> Weird, PBO Tuner says it sets it to 0.


Do you mean FIT scalar? Mine is set to 1 by default. I dont think theres a 0 scalar since you can´t really multiply 0, which probably means 0=1 in this case


----------



## ManniX-ITA

TimeDrapery said:


> I dunno dude... Set it to 0 using the tool and monitor max clocks with a boost tester... I think @KedarWolf is correct


Yeah you are right, interesting find 
Shouldn't be possible but it does it.

Also sets OC-Mode:









So beware of the reduced thermal protections.


----------



## ManniX-ITA

KedarWolf said:


> Weird, PBO Tuner says it sets it to 0.


Did you made some testing comparing to 1?


----------



## TimeDrapery

Saiger0 said:


> Do you mean FIT scalar? Mine is set to 1 by default. I dont think theres a 0 scalar since you can´t really multiply 0, which probably means 0=1 in this case
> View attachment 2563722


See @ManniX-ITA 's post dude... That's three people saying it's happening... All you gotta do is type 0 and press Set 😂😂😂😂😂


----------



## TimeDrapery

ManniX-ITA said:


> Yeah you are right, interesting find
> Shouldn't be possible but it does it.
> 
> Also sets OC-Mode:
> View attachment 2563723
> 
> 
> So beware of the reduced thermal protections.


Good look to see it triggers OC Mode... Too funny!


----------



## ManniX-ITA

TimeDrapery said:


> Good look to see it triggers OC Mode... Too funny!


Not really sure OC Mode is enabled for real...
Could be HWInfo is using the same method as all of us, checking if Scalar is zero.
I have to check with the Ryzen Master Monitoring SDK, it's the only way to be sure.


----------



## PJVol

ManniX-ITA said:


> Shouldn't be possible but it does it.


Come on, there should always be an Easter egg 



KedarWolf said:


> I'd like to set it with PBO Tuner to 0.


Idk... there supposed to be another way to pass defaults then. Need to think ...


----------



## ManniX-ITA

PJVol said:


> Come on, there should always be an easter egg


Ahah you are right


----------



## sp00n82

PJVol said:


> Idk... there supposed to be another way to pass defaults then. Need to think ...


Just named parameters like most other cli programs do?
E.g. xyz.exe -curve "-30 5 -20 -4 10 -23" -temp 90 -ppt 130 -edc 110 -tdc 90 -scalar 2 -boost 4900 etc


----------



## ManniX-ITA

PJVol said:


> Idk... there supposed to be another way to pass defaults then. Need to think ...


Did you look for a library?
Like this one (I haven't tested it):








GitHub - commandlineparser/commandline: The best C# command line parser that brings standardized *nix getopt style, for .NET. Includes F# support


The best C# command line parser that brings standardized *nix getopt style, for .NET. Includes F# support - GitHub - commandlineparser/commandline: The best C# command line parser that brings stan...




github.com







sp00n82 said:


> Just named parameters like most other cli programs do?
> E.g. xyz.exe -CO "-30 5 -20 -4-10 -23" -temp 90 -ppt 130 -edc 110 -tdc 90 -scalar 2 -boost 4900 etc


Double quotes in a shortcut are not good 
Better commas to separate the counts


----------



## imajescape

so i find the stable offset for each core on my 5600g and it passed corecycler on each core. but when i try to run the occt large data set it insta fails on core 4 (which is seemed one of the fastest cores with core 0 by ryzen master). while in occt it passed with CO -25, -30, -30, -19, -30, -30 both small data and large data set, i would still get random restarts from time to time while on low CPU load or when starting aida64 (didn't get restarts in games)

on corecycler core 4 passed with -25 in CO but insta fails in occt large data set( occt displays what core had the error so it was on physical core 4) . to pass in OCCT it needs minimum -19. anyone knows why does it pass in corecycler but insta fails in occt?


----------



## Luggage

imajescape said:


> so i find the stable offset for each core on my 5600g and it passed corecycler on each core. but when i try to run the occt large data set it insta fails on core 4 (which is seemed one of the fastest cores with core 0 by ryzen master). while in occt it passed with CO -25, -30, -30, -19, -30, -30 both small data and large data set, i would still get random restarts from time to time while on low CPU load or when starting aida64 (didn't get restarts in games)
> 
> on corecycler core 4 passed with -25 in CO but insta fails in occt large data set( occt displays what core had the error so it was on physical core 4) . to pass in OCCT it needs minimum -19. anyone knows why does it pass in corecycler but insta fails in occt?


What settings and how long did it pass corecycler?
Newest occt has been good at finding unstable co values, last update with the “stability certification (sic)” found two more for me that have been stable through a lot of other stress tests…


----------



## imajescape

Luggage said:


> What settings and how long did it pass corecycler?
> Newest occt has been good at finding unstable co values, last update with the “stability certification (sic)” found two more for me that have been stable through a lot of other stress tests…


multiple iterations passed on core 0 at -25
i need CO -25,-22,-30,-25,-25,-27 to pass corecycler
but with -25, -30, -30, -19, -30, -30 i pass OCCT without erros for 30 minutes the large data set/normal mode/variable/instructions set and threads on auto. but with this CO i get some random restarts from time to time while i don't get it in games or while running cinebench r23

so core 4 that can pass corecycler at -25 but needs minimum -19 for OCCT.

would had been happy with the -25, -30, -30, -19, -30, -30 CO , if not for random restarts that don't even happen while on cinebench r23 or gaming

what settings did you run occt?

btw. the ram OC is stable so it's not the RAM


----------



## Luggage

imajescape said:


> multiple iterations passed on core 0 at -25
> i need CO -25,-22,-30,-25,-25,-27 to pass corecycler
> but with -25, -30, -30, -19, -30, -30 i pass OCCT without erros for 30 minutes the large data set/normal mode/variable/instructions set and threads on auto. but with this CO i get some random restarts from time to time while i don't get it in games or while running cinebench r23
> 
> so core 4 that can pass corecycler at -25 but needs minimum -19 for OCCT.
> 
> would had been happy with the -25, -30, -30, -19, -30, -30 CO , if not for random restarts that don't even happen while on cinebench r23 or gaming
> 
> what settings did you run occt?
> 
> btw. the ram OC is stable so it's not the RAM


no - what settings in corecycler. only default? how many hours? or different fft sizes, y-cruncher kagari etc... do you pass y-cruncher stand alone with all tests enabled over nigh?
Just running the default settings is not very hard... 


http://imgur.com/a/ZMnaGHQ


In occt I ran the gold stability certification...


----------



## CubanB

PJVol said:


> I was planning to add Curve control for the Cezanne CPUs, but got stuck in a vain effort to figure out the Fmaxboost control via mp1 or rsmu, hence no update. So I think, I save it for later then.
> Will look into adding cli options for the pbo limits.
> 
> 
> CBR23 is much less sesitive to higher EDC.
> With regards to some inconsistency after wake up, I'd stay away from the sleep mode, or better disable S3 wherever you see it.


CLI options for PBO limits would be great. I will consider what you said about sleep modes and do some testing. In the past, I've always had problems with it and turned it off, but so far it's been ok.

I have to revise some of what I said in that last post in terms of scores or performance numbers.. because I hadn't tested with y-cruncher yet, and it's been kicking my ass. It's the hardest benchmark/stress test I've ever tested with.. and my curve has been changing a lot. I think I need two different BIOS profiles for two different curves. One for y-cruncher and one for everything else. The config file I've been using is considered a ram test, where the test length is 200 seconds instead of 120. Run forever. The 5 tests at the bottom of the list, starting with N32, N64 etc. 8 hours is the best I can do so far, but it's really inconsistent and random in terms of reboots. It can last for 2 hours, and then with the same settings a core will fail after 5 minutes. I guess I am nowhere near stable as I thought.

In terms of idle reboots.. I haven't had any.. but I did find some instability with an AutoHotkey loop script with CB R20. Someone on AMD's subbreddit shared it, and then you just have to adapt it to your screen resolution (to the pixel location of the run button). Basically.. opens an all core test, waits a few seconds, then ends the test. Waits a few seconds.. then starts a new all core test. Looping that for a few hours found new errors in going from idle to load and back to idle that other tests haven't found. It was usually the best cores with the highest freq that would error. People have mentioned Windows Update or leaving a browser window play with a YouTube video playing overnight.. or other things but so far this one has found the errors pretty quickly.

Y-cruncher has been tough, especially the wattage and temps of N64. But it has been said that if a system can pass y-cruncher it can pass anything. Just sharing these in case anyone sees things and it helps them. OCCT helped with core cycling and finding errors when a core is isolated and under 100% load, but there were some errors that it couldn't find. For extra all core errors under max load - y-cruncher. For errors under light/idle load.. the loop script.

All of this Core Optimizer stuff seems to be a matter of how stable you want something to be vs how patient you are.. because it could be easy to spend months on the fine tuning. The long road of going from 99% stable to 100% stable etc.


----------



## sp00n82

ManniX-ITA said:


> Double quotes in a shortcut are not good
> Better commas to separate the counts


I assume you need some sort of delimiter for the values, or the negative values might be interpreted as parameters themselves. You can always replace the double quotes by single quotes, e.g. if used in a shortcut. Or you could use some other character like [ and ] to enclose the curve values, but (double or single) quotes seem like the most obvious choice.


----------



## PJVol

sp00n82 said:


> I assume you need some sort of delimiter


Escaping symbols in powershell is sorta mess imho. Just figured out the "backtick" is used to escape double quote


----------



## ManniX-ITA

sp00n82 said:


> I assume you need some sort of delimiter for the values, or the negative values might be interpreted as parameters themselves. You can always replace the double quotes by single quotes, e.g. if used in a shortcut. Or you could use some other character like [ and ] to enclose the curve values, but (double or single) quotes seem like the most obvious choice.


It's just safer to avoid using the double quotes cause they are used to escape the executables with spaces in the pathname.
If you use them for the arguments sometimes are causing weird issues


----------



## sp00n82

PJVol said:


> Escaping symbols in powershell is sorta mess imho. Just figured out the "backtick" is used to escape double quote
> View attachment 2563977


Or just use single quotes. echo '"-1"'
Or vice versa: echo "'-1'"
That's what I meant @ManniX-ITA. You can always enclose double quotes in single quotes, or single quotes in double quotes. That's the default way for CLI programs.


One "fun" thing I came across when I tried to figure out how to start the stress test programs without stealing the focus, I eventually ended up using a VBA call to do so. And the escape character for double quotes in VBA is... another double quote!
This resulted in such fine lines as
[Microsoft.VisualBasic.Interaction]::Shell("""E:\_Overclock\CoreCycler\test_programs\p95\prime95.exe"" -t", 0)

Or even
[Microsoft.VisualBasic.Interaction]::Shell("cmd /C start /MIN ""y-Cruncher - 19-ZN2 ~ Kagari.exe"" ""E:\_Overclock\CoreCycler\test_programs\y-cruncher\Binaries\19-ZN2 ~ Kagari.exe"" priority:2 config ""E:\_Overclock\CoreCycler\test_programs\y-cruncher\Binaries\stressTest.cfg""", 0)
for Y-Cruncher. Good times.


----------



## ManniX-ITA

sp00n82 said:


> That's what I meant @ManniX-ITA. You can always enclose double quotes in single quotes, or single quotes in double quotes. That's the default way for CLI programs.


Yep I got it, there's always a way to escape it.
But for arguments it's still better to avoid it.
Windows itself can manage but very often is causing troubles with other tools/utilities.
Like a search tool (similar to Everything or Stardock stuff), startup/task management tools, etc


----------



## ronindj68

Ciao,
On my 5950x on DARK CROSSHAIR HERO I am trying the PBO TUNER tool to find the best Curve Optimizer
I am using PPT 220 TDC 140 EDC 140 with BOOST OVERDRIVE at + 200Mhz
SOC Voltage 1.1Volt
My best core seems to be CORE 0 and CORE 2
The best optimizer curves I got were:
-18 -30 -25 -30 -30 -29 -30 -29 -30 -19 -30 -25 -27 -12 -13 -19
The maximum score obtained in Multi Core is 29599
Also i can see that there are some cores that stay below of 5000Mhz like cores 8 10 13 14 and 15
What can i do to try best their performance ? Have i to sustain SOC voltage ? more than 1.1v ?
What am I doing wrong ?
Boostester and PBO2Tuner are fantastic tools

Regards
Gabriele (italy)


----------



## Andi64

Great tool. I've been testing for days now. It's stable on prime95 SSE Moderate, Heavy and HeavyShort for ~18Hs each. Testing AVX now, it already passed Moderate and HeavyShort. I'll consider everything stable once it finishes SSE, AVX, AVX2 on Moderate, Heavy, HeavyShort, and one night of YCruncher and AIDA64.

5900X results so far:
CCD1: -30, -27, -24, -21, -21 -15
CCD2: -30, -30, -27, -30, -30, -21

Boost +50Mhz

CB23 scores 22850

I'm not sure about PBO2 limits. It's currently set to PPT 210W, TDC 135A, EDC 170A, Fit Scalar 1, Temp Limit 90°C, Max Boost 5000Mhz.

I've noticed that it was actually limited by EDC at 155A, so I raised it to 170A. Then TDC was a limit at 115A. Now it hits 128A TDC, and 204W PPT. The limit is once again EDC that goes up to 170A. Temperature raised significantly to 82°C in CB23 (360mm AIO).

Should I change PBO2 limits? It raises temperature and power consumption but it only scores a little bit more in CB23.

I had a 5800X that I replaced with this 5900X. The 5800X did 1900Mhz FCLK no issues, but I tried 3 different 5900X CPUs and all of them refuse to POST at 1900Mhz. So I had to revert back to 1866Mhz (same as my old 3800X). Is there any way to get 1900Mhz back or it's just CPU dependent? It won't even POST at 1900Mhz, but it boots fine at 1933Mhz, but gives me lot's of WHEA errors (2x16GB GSkill TridentZ Neo C16-16-16 Samsung B Die).


----------



## KedarWolf

Andi64 said:


> Great tool. I've been testing for days now. It's stable on prime95 SSE Moderate, Heavy and HeavyShort for ~18Hs each. Testing AVX now, it already passed Moderate and HeavyShort. I'll consider everything stable once it finishes SSE, AVX, AVX2 on Moderate, Heavy, HeavyShort, and one night of YCruncher and AIDA64.
> 
> 5900X results so far:
> CCD1: -30, -27, -24, -21, -21 -15
> CCD2: -30, -30, -27, -30, -30, -21
> 
> Boost +50Mhz
> 
> CB23 scores 22850
> 
> I'm not sure about PBO2 limits. It's currently set to PPT 210W, TDC 135A, EDC 170A, Fit Scalar 1, Temp Limit 90°C, Max Boost 5000Mhz.
> 
> I've noticed that it was actually limited by EDC at 155A, so I raised it to 170A. Then TDC was a limit at 115A. Now it hits 128A TDC, and 204W PPT. The limit is once again EDC that goes up to 170A. Temperature raised significantly to 82°C in CB23 (360mm AIO).
> 
> Should I change PBO2 limits? It raises temperature and power consumption but it only scores a little bit more in CB23.
> 
> I had a 5800X that I replaced with this 5900X. The 5800X did 1900Mhz FCLK no issues, but I tried 3 different 5900X CPUs and all of them refuse to POST at 1900Mhz. So I had to revert back to 1866Mhz (same as my old 3800X). Is there any way to get 1900Mhz back or it's just CPU dependent? It won't even POST at 1900Mhz, but it boots fine at 1933Mhz, but gives me lot's of WHEA errors (2x16GB GSkill TridentZ Neo C16-16-16 Samsung B Die).


Manually set Core Cycler to 720-720 FFTs SSE, it'll find errors Heavy and HeavyShort etc. will miss.


----------



## Andi64

KedarWolf said:


> Manually set Core Cycler to 720-720 FFTs SSE, it'll find errors Heavy and HeavyShort etc. will miss.


Thanks! It was unstable on 6 cores! Dropped them down and it's now testing. 3 of them already passed 8 iterations. I'll let it run for 12hs more until none of them fail.

Should I also test AVX, AVX2, YCruncher and AIDA?


----------



## Luggage

Andi64 said:


> Thanks! It was unstable on 6 cores! Dropped them down and it's now testing. 3 of them already passed 8 iterations. I'll let it run for 12hs more until none of them fail.
> 
> Should I also test AVX, AVX2, YCruncher and AIDA?


At least ycruncher kagari is a good test.


----------



## ManniX-ITA

Andi64 said:


> Should I also test AVX, AVX2, YCruncher and AIDA?


Preferably everything.
If I recall 720K FFT doesn't work with AVX/AVX2 and CC P95, you need to use 768.


----------



## Andi64

Well, I guess it's stable enough. I'll let it run tests each night to be completely sure, but it passed so far:

Prime95 SSE HeavyShort: 15hs
Prime95 SSE Moderate: 11hs
Prime95 SSE Heavy: 17Hs
Prime95 AVX Heavyshort: 18hs
Prime95 AVX Moderate: 12hs
Prime95 SSE 720-720: 13hs
Prime95 AVX 768-768: 12hs
Prime95 AVX2 768-768: 22hs
Y-Cruncher Kagari: 8hs

CCD1: -30, -24, -21, -18, -21, -12
CCD2: -27, -30, -24, -30, -30, -18

I ended up lowering the PBO2 limits. It was consuming more power and giving me worse results on CB20/CB23.
PPT: 200W
TDC: 125A
EDC: 165A

Thanks for the help!

I now want to overclock the RAM, but find it hard to know where to start. It's at 3733MT/s C16, and it's Samsung B-Die, but it's nearly at stock speeds.


----------



## sp00n82

Andi64 said:


> Well, I guess it's stable enough. I'll let it run tests each night to be completely sure, but it passed so far:
> 
> Prime95 SSE HeavyShort: 15hs
> Prime95 SSE Moderate: 11hs
> Prime95 SSE Heavy: 17Hs
> Prime95 AVX Heavyshort: 18hs
> Prime95 AVX Moderate: 12hs
> Prime95 SSE 720-720: 13hs
> Prime95 AVX 768-768: 12hs
> Prime95 AVX2 768-768: 22hs
> Y-Cruncher Kagari: 8hs
> 
> CCD1: -30, -24, -21, -18, -21, -12
> CCD2: -27, -30, -24, -30, -30, -18
> 
> I ended up lowering the PBO2 limits. It was consuming more power and giving me worse results on CB20/CB23.
> PPT: 200W
> TDC: 125A
> EDC: 165A
> 
> Thanks for the help!
> 
> I now want to overclock the RAM, but find it hard to know where to start. It's at 3733MT/s C16, and it's Samsung B-Die, but it's nearly at stock speeds.


How long would you test an all-core overclock to consider it stable?
Now multiply this value by the number of cores you have to get the rough amount of time you need for about the same level of confidence.

And regarding RAM overclocking, since you have B-dies, the DRAM Calculator for Ryzen together with Thaiphoon Burner to read the default memory settings is a good starting point.
For testing use TestMem5 and/or Karhu (costs a bit of money, but found errors faster for me), and to see the current settings in Windows use ZenTimings.

Be aware that RAM overclocking can be even more time consuming than CPU overclocking, and many many many more restarts are required.
Also you shouldn't work on anything important while figuring out the stable settings.


----------



## Antonis_35

According to this MSI forum (MSI Global English Forum) MSI has started releasing Beta BIOS for selected AM4 motherboard models which include the Kombo Strike utility for the Ryzen 7 5800X3D, which enables overclocking and Core Offset Voltage. 
Google Drive Link which contains beta BIOS for various motherboard models (Kombo Strike Beta - Google Drive)


----------



## intelfx

Hi.
Beginner overclocker here.
What is the best set of settings for Curve Optimizer stability testing? Should I just iterate through all instruction sets and FFT sizes (i. e. SSE short, SSE medium, ..., AVX short, ...), or is there a recommended list of configs that would catch most of the problems?


----------



## sp00n82

In the beginning you want to see quick results, the default settings worked good for me (that's why I chose them), but some people here mentioned that SSE with an FFT size of 720 worked better for them (enter 720-720 for the FFT sizes to use just this size).
When the results become stable over multiple hours, it's time to switch things up and test with AVX & AVX2 and other FFT sizes.
The final stabilization tests should always be all the FFT sizes for each core, for each SSE, AVX & AVX2. For how long exactly depends on your wish for stability.


----------



## Luggage

I would start with running a coupe of hours of y-cruncher all tests, 1-7-0 before even starting with corecycler.


----------



## SneakySloth

I've found SSE/AVX2 128-128 to be really great at finding errors initially as well.


----------



## intelfx

sp00n82 said:


> In the beginning you want to see quick results, the default settings worked good for me (that's why I chose them), but some people here mentioned that SSE with an FFT size of 720 worked better for them (enter 720-720 for the FFT sizes to use just this size).
> When the results become stable over multiple hours, it's time to switch things up and test with AVX & AVX2 and other FFT sizes.
> The final stabilization tests should always be all the FFT sizes for each core, for each SSE, AVX & AVX2. For how long exactly depends on your wish for stability.


Thanks. I think I have my preliminary CO results (i. e. ones that are stable over multiple hours), so I'm mostly interested in the stabilization steps.

If I set FFTSizes = All, with 16 cores, what would be the approximate total runtime for 100% coverage (i. e. so that each core runs each FFT size at least once)?


----------



## sp00n82

This depends on the selected mode, for SSE there are less FFT sizes that will be tested than for AVX or AVX2, which has the most. Additionally, after the first full iteration, Prime95 starts to randomize the order of the FFT sizes, and can repeat a previously tested FFT size again before continuing to an untested one.
In the comments for the runtime setting I've given some example runtimes, which ranged from roughly 40 minutes to around 160 minutes for one full iteration for the "All" setting.

Although you should be able streamline this process by setting the FFTSize entry to All, runtimePerCore to auto and restartTestProgramForEachCore to 1, which should force Prime95 to always perform its "first iteration" on every core and therefore not repeat any FFT sizes, and so take roughly the same amount of time for each core.
It will still vary slightly depending on the clock speed though.


----------



## robocookie

PJVol said:


> @paih85 @Dijati et al )
> Can you try this binary:
> (it should accept CO values in command line. This is test version, so the main application window may appear before exit)
> Debug-CLI.7z
> 
> 
> Code:
> 
> 
> 'path-to-a-binary\PBO2 tuner.exe' 1 2 3 4 5 6 7 8 (for the 5800's)
> 
> Args number should be equal to the active cores count (i.e. 8 in case of 5800x3d)


If you could share the sourcecode so I could/we could implement a Run on Startup/Run on wakeup from sleep functionality would be awesome! Thanks for the tool!


----------



## Andi64

intelfx said:


> Hi.
> Beginner overclocker here.
> What is the best set of settings for Curve Optimizer stability testing? Should I just iterate through all instruction sets and FFT sizes (i. e. SSE short, SSE medium, ..., AVX short, ...), or is there a recommended list of configs that would catch most of the problems?


What I did was: set every core to -15. I only tested in increments of 3. Prime95 SSE 720-720 was the easiest way for me to find unstable cores.
I let it run during the night, and during the day when I was working. After 1 or 2 passes I upped the stable cores, and lowered the unstable ones.

At the end you'll have some cores at -30, and one or two (most of the time your preferred and good cores) with a much lower curve (-12 in my case). Once you know your max on each core you'll have to test for stability.

SSE 720-720
AVX 768-768
AVX2 768-768
YCruncher

It took me days. Every time a core fails, lower it and start over. In my case, if a core passed -24 with AVX 768-768 but failed with SSE, after I lowered it to -21 I didn't test it again with AVX, I'll consider it stable.

And then I did "heavy", "heavyshort" and "moderate". Just for good measure. The more you test the better.


----------



## CubanB

I still love the PBO2 Tuner tool, it's so great. Any extra functionality in the future would be highly welcomed, as it is it is already really good though.

In terms of Core Optimizer.. if you haven't OC'd your RAM yet.. beware because it will affect the curve. I've had a lot of testing over the last month and nearly everything affects the curve. For example.. PPT.. an unstable curve in Y-Cruncher can become stable.. if you lower the PPT by 10 (or some other number). Getting a core stable doesn't have to mean lowering the CO number. There are other options. Also, in heavy workloads sometimes one core will make another fail, making it hard to diagnose which core to adjust. Voltages, PPT and other factors can help stabilize that.

VDDP voltages had an effect on the stability of the curve that I wasn't expecting. I tested voltage for SOC, VDDP, VDDG CCD and IOD, each voltage step (within a certain range) looking for sweet spots. For example.. I initially had VDDP at 0.915V. After finding the sweet spots from a combination of tests like AIDA64, CPU spee tests etc.. I adjusted it to 0.950. Because the scores were highest and the consistency of the scores was better there. After the VDDP change.. the CO curve was suddenly more stable on my fastest core and I could bump the numbers up a little bit. SOC was mainly about trying to reduce temps and idle wattage (it worked fine at 1900 IF on nearly any voltage unless you go into the extremes). CCD was more about it's relationship/ratio to VDDP and also helped slightly with CO Curve. And IOD was mainly about it's relationship to SOC, didn't notice much CO curve benefit.. mainly IF stability.

It's been a very complicated process, a lot of compromises.. and there's no real one perfect way of doing it. Just whatever works for you. Whatever your use case is. Whatever your priority is.

The main point I'm trying to make is.. if you prioritize the CO curve, it will hurt your RAM OC (or timings) or stability. If you prioritize RAM OC, it will lower the CO. On my chip, in Y-Cruncher, it's even sensitive to tRDRDSCL and tWRWRSCL. I can get better gaming performance for example, if I have them looser.. because the curve/clocks can be higher. Some games just want higher clock speed. The read (RD) is especially sensitive. Bumping the RAM voltage up can help, if you want to keep them tight, but also pushes it out of the sweet spot (1.38V with my combo of stuff). You can try brute forcing it with more voltage for everything, but I've tried for a balanced power efficient system that is 24/7 stable in all workloads.

The main reason I'm typing this, is because I haven't seen voltages mentioned much. I've seen people talk about voltages in guides with the aim of RAM OC, tighter timings or higher fabric clock, but not in the context of a faster/higher CO curve.

I've seen videos where Buildzoid for example goes for extreme RAM OC, and doesn't even use CO because he says it's unstable. It can be stable.. but the RAM timings will be compromised. It's just a matter of what goal you are trying to achieve and adjusting everything around that goal. Cinebench likes clockspeed and more wattage. Y-Cruncher likes higher RAM freq.. but other programs or games can vary.

It's a lot of messing around, lots of pages of notes.. for the sake of fine tuning and learning etc.. some might even say it's a waste of time. But it has been fun to learn how Zen 3 works. I do like CO, it's a big plus compared to Zen 2 in my opinion. I like the low idle wattage. And with the right settings it can be 100% stable.. and highly optimized for speed.. it just takes a lot of work. But you can get 99% there within a few days or a week of testing if you already know what you are doing. I'm not saying any of these things are a guarentee.. maybe VDDP won't help for you.. just that it seemed to help in my case with this combo of 2 x 32GB Micron Rev B, B2 5950X and X570S Carbon Max.


----------



## intelfx

CubanB said:


> I still love the PBO2 Tuner tool, it's so great. Any extra functionality in the future would be highly welcomed, as it is it is already really good though.
> 
> In terms of Core Optimizer.. if you haven't OC'd your RAM yet.. beware because it will affect the curve. I've had a lot of testing over the last month and nearly everything affects the curve. For example.. PPT.. an unstable curve in Y-Cruncher can become stable.. if you lower the PPT by 10 (or some other number). Getting a core stable doesn't have to mean lowering the CO number. There are other options. Also, in heavy workloads sometimes one core will make another fail, making it hard to diagnose which core to adjust. Voltages, PPT and other factors can help stabilize that.
> 
> VDDP voltages had an effect on the stability of the curve that I wasn't expecting. I tested voltage for SOC, VDDP, VDDG CCD and IOD, each voltage step (within a certain range) looking for sweet spots. For example.. I initially had VDDP at 0.915V. After finding the sweet spots from a combination of tests like AIDA64, CPU spee tests etc.. I adjusted it to 0.950. Because the scores were highest and the consistency of the scores was better there. After the VDDP change.. the CO curve was suddenly more stable on my fastest core and I could bump the numbers up a little bit. SOC was mainly about trying to reduce temps and idle wattage (it worked fine at 1900 IF on nearly any voltage unless you go into the extremes). CCD was more about it's relationship/ratio to VDDP and also helped slightly with CO Curve. And IOD was mainly about it's relationship to SOC, didn't notice much CO curve benefit.. mainly IF stability.
> 
> It's been a very complicated process, a lot of compromises.. and there's no real one perfect way of doing it. Just whatever works for you. Whatever your use case is. Whatever your priority is.
> 
> The main point I'm trying to make is.. if you prioritize the CO curve, it will hurt your RAM OC (or timings) or stability. If you prioritize RAM OC, it will lower the CO. On my chip, in Y-Cruncher, it's even sensitive to tRDRDSCL and tWRWRSCL. I can get better gaming performance for example, if I have them looser.. because the curve/clocks can be higher. Some games just want higher clock speed. The read (RD) is especially sensitive. Bumping the RAM voltage up can help, if you want to keep them tight, but also pushes it out of the sweet spot (1.38V with my combo of stuff). You can try brute forcing it with more voltage for everything, but I've tried for a balanced power efficient system that is 24/7 stable in all workloads.
> 
> The main reason I'm typing this, is because I haven't seen voltages mentioned much. I've seen people talk about voltages in guides with the aim of RAM OC, tighter timings or higher fabric clock, but not in the context of a faster/higher CO curve.
> 
> I've seen videos where Buildzoid for example goes for extreme RAM OC, and doesn't even use CO because he says it's unstable. It can be stable.. but the RAM timings will be compromised. It's just a matter of what goal you are trying to achieve and adjusting everything around that goal. Cinebench likes clockspeed and more wattage. Y-Cruncher likes higher RAM freq.. but other programs or games can vary.
> 
> It's a lot of messing around, lots of pages of notes.. for the sake of fine tuning and learning etc.. some might even say it's a waste of time. But it has been fun to learn how Zen 3 works. I do like CO, it's a big plus compared to Zen 2 in my opinion. I like the low idle wattage. And with the right settings it can be 100% stable.. and highly optimized for speed.. it just takes a lot of work. But you can get 99% there within a few days or a week of testing if you already know what you are doing. I'm not saying any of these things are a guarentee.. maybe VDDP won't help for you.. just that it seemed to help in my case with this combo of 2 x 32GB Micron Rev B, B2 5950X and X570S Carbon Max.


Interesting, thanks for the insights.

The interaction between RAM OC and CPU tuning is indeed kinda significant for me, because I'm running 128GB of DDR4-3600 (4x32 Micron Rev. B) and it's been another pain point for this build.


----------



## Taraquin

CubanB said:


> I still love the PBO2 Tuner tool, it's so great. Any extra functionality in the future would be highly welcomed, as it is it is already really good though.
> 
> In terms of Core Optimizer.. if you haven't OC'd your RAM yet.. beware because it will affect the curve. I've had a lot of testing over the last month and nearly everything affects the curve. For example.. PPT.. an unstable curve in Y-Cruncher can become stable.. if you lower the PPT by 10 (or some other number). Getting a core stable doesn't have to mean lowering the CO number. There are other options. Also, in heavy workloads sometimes one core will make another fail, making it hard to diagnose which core to adjust. Voltages, PPT and other factors can help stabilize that.
> 
> VDDP voltages had an effect on the stability of the curve that I wasn't expecting. I tested voltage for SOC, VDDP, VDDG CCD and IOD, each voltage step (within a certain range) looking for sweet spots. For example.. I initially had VDDP at 0.915V. After finding the sweet spots from a combination of tests like AIDA64, CPU spee tests etc.. I adjusted it to 0.950. Because the scores were highest and the consistency of the scores was better there. After the VDDP change.. the CO curve was suddenly more stable on my fastest core and I could bump the numbers up a little bit. SOC was mainly about trying to reduce temps and idle wattage (it worked fine at 1900 IF on nearly any voltage unless you go into the extremes). CCD was more about it's relationship/ratio to VDDP and also helped slightly with CO Curve. And IOD was mainly about it's relationship to SOC, didn't notice much CO curve benefit.. mainly IF stability.
> 
> It's been a very complicated process, a lot of compromises.. and there's no real one perfect way of doing it. Just whatever works for you. Whatever your use case is. Whatever your priority is.
> 
> The main point I'm trying to make is.. if you prioritize the CO curve, it will hurt your RAM OC (or timings) or stability. If you prioritize RAM OC, it will lower the CO. On my chip, in Y-Cruncher, it's even sensitive to tRDRDSCL and tWRWRSCL. I can get better gaming performance for example, if I have them looser.. because the curve/clocks can be higher. Some games just want higher clock speed. The read (RD) is especially sensitive. Bumping the RAM voltage up can help, if you want to keep them tight, but also pushes it out of the sweet spot (1.38V with my combo of stuff). You can try brute forcing it with more voltage for everything, but I've tried for a balanced power efficient system that is 24/7 stable in all workloads.
> 
> The main reason I'm typing this, is because I haven't seen voltages mentioned much. I've seen people talk about voltages in guides with the aim of RAM OC, tighter timings or higher fabric clock, but not in the context of a faster/higher CO curve.
> 
> I've seen videos where Buildzoid for example goes for extreme RAM OC, and doesn't even use CO because he says it's unstable. It can be stable.. but the RAM timings will be compromised. It's just a matter of what goal you are trying to achieve and adjusting everything around that goal. Cinebench likes clockspeed and more wattage. Y-Cruncher likes higher RAM freq.. but other programs or games can vary.
> 
> It's a lot of messing around, lots of pages of notes.. for the sake of fine tuning and learning etc.. some might even say it's a waste of time. But it has been fun to learn how Zen 3 works. I do like CO, it's a big plus compared to Zen 2 in my opinion. I like the low idle wattage. And with the right settings it can be 100% stable.. and highly optimized for speed.. it just takes a lot of work. But you can get 99% there within a few days or a week of testing if you already know what you are doing. I'm not saying any of these things are a guarentee.. maybe VDDP won't help for you.. just that it seemed to help in my case with this combo of 2 x 32GB Micron Rev B, B2 5950X and X570S Carbon Max.


Good info, I agree with you. My priority when setting up a Zen 3 setup is first tuning ram (it can account for over 20% in some games when CPU bound, on avg typically 15-20% if tuned B-die (5% lower if Micron E\B or Hynix C\D) at 3800 vs 3200 xmp), making it 100% stable, finding baseline voltages that work fine, then work out your CO+PBO (up to 5-6% in games and apps if lucky with binning) and lastly try reducing voltages if possible to bring down temp\consumption even more.


----------



## PJVol

CubanB said:


> I've had a lot of testing over the last month and nearly everything affects the curve.


You should bear in mind that most of what you called "everything" here, could actually have nothing to do with CO stability. Instead the issues most likely come from the temperature variance at boot time leading to a different training "reference points" (derived from the PSM v/t measurements and/or core's Cac weights), used in boosting algorithms.
Add to it "on-the-edge" curve preset and you thus easily have a scenario when a 1-2°C difference at the BTC will ruin CPU stability.
Let's say you've changed something elsewhere altering the total power budget or some other metric, involved in a target boost frequency calculation, and having little or no direct relation to the CO at all. However, this I think can potentially expose and engage unstable point on a virtual V/F/T-curve.

The key thing to remember is that changing CPU boost state machine parameters (PBO2) runtime and boottime not necessarily the same (in fact more likely not)


----------



## CubanB

intelfx said:


> Interesting, thanks for the insights.
> 
> The interaction between RAM OC and CPU tuning is indeed kinda significant for me, because I'm running 128GB of DDR4-3600 (4x32 Micron Rev. B) and it's been another pain point for this build.


I'm sort of in a similar situation. I do have 2 sticks in now, but have planned on using another 2 in the future. I'm just trying to learn how to optimize 2 first since it's easy mode and I'm trying to find where the peak speeds or effeciency is. And 4 sticks do stress the memory controller a lot harder and require a lot of loosening of timings etc.

In the last few days I've been testing RAM timings and the curve relationship a bit more. tRP from 18 to 20 (at 3800Mhz) was the difference between Y-Cruncher CPU test (all 9 tests 120 seconds looped) running for 10 mins - 2 hours.. to running for 12 hours straight. This is with a higher CO Curve than I had a week ago. I've also been playing around with SCL's and also tFAW and tRRDS and tRRDL. Loosening some, tightening others and trying to find where it goes wrong in Y-Cruncher (without changing the curve). I'm trying to make 2 profiles.. one for encoding (aloways stable not matter what) and one for gaming (higher boost, less stability). After these RAM tweaks my encoding profile is now faster in CB R20 than the gaming one I had a week ago. It's just very time consuming and requires a lot of patience and experimenting. If I've repeated myself from some of what I said in that original post, apologies it was late at night and I can't even remember what I typed.


----------



## CubanB

PJVol said:


> You should bear in mind that most of what you called "everything" here, could actually have nothing to do with CO stability. Instead the issues most likely come from the temperature variance at boot time leading to a different training "reference points" (derived from the PSM v/t measurements and/or core's Cac weights), used in boosting algorithms.
> Add to it "on-the-edge" curve preset and you thus easily have a scenario when a 1-2°C difference at the BTC will ruin CPU stability.
> Let's say you've changed something elsewhere altering the total power budget or some other metric, involved in a target boost frequency calculation, and having little or no direct relation to the CO at all. However, this I think can potentially expose and engage unstable point on a virtual V/F/T-curve.
> 
> The key thing to remember is that changing CPU boost state machine parameters (PBO2) runtime and boottime not necessarily the same (in fact more likely not)


Thanks, good info there. I have noticed some of what you talked about. Where it feels like the CPU can have a different personality, that changes from one reboot to another. Where it boosts higher or is more stable even though nothing has changed in BIOS. It would make sense if there's timings/training that we can't control that are being changed. I've also noticed that changing something like PPT or the CO curve in Windows and changing in the BIOS can have different behavior or results. Before any long stress test, I've made sure to make the changes in the BIOS and change nothing in Windows. When I change PPT, I only lower it to reduce temps/power consumption for different tasks. But for my stress tests, I'm running max PPT without changing it. I don't change CO Curve via Windows anymore, but initially for core cycling and building an initial curve, it's a great time saver.

There's something else I haven't mentioned that might be a factor, I have a weird core 0. I haven't posted about it anywhere because my posts are long enough as it is. But when the CPU was new.. any WHEA error/restart would be one core only. It made the initial curve easy to create with OCCT, core cycling etc. But after a while.. especially in Y-Cruncher.. I started getting two cores failing at the same time. Core 0 + 1 (fastest core), or especially.. core 0 + any core on second CCD. It's those core 0 + second CCD errors that VDDP voltages and RAM timings have been helping with. I changed tRP from 18 to 20 a few days ago, and they all went away. After that, it would only be core 0 + 1 (fastest core). When I tighten other RAM timings.. the second CCD errors come back (even with tRP at 20). I haven't been changing the curve at all in the last few days. Just testing Y-Cruncher stability with RAM timings and trying to measure which are fastest, vs which help stability. The reason I tried this, was because my curve was starting to become really low/slow and it didn't seem right. A few nights ago I reached 12 hours straight of Y-Cruncher when I stopped it (it could probably do 24 hours), and I wouldn't have thought this possible 2 weeks ago before I discovered this. Lowering the curve wasn't working, everything was just getting slower without extra stability.

Core 0 has always been a strange core. It uses low voltage compared to the others, and doesn't get very hot. It's not fastest or slowest, it's just average. I could run it at -30 for the first week or two in OCCT (passed all core cycling tests), but after Y-Cruncher testing it dropped all the way to -16 to -20 in order to be stable in intense all core stability tests. With bad settings it will fail in 12-13 minutes. I was worried it was degrading or bad but it's been stable for the last 2 weeks, despite a lot of intense testing. But there's a strange relationship that it has with second CCD and RAM speeds/timings. There are a couple of Y-Cruncher stress tests like N32, N64, HNT that really punish it hard and expose a WHEA (Core 0 + Core 8 to 15). Otherwise everything is pretty easy to understand and consistent. Core 0 is also right beside the fastest core.. and I noticed the relationship between them improved stability. Currently -18 (Core 0) and -20 (Core 1). -20 and -22 also works ok. I'm pretty sure that this is very unusual, that the fastest core isn't the one with the lowest CO. On the 2nd CCD, everything is normal. Fastest cores -20, slowest cores -26 to -30.

Maybe this is just a strange chip, it's hard to say because it's the first Zen 3 I've ever tested. Everything else about the chip has been really good and easy to work with, especially the IF. I'm not sure if it's temperature related, it seems there's something sensitive about core 0 communicating with both CCD's combined with IO die and RAM. It only shows up in 100% load extreme stability tests.. nothing in regular Windows use, 7z, Cinebench or games etc. Also.. it's been over a month and have still never had an idle WHEA/reboot. I'm very happy with the chip, all of this is just for learning and fine tuning. I'm happy to share my strange experiences, if it helps someone else who reads it.


----------



## sp00n82

CubanB said:


> I'm sort of in a similar situation. I do have 2 sticks in now, but have planned on using another 2 in the future. I'm just trying to learn how to optimize 2 first since it's easy mode and I'm trying to find where the peak speeds or effeciency is.  And 4 sticks do stress the memory controller a lot harder and require a lot of loosening of timings etc.


Yeah, trying to overclock 4 double sided RAM modules is horrible. I have 4x16GB Samsung B-dies that are originally specced for 3200 MT/s and they run not anywhere near as fast as with only 2 sticks. I couldn't even get 3733 MT/s to boot reliably, I've just reduced it to 3600 after a while because I was too tired of changing the settings around and around and around.
With 2 sticks I could go up to 3800 MT/s without much a problem (haven't really tried much higher than that), but 4 sticks just seem to put too much stress on the IMC.

4 sticks with single sided RAM should work just fine though, it's just 4x double sided that is a huge PITA (and all Samsung B-dies are double sided with 16GB per stick).


----------



## CubanB

sp00n82 said:


> Yeah, trying to overclock 4 double sided RAM modules is horrible. I have 4x16GB Samsung B-dies that are originally specced for 3200 MT/s and they run not anywhere near as fast as with only 2 sticks. I couldn't even get 3733 MT/s to boot reliably, I've just reduced it to 3600 after a while because I was too tired of changing the settings around and around and around.
> With 2 sticks I could go up to 3800 MT/s without much a problem (haven't really tried much higher than that), but 4 sticks just seem to put too much stress on the IMC.
> 
> 4 sticks with single sided RAM should work just fine though, it's just 4x double sided that is a huge PITA (and all Samsung B-dies are double sided with 16GB per stick).


Yeah, that's what I was thinking. Around 3600Mhz seems to be the limit from what I've read around the place. So it's a question of 3800Mhz-4000Mhz at 64GB vs 3600Mhz 128GB. And the choice comes down to.. what is your main use case.. because if it's gaming, 64GB is already plenty. On my set, I can go to 3933Mhz without problem but stuck with 3800Mhz just for stability and more tightening of timings. I like how low the idle voltage is with lower SOC voltage etc. But if the extra RAM is required, it's going to be hard without sacrificing some gaming/latency. It's just a question of what one's priorities are. 3600Mhz is still decent though, but you really want to be using that RAM regularly to justify it. I assume in your case that this is true.


----------



## CubanB

I know this isn't the RAM OC thread, but I wanted to share some things I've discovered in terms of stabilizing my CO curve via voltages and RAM. I have a handwritten notepad with 20-30 pages of notes and scores etc, but wanted to share some of what I have discovered in case it can help anyone else. I'm pretty much finished with this process now on this chip.

My initial curve when trying to stabilize Y-Cruncher stress test after a month of testing was..

(CCD0) -18 -20 -30 -30 -22 -30 -28 -28 (CCD1) -22 -28 -26 -22 -28 -28 -28 -26

I redid the curve from scratch core cycling all over again with the new voltages and RAM timings that I've learned and talked about here CoreCycler - tool for testing Curve Optimizer settings

The new curve is..

(CCD0) -20 -22 -30 -30 -26 -30 -30 -30 (CCD1) -26 -28 -28 -24 -30 -30 -30 -26

Early on I reduced cores by -1 but over time, doing it in even numbers was preferred. The difference between -21 and -20 is very small and I don't mind having that small bit of extra headroom.

I haven't had any WHEA errors or restarts since changing to this new curve, despite intense testing. So for now this is my final curve. I had one calculation error with Y-Cruncher N32 after 8 hours, and one freeze after 5+ hours that I can only link to general RAM instability. There was no BSOD or WHEA in the logs. Otherwise it's running good. The one thing to note.. is that the first curve was *all* 9 Y-Cruncher tests and the second curve is all Y-Cruncher tests except *N64*. Because N64 is a test that in my opinion is an unrealistic workload. I have two profiles.. one N64 stable and one without N64, and the latter will be the main 24/7 profile. It's 14 hours stable in Y-Cruncher but I'm pretty sure it's 24 hours stable, I've just never let the test run that long.

I played around a lot with RAM timings in the last few days after I found that second curve is the most stable I've had so far. It's now about fine tuning aimed at higher FPS in gaming situations at 1080p, and also for those old school programs that don't use multi cores properly. Stuff like MP3 encoding, FLAC encoding etc. The stuff that Intel is usually good at because the clock speed/latency advantage they have had over the years. The tests I used were 3D Mark Firestrike, Unigine Valley and Superposition, Lost Planet 2 Benchmark, x264 FHD Benchmark, CPU-Z SC and AC, AIDA64, and CB R20. And PC Mark in terms of testing things like app launch speeds, and general office/PC use. Trying to find the patterns in what settings favor certain settings what timings increase instability.

I found that with the tightest RAM timings that made AIDA64 screenshots look better.. some scores would suffer. And pushing the RAM even tighter would cause instability. Loosening them would help these things but hurt all core performance like Y-Cruncher 2.5B, 7-Zip benchmark etc. But it would help these other light load applications or games. There is no one right way tune them, but just what your priority is.

5950X B2
X570S Carbon Max
Micron Rev B 2 X 32GB @ 3800Mhz @ 1.38V
Primary timings as shown in AIDA64 - 16-18-20-28 (CR1) GDM On

Voltages -
VCORE -0.0500 (offset undervolt with medium to low LLC setting)
VSOC 1.0250 (Auto LLC that increases to 1.0300ish under load)
VDDP 0.950 (0.9474 in ZenTimings)
VDDG CCD 0.960 (0.9592 in ZenTimings)
VDDG IOD 1.010 (1.094 in ZenTimings)
ProcODT 30 ohm (I had it at 32, but reducing it to 30 added further stability without needing 1.39V)

These were the voltages that helped stabilize my curve and allowed me to retest it and increase the numbers a little. In terms of RAM timings, the ones I focussed on were tRP, tRDRDSCL and tWRWRSCL and TRRD_S and TRRD_L.

I see in the screenshots and RAM OC guides that a lot of people like to use tRDRDSCL and tWRWRSCL at 2 2, 3 3 or 4 4 and these numbers improve AIDA64 scores but I found the best performance with 4 3 or 5 4. The write being the lower number. It could be different with Samsung B die or Hynix, I'm specifically talking about Micron Rev B. Increasing these could help but it also requires a lot of extra voltage and I wanted to stay at 1.38V.

With some of these timings loosened, stability was improved but performance in games also went up. I don't know if it's because of less load on IMC, inter CCD communication, less power budget.. it's hard to say. I can just say.. it's slightly better in terms of higher fps low, avg and highs. Or even CPU-Z SC and AC speeds it seems to get consistently better results with the right combination of them. Unigine Valley is the most clear cut case that was consistent every time. I change affinity to the two fastest cores manually, and record the averages after 3 runs and sometimes the lower RAM speeds in AIDA64 were faster in games (with the right combination of timings).

With tRDRDSCL and tWRWRSCL at 4 3, it was stable with tRP at both 18 or 20. But it was slightly faster with the looser setting of 20. The reason it wasn't 3 3, it because for some reason read speeds wouldn't increase. So it was less stability with no performance benefit. The difference between tWRWRSCL at 3 instead of 4 was 400-500mb more write speed. AIDA64 write speed scores with 4 = 56900 to 57100MB/s and with 3 = 57400 to 57500Mb/s.

With tRDRDSCL and tWRWRSCL at 5 4, tRP 18 was the only choice. The gaming/clock boost scores were almost as good, everything was just a tad slower. The only reason to use tRP 20 is for Y-Cruncher N64 stability, if that is a priority.

The main one I wanted to talk about was TRRD_S and TRRD_L. I've been running these at 7 7, and it really seems to improve gaming/fps/clock boost. I've seen guides say 6 6 is safe, and 4 6 is tight etc. My initial curve had it at 4 6 based on the RAM guides and very little testing. Trying 7 7 worked better.. even for x264 FHD Benchmark with 1-2 extra fps. It's hard to describe what is happening.. other than having it tight seems to increase the load on the CPU that improves benchmark scores in terms of AIDA64, but seems to negatively affect gaming performance or boost speeds. 6 6 worked good too, but 7 7 seems to be consistently better. The reduction in speed is 50-100mb/s in AIDA read, write and copy. I've noticed that copy speeds don't really matter much for gaming, or at least in the stuff I tested with.

I can't say any of this will work for anyone else but in the last few days.. it has been a case of starting with TRRD_S and TRRD_L 7 7 and then tightening other timings to get some speed back with other timings. Increasing read, write or copy speeds in AIDA without losing the fps boost in X264 FHD Benchmark and in older games. The latency doesn't change with these settings, it's always either 56.7 or 56.8ns.

My fastest setup that's also super stable is tRP18 or 20, tRDRDSCL and tWRWRSCL at 4 3, and TRRD_S and TRRD_L at 7 7.

With the first curve I posted and the tightest RAM timings, in CPU-Z the average SC score was 676-678, and with all of these new settings.. 680-684.6. All core speed is about 50-70 points higher. At 170W PPT, my all core for CPU-Z is 13020 when cold.. or 12950 after a few runs. 22C ambient but even at 26C ambient, the scores don't change much.

If you're gaming at 4K, all of this is pretty insignificant. If you care about memory intensive applications like Y-Cruncher 2.5B score, or 7-Zip all core performance.. other settings will probably work better. But these settings work good for old school low thread applications, Adobe Photoshop, MP3 encoding type stuff. The stuff that usually favors Intel or rewards higher frequency. And it also has the benefit of extra stability for everything outside of Y-Cruncher N64. It's only small improvements, a few fps here or there. A little bit higher boost here or there. But I also noticed in physics intensive graphics.. that are CPU limited.. it seems a little less stuttery.. even at the similar FPS as a tighter RAM setting. This is a hard thing to prove, but the graphics just seem to flow a little smoother with less micro stutters.

Running the RAM super tight on everything (which is possible if you increase VDIMM voltage or don't care about instability) gives better memory test scores but I don't know if there's internal CPU error correction going on.. or if it's just more power budget on the IO die.. I don't really know. But performance suffers unless it's a memory intensive application that cares a lot more about RAM. I know that there are some modern games that are like this and they would probably prefer tighter RAM timings. For a manual all core OC, or optimizing memory intensive apps.. it would require a completely different approach. Tighter timings, higher RAM voltage, lower curve numbers etc.

I just thought I would share this in case it helps anyone else. I would recommend building an initial curve. Try to fine tune voltages into their sweet spots, where the setting will either have faster scores or more consistency between runs.. and then fine tune the RAM. Then try to retune the curve again, it's possible that you might find slightly better results the second time. VDDP helped the most in my case. I initially had it at 0.9150V based on someone else's screenshot and with my setup, the CO curve suffered. I will be testing all of this on a second 5950X in the near future. This first one took 5 weeks.. I'm hoping the second one takes 1-2 weeks. I will test it using the same motherboard and voltages as a starting point and it will be fun to see where the differences are.


----------



## heptilion

CubanB said:


> 5950X B2
> X570S Carbon Max
> Micron Rev B 2 X 32GB @ 3800Mhz @ 1.38V
> Primary timings as shown in AIDA64 - 16-18-20-28 (CR1) GDM On
> 
> Voltages -
> VCORE -0.0500 (offset undervolt with medium to low LLC setting)
> VSOC 1.0250 (Auto LLC that increases to 1.0300ish under load)
> VDDP 0.950 (0.9474 in ZenTimings)
> VDDG CCD 0.960 (0.9592 in ZenTimings)
> VDDG IOD 1.010 (1.094 in ZenTimings)
> ProcODT 30 ohm (I had it at 32, but reducing it to 30 added further stability without needing 1.39V)


What was your VDD18/PLL voltage?


----------



## jvidia

From where can I download PBO2 Tuner? 

Thanks!


----------



## CubanB

heptilion said:


> What was your VDD18/PLL voltage?


Is that the 1.8V one? I've left that at stock, I've never actually experimented with it. Stock for this board is 1.800 in BIOS, showing as 1.802-1.804 in HWMonitor. I would expect that increasing it slightly would improve stability, I did read some people say that.. I was just never desperate enough to try it.. because my settings are based around as low voltages/temps as possible for lower idle watts or less temps at full load etc. Idle from the wall meter is 54-56W, which was a nice surprise for a 16 core chip. It will increase when other drives are added but yeah.


----------



## CubanB

I'll try to keep it short but I just wanted to add some more thoughts on the fine tuning I've done in the last week. I don't think the settings themselves matter that much, they might vary for people and their setups. But just to encourage people that if you keep fine tuning the relationship between the curve and certain RAM timings, it can sometimes pay off. Even though it's small gains.

I now have 3 profiles that are very stable.

A gaming one, with the highest benchmark scores that is stable with Y-Cruncher stability tests (all 9 tests minus N64 for 12 hours +). The fastest cores on first CCD are -18, -20 and -26.

An encoding one that is stable for all 9 Y-Cruncher tests (all 9 tests including N64 for 10 hours +). The fastest cores are -18, -20 and -24. This one is aimed for X264 type encoding.

And an encoding "super stable" one that is stable with N64 for 16 hours +. The fastest cores are -16, -18 and -24.

The N64 stability was a nice surprise, because in the first few weeks, N64 stability seemed impossible without a really bad curve that was much lower compared to OCCT core cycling curve. The main benefit of the gaming profile is if you have an older game, you can pin the affinity on the fastest cores and eek out some more fps, 10 more fps max or 2 more fps in 1% low etc. I prefer Unigine tests for this, but if there was a specific esports game you play like CS:GO, that would probably work better. Otherwise, the benefits for the encoding profiles is just knowing that you are never going to crash and still have nearly the same performance in all core loads. The difference from the gaming one to the slowest is 100 points in CPU-Z all core test. 12980 to 12880 for example at 170W PPT. Or 50-80 points less in CB R20 at 162W PPT. 100mb/s less in AIDA64 read, write, copy etc.

The difference in RAM timings between the three is small, but the gaming one has tRAS at 30. The others have tRAS at 32. The gaming one has tRRD_S at 4 and tRRD_L at 6, the encoding ones is 6 6. So it's small changes. If running tRAS at 28, TRRD's would be 7 7 but this is unstable for anything other than gaming. Any of these work, it's just a matter of what type of program are you targeting for higher performance.

Regardless of the specific settings, I would just generally recommend finding the settings that your CPU is sensitive to, depending on what your goal is. And trying different combinations of them. For me, I found the relationship between tRP, tRAS and tRRD and the SCL's to be important. For example, loosening tRP and then tightening tRRD_S and _L. Trying to keep tRAS as high as possible for gaming, but lowering it for encoding/RAM stability. Testing different combinations of these, finding both performance and stability with the right combinations of them. With the right combinations you can target RAM read, RAM write or RAM copy bandwidth. All of these settings above don't really affect latency. I tried increasing IF and RAM to 3866mhz with the same timings (except looser tRFC) and speeds actually got slower fps in games. It would require new voltages sweet spots to be found but wattage at idle wattage already went up by 5-10W so I stayed at 3800Mhz.

One other thing is that performance comparisons are so difficult when fine tuning. Replicating the conditions.. even with a temperature controlled room PBO2 seems so temperature sensitive, how long it sits for idle before running a test, the room will naturally heat up after testing for a while.. it can be so difficult and confusing to repeat results and have them consistent. You can have the same ambient temps and test at 8pm two days in a row with the same BIOS profile, and the scores will still be different. It's more about averages and trends. CPUs are so much like GPUs now. You will still be able to see trends,r for example a setting that gives you the highest score you've ever gotten, or the worst spike in 1% lows etc. Or one that is really inconsistent compared to another that is more consistent. Stability is easy to test overnight while sleeping but accurately measuring the performance gains are tough. It gets tedious near the end.. because each change barely makes a difference. And you can fool yourself by leaving it idle for a few extra mins and the score will be higher. Generally tighter timings are always faster and the rest is temperature variation and random PBO2 behavior. But in some things, a looser RAM timing and a higher CO Curve can be faster. Benchmate with including ZenTiming/PBO2 Tuner screenshots are really good because you can look back over the last week or two and see which way the scores are trending.

The reason I tested this so much, is because I want to stay on AM4 for a long time before switching to AM5 and need 100% stability for 24/7 use. Even if I get a WHEA or BSOD in a year from now, I want to know that I can fix it quickly. This kind of testing isn't for everybody, it's easy to lose patience.. but there can be small gains if you keep honing in. For performance alone it's not really worth it, but pinpointing the setting that affect stability in the program you care about can be useful. Or having a slightly higher curve that lowers idle power a little (if that's a priority). With Y-Cruncher N64, one timing (TRRD or tRP or TRAS in my case) can be the difference between 12 hours stability, or a restart after 5-10 mins. Generally speaking, I have found that if you're fastest cores are the ones causing the WHEA, the tight timings are contributing to it. If it's one of the slower cores (a -30 or -28 core).. its the curve for that core that probably needs lowering (but not always).

My current scores are within 1% of the fastest scores I've ever had, but also the most stable. Hopefully there is no degradation and it stays that way. In the first 2 weeks, there was a bit of degradation when testing with Y-Cruncher but it settled in.. and now even Y-Cruncher doesn't seem to degrade it. It's been pretty steady for the last few weeks and it doesn't feel like Y-Cruncher degrades it anymore. This is despite using 10W extra PPT, just to add more stress to it (headroom for summer, or dust etc). The chip now feels like a pair of shoes that has worn in a little bit. AMD did a really good job with these chips, it's just a bit more complicated than it used to be with the older manual OC method. Sorry for these lengthy posts.. there's just a lot of information in my brain after testing all of this over the last month or two. I just wanted to say that there is a lot of room to adjust things, it's like a cockpit with a lot of buttons.. but if you find the right ones.. good things can happen.


----------



## CubanB

PJVol said:


> and @CubanB
> you can try binary linked below.
> Use the following arguments order
> 1 2 3 4 5 6 7 8 ppt tdc edc fmax
> All four limits are required, use 0 to not override.
> e.g. to set only EDC limit to 320A
> 
> 
> Code:
> 
> 
> 'path-to-a-binary\PBO2 tuner.exe' 1 2 3 4 5 6 7 8 0 0 320 0'
> 
> 
> 
> 
> 
> 
> 
> Debug-cli.7z
> 
> 
> 
> 
> 
> 
> 
> drive.google.com


Sorry that I missed this post, I've been so hyper focused on testing and trying to get stability, that I missed it. Oops!

So happy to see that others have used it and have reported back success. It would have saved me so much time, because I have manually typed in values so many times I can't even count. Thanks for this, I don't need Ryzen Master, your tool is great. 

edit - Works great. Can create multiple profiles within Task Scheduler and enable/disable the preferred current one. I don't often use sleep and I have it set to never, but with this board I like to have it as an option to sleep it manually from Start Menu because it's given me 0 problems so far. Sometimes it helps to cool down the system quicker and reset to a baseline for temperature related testing.

I doubt many use sleep, but if they do.. to use this when waking from sleep, trigger with (multiple triggers)..

Event - System - Power-Troubleshooter - Event ID 1

Therefore it triggers when logging on, or also when waking from sleep. Works flawlessly, thanks for coding this valuable tool.


----------



## PJVol

CubanB said:


> I missed it


Glad you found it helpful, though I've made slight changes to the arguments format since then, and fixed some minor bugs. You can grab the binary from here (post #1,691):








5800X3D Owners


========================= UPDATE: fixed in Debug-CLI.7z this is the last version? is it recommend to use LLC (to negate vdrop)?




www.overclock.net


----------



## CubanB

PJVol said:


> Glad you found it helpful, though I've made slight changes to the arguments format since then, and fixed some minor bugs. You can grab the binary from here (post #1,691):
> 
> 
> 
> 
> 
> 
> 
> 
> 5800X3D Owners
> 
> 
> ========================= UPDATE: fixed in Debug-CLI.7z this is the last version? is it recommend to use LLC (to negate vdrop)?
> 
> 
> 
> 
> www.overclock.net


Yeah, it really is very helpful, especially on an older OS where Ryzen Master isn't an option. Great to see these further changes/improvements. My only small request would be to start using version numbers (1.01, 1.02 etc) or a changelog to keep track of the changes. It's only a small thing though. Thanks again.


----------



## Focus-_-

Greetings to all. I don't understand if everything is ok. My MB: MSI B450-A Pro Max (BIOS: 7B86vMF). 
So, I have a Ryzen 7 5700X. Cores 1 and 3 are the fastest. LLC = Auto. PBO enabled: PPT = 100W (def. 75W), TDC = 85A (def. 60), EDC = 115A (def. 90), Boost = Off, Scalar = Auto. For testing, I use Prime95 with SSE mode, FFTSize = Huge or Moderate, numberOfThreads = 2.
I don't understand why, but CoreCycler keeps showing errors on Core 1. This core failed any tests with a negative magnitude. When I used FFTSize = Huge, the script showed errors on Сore 1 even when magnitude = 0. And when I started testing on FFTSize = Moderate, the script started showing errors even when magnitude = +1 or +2. I decided to disable Curve Optimizer and ran the test: SSE, FFTSize = Moderate, numberOfThreads = 2. As a result, on the 2nd iteration, I got an error on Core 1.
Please explain what is wrong?

By the way, I also noticed that the combination of SSE + Moderate + 2 Threads started catching errors too well. Perhaps that's just the point.


----------



## Frosted racquet

Make sure you're using the latest version of CoreCycler. If a core throws an error during testing with Curve Optimiser values of 0 for all cores (not just for the Core 1) then the CPU is faulty, or rather the default Voltage/frequency curve is too aggressive.


----------



## jacklayton17

PJVol said:


> and @CubanB
> you can try binary linked below.
> Use the following arguments order
> 1 2 3 4 5 6 7 8 ppt tdc edc fmax
> All four limits are required, use 0 to not override.
> e.g. to set only EDC limit to 320A
> 
> 
> Code:
> 
> 
> 'path-to-a-binary\PBO2 tuner.exe' 1 2 3 4 5 6 7 8 0 0 320 0'
> 
> 
> 
> 
> 
> 
> 
> Debug-cli.7z
> 
> 
> 
> 
> 
> 
> 
> drive.google.com


Is it weird that my computer isnt recognizing this as a folder when I am trying to download it. So I can't access anything in the file

any suggestions?


----------



## Luggage

jacklayton17 said:


> Is it weird that my computer isnt recognizing this as a folder when I am trying to download it. So I can't access anything in the file
> 
> any suggestions?


7-zip


----------



## Audioboxer

One of my friends recently picked up a 5950x for an upgrade as prices are coming down a bit in preparation for AM5. Mostly a workstation, but some light gaming here and there. He's no idiot and is relatively competent with tech stuff, but it was fun introducing him to Corecycler Prime95 720-720 and y-cruncher 19-ZN2 ~ Kagari.

It has to be said a lot of the info on YouTube and the web about "How to do a curve" is, to put it politely, a mixed bag. "I RUN -30 ALL CORE ON A 5950X AND IT PLAYS GAMES FINE, I'M STABLE!". Uh-huh 

Good old 720-720 and Kagari slaughtering curves.


----------



## KedarWolf

Audioboxer said:


> One of my friends recently picked up a 5950x for an upgrade as prices are coming down a bit in preparation for AM5. Mostly a workstation, but some light gaming here and there. He's no idiot and is relatively competent with tech stuff, but it was fun introducing him to Corecycler Prime95 720-720 and y-cruncher 19-ZN2 ~ Kagari.
> 
> It has to be said a lot of the info on YouTube and the web about "How to do a curve" is, to put it politely, a mixed bag. "I RUN -30 ALL CORE ON A 5950X AND IT PLAYS GAMES FINE, I'M STABLE!". Uh-huh
> 
> Good old 720-720 and Kagari slaughtering curves.


OCCT 12-hour stability test caught some core errors 720-720 FFTs Core Cycler missed.

However, you need to be a Patreon to use the stability test.


----------



## Audioboxer

KedarWolf said:


> OCCT 12-hour stability test caught some core errors 720-720 FFTs Core Cycler missed.
> 
> However, you need to be a Patreon to use the stability test.


I genuinely tend to find a 720-720 overnight and then a Kagari overnight does the trick, in terms of finding the failing cores. From there, just add the rest to ignore in corecycler, and repeat overnights with less cores till nothing is failing. It's often your 2 best cores, or 4 best if 2CCD, that will give you the most challenge.

Then run a 50 cycle TM5 and make sure it doesn't time out (if TM5 times out it's often a good indicator one of your cores has crashed). That or a Karhu crash after like 5~6+ hours. Though Karhu is paid software as well.


----------



## Audioboxer

Ooft, after spending days doing extensive testing with Corecycler, again, I actually managed to fail a few more cores. Now, I don't know if this could be in part due to AGESA 1.2.0.7. AMD made big changes with 1.2.0.4 that knocked curves off. I redid my curve on 1.2.0.5. Failures I got now were mostly hours into testing, not like quick fails.

Anyway, my 2nd best core that was at -1 actually fell to 0










Core 2 which is my best core had to come down as well.

Out of interest when you guys are running 720-720 what sort of CPU temps and boost frequencies do you see? I'm usually around 67~69. It is summer just now but CPU temps don't usually get impacted too much by ambient when the loop is just running a CPU stability test. Core seems to boost to around 4,849~4949mhz for me going by HWINFO.

I use telemetry as it helps my single core loads boost higher, so I guess that's the wildcard for me between AGESA versions as well. Whether or not telemetry values are needing tweaked and/or just impacting the curve. Values of 150A with a 45mA offset are what I use.

I've seen a wide spread on negative values on other people's curves that are done properly (as in, *actually* stable lol), but my Core 5 from day 1 seems to be one of the most extreme examples. When I first did my Curve way back on AGESA 1.2.0.1 or whatever it was, it was at -5. So, it's always been a Core out of the factory that seems to have a voltage curve very close to optimal. As I said above I'm guessing using telemetry stresses that even more, if it's pushing core clock higher.


----------



## ManniX-ITA

Just noticed Ryzen Master added an automatic Curve Optimizer tool...
Did anyone tested it?

I'm running it now on a 5600G, about 52 minutes ETA.
Rebooted once while testing Core 0, now is testing Core 2.


----------



## KedarWolf

ManniX-ITA said:


> Just noticed Ryzen Master added an automatic Curve Optimizer tool...
> Did anyone tested it?
> 
> I'm running it now on a 5600G, about 52 minutes ETA.
> Rebooted once while testing Core 0, now is testing Core 2.


Others have tested it and it's not very good. They found the curve it finds is unstable and requires much more testing with Core Cycler and y-cruncher etc.


----------



## ManniX-ITA

KedarWolf said:


> Others have tested it and it's not very good. They found the curve it finds is unstable and requires much more testing with Core Cycler and y-cruncher etc.


I didn't expect miracles considering it takes less than 10 minutes per core...
Thought maybe AMD had some magic trick hidden to more quickly test but I guess not.

Maybe it depends also on the CPU model.
I'm testing the counts found by this optimization on Linux with this 5600G and it's not freaking out.
Linux is much more sensible to unstable OC and it crashed previously when I tried a blunt -20 all core.


----------



## -Slane-

New CoreCycler version 0.9.1.0 is out : Releases · sp00n/corecycler

Changelog:
The previous release had problems with 2 threads, fixed these.


----------



## Sir Beregond

ManniX-ITA said:


> Just noticed Ryzen Master added an automatic Curve Optimizer tool...
> Did anyone tested it?
> 
> I'm running it now on a 5600G, about 52 minutes ETA.
> Rebooted once while testing Core 0, now is testing Core 2.


It's not good. It'll tell you you can do all core -30 and that's just not true.


----------



## ManniX-ITA

Sir Beregond said:


> It's not good. It'll tell you you can do all core -30 and that's just not true.


Yes it's pretty sloppy.
But at least it gave me a hint.
Went down more or less 2 to 4 counts on all cores to get it stable and one core 10-15, it was really unstable.

I can't do -30 even on Windows at FCLK 1900.
I'm running Linux there and the CO count, like everything else, are not the same as Windows.
Not everyone is lucky, average binning


----------



## KedarWolf

PJVol said:


> and @CubanB
> you can try binary linked below.
> Use the following arguments order
> 1 2 3 4 5 6 7 8 ppt tdc edc fmax
> All four limits are required, use 0 to not override.
> e.g. to set only EDC limit to 320A
> 
> 
> Code:
> 
> 
> 'path-to-a-binary\PBO2 tuner.exe' 1 2 3 4 5 6 7 8 0 0 320 0'
> 
> 
> 
> 
> 
> 
> 
> Debug-cli.7z
> 
> 
> 
> 
> 
> 
> 
> drive.google.com


I don't think PBOTuner is working on my EVGA X570 Dark board. I set a core on the curve, run Core Cycler, raise it, run it again, always passes. But if I set that core in the BIOS at the same speed as the tool, it fails Core Cycler.


----------



## heptilion

KedarWolf said:


> I don't think PBOTuner is working on my EVGA X570 Dark board. I set a core on the curve, run Core Cycler, raise it, run it again, always passes. But if I set that core in the BIOS at the same speed as the tool, it fails Core Cycler.


did you end up buying the dark board? do you think it's worth it? are you noticing anything better than your old board/something like a crosshair 8 board?


----------



## KedarWolf

heptilion said:


> did you end up buying the dark board? do you think it's worth it? are you noticing anything better than your old board/something like a crosshair 8 board?


Yes, I bought the Dark board, but until I get someone to mod the BIOS our make a guide so I can do it myself, I'll not see the full potential. It doesn't overclock the RAM as well as my Unify-X Max but I did get the #1 in the world benchmark in Blender for a 5950x today with a static CCX overclock. I can do Core 1 -23 and the rest of the cores -30 in the Curve y-cruncher and Core Cycler stable but PBO is broken and I score like 300 points less in R23 and much slower in y-cruncher 2.5b. I'm hoping a BIOS update will fix the PBO soon and I can get PBS and CBS unlocked BIOS soon. Until I do, I'll not see good results yet.

I'm pretty much stuck with a CCX overclock until a BIOS update fixes the PBO boost.


----------



## MrGamer

I'm having some issues with my 5800X3D - to save a long story short it's not boosting to it's max when benchmarking, it maxes out at 66W, 70ish% of PPT Limit and 3.8ghz. I've tried pretty much everything (latest BIOS which has been reflashed, windows power settings, lots and lots of other things) However, the really odd thing I get with it is that if I use PBO2 Tuner and set any minus value and benchmark it, it suddenly uses 115W, PPT usage goes up and it boosts right upto 4.3ghz (where it then thermal throttles down). I'm really confused, I think there's some setting stuck somewhere (not sure how, Windows and Motherboard has been reset/reflashed). Wondering if you may possibly know? HWinfo is confirming it's not Thermal Throttling either. PSU is a Corsair 750XM.


----------



## KedarWolf

KedarWolf said:


> Yes, I bought the Dark board, but until I get someone to mod the BIOS our make a guide so I can do it myself, I'll not see the full potential. It doesn't overclock the RAM as well as my Unify-X Max but I did get the #1 in the world benchmark in Blender for a 5950x today with a static CCX overclock. I can do Core 1 -23 and the rest of the cores -30 in the Curve y-cruncher and Core Cycler stable but PBO is broken and I score like 300 points less in R23 and much slower in y-cruncher 2.5b. I'm hoping a BIOS update will fix the PBO soon and I can get PBS and CBS unlocked BIOS soon. Until I do, I'll not see good results yet.
> 
> I'm pretty much stuck with a CCX overclock until a BIOS update fixes the PBO boost.


EVGA modded a BIOS and unlocked the PBS and CBS menus.

Now I'm getting better R23, y-cruncher about a second faster, and a really excellent CO Curve. Same RAM timings though, I think I maxed that out on my MSI board.

TM5, Core Cycler 720-720 FFTs SSE, y-cruncher HNT, FFT and C17 stress tests and Linpack XTreme 1.1.5 stable.


----------



## Seaie280672

Has anyone ever seen this error before, so far its only happening on this 768K AVX2 test, my CO is currently set to -25 for all cores except one which is at -18, it will pass on AVX and on SSE, this is on a 5950X on a Gigabyte X570S motherboard, strange part is, it does it on this test too with CO disabled in the bios too, its passing every other test I throw at it, but giving this error for every core in this test.


----------



## HEYY0M1KEY

Current progress. PPT, TDC, and EDC set at default 142, 90, 140. +150 core. Outside of ram most of my bios settings are Auto, besides Global C-State and CPPC. Pretty happy I broke 16,000 Multi and 1,600 Single in Cinebench R23. 15,000 or so and high 1,400 low 1,500 was stock PBO. Working on running a few different configs to see if some of the -30 are too high still. Y-Cruncher 19-zn2 Kagari helped show Core 0 and 1 needed to be less of an offset. This run was just shy of 10 hours on Y-Cruncher. Also ran Prime 95 SSE and AVX2 overnight as well before this. Spreadsheet shows my process on testing thus far.


----------



## HEYY0M1KEY

Seaie280672 said:


> Has anyone ever seen this error before, so far its only happening on this 768K AVX2 test, my CO is currently set to -25 for all cores except one which is at -18, it will pass on AVX and on SSE, this is on a 5950X on a Gigabyte X570S motherboard, strange part is, it does it on this test too with CO disabled in the bios too, its passing every other test I throw at it, but giving this error for every core in this test.
> 
> I got the exact same error running that config. Not sure if it's not a valid config setting. Someone more knowledgeable than me may have an answer.


----------



## KedarWolf

Seaie280672 said:


> Has anyone ever seen this error before, so far its only happening on this 768K AVX2 test, my CO is currently set to -25 for all cores except one which is at -18, it will pass on AVX and on SSE, this is on a 5950X on a Gigabyte X570S motherboard, strange part is, it does it on this test too with CO disabled in the bios too, its passing every other test I throw at it, but giving this error for every core in this test.
> 
> View attachment 2574446


It looks like you're using 720-720 FFTs. Change it to 768-768 FFTs.


----------



## sp00n82

It seems I have to add a validity check for the custom FFT sizes. It's interpreting the 720-720 as 768 as the lower and 672 as the upper bound. As 720k itself doesn't exist, it tries to determine the next possible ones, and apparently there's a small flaw in that, and Prime95 won't run with invalid setting (hence the error messages).


----------



## KedarWolf

sp00n82 said:


> It seems I have to add a validity check for the custom FFT sizes. It's interpreting the 720-720 as 768 as the lower and 672 as the upper bound. As 720k itself doesn't exist, it tries to determine the next possible ones, and apparently there's a small flaw in that, and Prime95 won't run with invalid setting (hence the error messages).


I think it only does that with AVX2 as it's not a valid FFT size for it. AVX2 you need to do 768-768.

SSE it's fine at 720-720.

Prime95_2022-10-06_22-23-18_SSE_720-720_FFT_720K-720K.txt


----------



## sp00n82

Yeah, the various modes have different tested FFT sizes.


----------



## gamerguy777

Well this ain't working for me, 5950x download, extract and run with out adjusting anything, just keeping it . Runs first core and that is it. Any help would be exceptionally appreciated


----------



## sp00n82

No logs, no help. 🤷‍♂️


----------



## gamerguy777

sp00n82 said:


> No logs, no help. 🤷‍♂️


Ok into that


----------



## gamerguy777

sp00n82 said:


> No logs, no help. 🤷‍♂️


Spoon can I ask what settings to make the fastest pass and how long is that, I tried 6 mins and still on the first core, 3 mins still on the first core.

I need to test if this is working so asking how do I setup the fastest pass from one core to the next, please advise thank you?


----------



## gamerguy777

sp00n82 said:


> No logs, no help. 🤷‍♂️


----------



## gamerguy777

After a couple of minutes, can anyone please help??


----------



## sp00n82

gamerguy777 said:


> Spoon can I ask what settings to make the fastest pass and how long is that, I tried 6 mins and still on the first core, 3 mins still on the first core.
> 
> I need to test if this is working so asking how do I setup the fastest pass from one core to the next, please advise thank you?


From the log (and the other screenshots) it seems the execution just stopped without an error? You didn't close the script terminal window yourself?
I've never had reports of this behavior before, so don't know exactly what's going on here.


----------



## gamerguy777

sp00n82 said:


> From the log (and the other screenshots) it seems the execution just stopped without an error? You didn't close the script terminal window yourself?
> I've never had reports of this behavior before, so don't know exactly what's going on here.


Correct it just stops, Spoon can you please advise me whats the fastest settings I can use to at least get the script to run on the other cores, please advise what settings I should use in the .ini please?

I have no idea how to proceed as I really need to get the Curve sorted, random reboots etc happening all the time and I cannot get anything done, using brand new 22H2 as well.

please advise what settings to proceed, the fastest ones possible please, it would bet better with something than nothing and at the moment its nothing

Thanks so very much for any help moving forward!


----------



## gamerguy777

This is as far as I get: the C:\Windows\System32> below comes up after 30 seconds, not pressing anything!

I have attached the logs and the .ini as a .txt to allow it here, can anyone help me to get this working, I actually really need to use corecycler for a real world random reboots to stop, please help anyone to get this working!!

Whats the shortest test I can use to see if it switches to the next core, need the fastest setting to simply be able to test if its switching to the next core, any help needed please!


----------



## sp00n82

Well you can set the runtime per core to like 10s, the exact syntax is in the config.ini. It won't really test much then though. Or you could customize the core test order if you want a specific core to run first, again, the syntax should be explained in the ini file.

I can't run any test personally right now and for the next couple of days, but this behavior you describe is unlike anything I've heard before. Maybe a very unstable overclock, or some Windows settings nobody else has yet encountered.

//Edit
I see you attached the config.default.ini, note that the program uses this file only if no *config.ini* is found, so any changes to the .default.ini will not be applied to the script if the config.ini is already there.
And the config.ini _should_ be auto-generated from the config.default.ini if it's not found.


----------



## Luggage

gamerguy777 said:


> This is as far as I get: the C:\Windows\System32> below comes up after 30 seconds, not pressing anything!
> 
> I have attached the logs and the .ini as a .txt to allow it here, can anyone help me to get this working, I actually really need to use corecycler for a real world random reboots to stop, please help anyone to get this working!!
> 
> Whats the shortest test I can use to see if it switches to the next core, need the fastest setting to simply be able to test if its switching to the next core, any help needed please!
> View attachment 2575248


Sounds very unstable - how many cycles of y-cruncher all tests can you pass? Press 1-7-0


----------



## gamerguy777

Luggage said:


> Sounds very unstable - how many cycles of y-cruncher all tests can you pass? Press 1-7-0


Well I have not even tried with y-cruncher as yet, should I change the settings from prime95 and see, whats the minimum settings in time I can use for y-cruncher. Again I have not been able to get past the first core, nothing happens. My cores are mainly -30 for the second ccx and range around -15 to -25 for the first ccx, I get anywhere up to 5100 mhz whilst the processor is in heavy use. I dont think its a very unstable OC I think something isnt working right!

Whats the smallest timewise setting for y-cruncher can I use luggage?


----------



## Luggage

gamerguy777 said:


> Well I have not even tried with y-cruncher as yet, should I change the settings from prime95 and see, whats the minimum settings in time I can use for y-cruncher. Again I have not been able to get past the first core, nothing happens. My cores are mainly -30 for the second ccx and range around -15 to -25 for the first ccx, I get anywhere up to 5100 mhz whilst the processor is in heavy use. I dont think its a very unstable OC I think something isnt working right!
> 
> Whats the smallest timewise setting for y-cruncher can I use luggage?


Not in corecycler - just run y-cruncher stand alone. Run the stress test “1”, enable all tests “7”, run “0”.
Let it run for a couple of hours as a start.


----------



## gamerguy777

Luggage said:


> Not in corecycler - just run y-cruncher stand alone. Run the stress test “1”, enable all tests “7”, run “0”.
> Let it run for a couple of hours as a start.


Ok what am i typing in to get this to start?

And will the results show me if the system is stable with the current CO settings ?


----------



## gamerguy777

ok its running, how can I determine if its good with the current CO settings, I am doing this to fine tune my CO settings, what am I looking for to determine this, and why do I need to run it for 2 hours, how are other people doing it, run for 2 hours and then change the settings for CO on cores that did work at that CO, surely there is a simpler way, I might scrap this because I was hoping to find a tool that simply allows me to test each core for the CO and then adjust and then adjust again


----------



## CrustyJuggler

gamerguy777 said:


> ok its running, how can I determine if its good with the current CO settings, I am doing this to fine tune my CO settings, what am I looking for to determine this, and why do I need to run it for 2 hours, how are other people doing it, run for 2 hours and then change the settings for CO on cores that did work at that CO, surely there is a simpler way, I might scrap this because I was hoping to find a tool that simply allows me to test each core for the CO and then adjust and then adjust again


If it crashes or throws an error you have an issue, you might throw hardware errors as well. When I did this test I always had a hardware error logged along with a an error or crash of y-cruncher.


----------



## gamerguy777

Ok for some reason its now working, caqn someone please tell me which log do I look at and what text will I see if it fails, what and I searching for in the log to determine if I need to adjust more - or less, thanks in advance!


----------



## Flayiming

Hi, I need your advice.
I have one core (7 core, 8 if normalny count form 1, last in CCD) which is my best core.
But this core fails SSE 720k no matter what.

My setup:
CPU: 5950x
MB: Asus B550-E (lastest bios, 2803 2022/04/29, with AGESA V2 PI 1.2.0.7)
RAM: 4x8 GB runing in default settings, voltages, etc (2133 mhz CL 15)
PSU: Corsair HX1000
CPU cooler: Arctic Liquid Freezer II 360 with offset mount

On CO -10 this core fails 720k in 1 minute, I checked LLC auto, 2 & 4, if I change LLC to 3 it passes 2 minutes but stil fails.
I even changed Power Phase Control to optimized, this had given me some more seconds before fail, same with CPU VRM Switching Frequency set to 500.
On CO -5 it passes something like 30 minutes but fails.

After so many fails (other values like -3, -2, etc), I changed whole CO and set (only) core 7 to -1, this time it passed 05 hours, 47 minutes, 56 seconds (time form log file).

After this fail I turned off whole CO and let it run some hours (I set in config file 18 hours).
It passed 12 hours, 35 minutes, 22 seconds but still failed, so now this begs the question if it passed 12 hours can I regard this as stable?
12 hours passed but after 35 more minutes another fail 

Oh, and max boost on this core with CO turned off is 5050, and effective 5043, no boost override, so its all on +0 mhz.


----------



## sp00n82

gamerguy777 said:


> ok its running, how can I determine if its good with the current CO settings, I am doing this to fine tune my CO settings, what am I looking for to determine this, and why do I need to run it for 2 hours, how are other people doing it, run for 2 hours and then change the settings for CO on cores that did work at that CO, surely there is a simpler way, I might scrap this because I was hoping to find a tool that simply allows me to test each core for the CO and then adjust and then adjust again


It's no one-click tool. If you see an error, reduce the negative CO value (i.e. more into the positive). If you don't see an error after x time, increase it (more into the negativ) and test again. It's a *very* time consuming process, so it may not have been what you are looking for.

Oh, and changing the setting of one core might also affect the stability of other cores, something to be aware of when you're right on the edge of stability.


----------



## sp00n82

Flayiming said:


> Hi, I need your advice.
> I have one core (7 core, 8 if normalny count form 1, last in CCD) which is my best core.
> But this core fails SSE 720k no matter what.
> 
> My setup:
> CPU: 5950x
> MB: Asus B550-E (lastest bios, 2803 2022/04/29, with AGESA V2 PI 1.2.0.7)
> RAM: 4x8 GB runing in default settings, voltages, etc (2133 mhz CL 15)
> PSU: Corsair HX1000
> CPU cooler: Arctic Liquid Freezer II 360 with offset mount
> 
> On CO -10 this core fails 720k in 1 minute, I checked LLC auto, 2 & 4, if I change LLC to 3 it passes 2 minutes but stil fails.
> I even changed Power Phase Control to optimized, this had given me some more seconds before fail, same with CPU VRM Switching Frequency set to 500.
> On CO -5 it passes something like 30 minutes but fails.
> 
> After so many fails (other values like -3, -2, etc), I changed whole CO and set (only) core 7 to -1, this time it passed 05 hours, 47 minutes, 56 seconds (time form log file).
> 
> After this fail I turned off whole CO and let it run some hours (I set in config file 18 hours).
> It passed 12 hours, 35 minutes, 22 seconds but still failed, so now this begs the question if it passed 12 hours can I regard this as stable?
> 12 hours passed but after 35 more minutes another fail
> 
> Oh, and max boost on this core with CO turned off is 5050, and effective 5043, no boost override, so its all on +0 mhz.


PBO is not covered by AMD's warranty, so having to set positive values for CO is something that you might have to do. It's (probably) the minority, but I've seen multiple reports that this was the case. Just bad luck with the silicone lottery.

If the core even fails in stock settings, i.e. no PBO at all (be aware, some motherboards activate it in their "stock" settings!), then you could consider to RMA the processor as faulty.
If you can RMA the processor with a failing core with PBO active depends on the goodwill of your seller I guess.


----------



## gamerguy777

sp00n82 said:


> PBO is not covered by AMD's warranty, so having to set positive values for CO is something that you might have to do. It's (probably) the minority, but I've seen multiple reports that this was the case. Just bad luck with the silicone lottery.
> 
> If the core even fails in stock settings, i.e. no PBO at all (be aware, some motherboards activate it in their "stock" settings!), then you could consider to RMA the processor as faulty.
> If you can RMA the processor with a failing core with PBO active depends on the goodwill of your seller I guess.


what log states the fail, what word is used, passed for passed, what word is used for as failed test ??


----------



## sp00n82

gamerguy777 said:


> what log states the fail, what word is used, passed for passed, what word is used for as failed test ??


Normally it should be "error" in the CoreCycler log file, and it should also be displayed in the terminal. But if the whole script just terminates as it seems to do for you, then this of course is not being displayed.
For the Prime95 log file it should also be error (e.g. Fatal Error).

I'm really curious why the script just terminates for you, if it's closed then of course no core change will happen. But the log file doesn't seem to indicate any problems.


----------



## LtMatt

sp00n82 said:


> PBO is not covered by AMD's warranty, so having to set positive values for CO is something that you might have to do. It's (probably) the minority, but I've seen multiple reports that this was the case. Just bad luck with the silicone lottery.
> 
> If the core even fails in stock settings, i.e. no PBO at all (be aware, some motherboards activate it in their "stock" settings!), then you could consider to RMA the processor as faulty.
> If you can RMA the processor with a failing core with PBO active depends on the goodwill of your seller I guess.


No motherboard should activate PBO when using true default BIOS settings. Auto, which is the default option, is off.


----------



## sp00n82

LtMatt said:


> No motherboard should activate PBO when using true default BIOS settings. Auto, which is the default option, is off.


That should be the case, yes, but I've read reports that this isn't always the case for some motherboards.
It may also have been user error though, so just to be on the safe side set it to disabled anyway if you want to test for non-PBO stability.


----------



## LtMatt

sp00n82 said:


> That should be the case, yes, but I've read reports that this isn't always the case for some motherboards.
> It may also have been user error though, so just to be on the safe side set it to disabled anyway if you want to test for non-PBO stability.


Thanks, I am 99% sure it is user error but I agree with your advice.


----------



## Flayiming

PBO active means other power limits than stock? PPT 142, TDC 95 and EDC 140 for 5950x.
When I was testing CO turned off, my power limits were set to PPT 200, TDC 130, EDC 135,
more TDC/EDC lowered clocks in CB23. Max PPT that I have seen was something like 205, so I set 200 to limit it.

But I think this shound not interfere with core testing, were max I have seen is PPT 84 (avg 50), EDC/TDC 44(avg 21,4). Readings from HWinfo.


----------



## sp00n82

The power settings with PBO enabled are set by the motherboard, and these can differ from board to board. Or you can set them manually.








Explaining AMD Ryzen Precision Boost Overdrive (PBO), AutoOC, & Benchmarks


With the launch of the Ryzen 3000 series processors, we’ve noticed a distinct confusion among readers and viewers when it comes to the phrases “Precision Boost 2,” “XFR,” “Precision Boost Overdrive,” which is different from Precision Boost, and “AutoOC.” There is also a lot of confusion about...




www.gamersnexus.net


----------



## LtMatt

sp00n82 said:


> The power settings with PBO enabled are set by the motherboard, and these can differ from board to board. Or you can set them manually.
> 
> 
> 
> 
> 
> 
> 
> 
> Explaining AMD Ryzen Precision Boost Overdrive (PBO), AutoOC, & Benchmarks
> 
> 
> With the launch of the Ryzen 3000 series processors, we’ve noticed a distinct confusion among readers and viewers when it comes to the phrases “Precision Boost 2,” “XFR,” “Precision Boost Overdrive,” which is different from Precision Boost, and “AutoOC.” There is also a lot of confusion about...
> 
> 
> 
> 
> www.gamersnexus.net
> 
> 
> 
> 
> 
> View attachment 2575398


Yes, that confirms it as setting PBO to enabled/advanced is not the default option. The default option is always Auto, and Auto = disabled.


----------



## sp00n82

LtMatt said:


> Yes, that confirms it as setting PBO to enabled/advanced is not the default option. The default option is always Auto, and Auto = disabled.


Yeah, as said, that's how it _should_, but not necessarily how it _does_ work.
See e.g. here:

__
https://www.reddit.com/r/Amd/comments/kxsrbu/_/gjd9um2


----------



## LtMatt

sp00n82 said:


> Yeah, as said, that's how it _should_, but not necessarily how it _does_ work.
> See e.g. here:
> 
> __
> https://www.reddit.com/r/Amd/comments/kxsrbu/_/gjd9um2


I’d like to see some screenshots from that users system showing the difference in Ryzen Master Tool with PBO at Auto, enabled and disabled.


----------



## Flayiming

Hi, I have another question.
I had seen some strange behavior with my ethernet card when I test CO with p95 SSE 720k on core 0.
When I test core 0 my internet connection via cable is slower approx 75% than if I not test core 0.
From 50 mbps to 12 mbps. When I stop the test internet speed is back to normal. I'm using asus motherboard b550-e (etherent connection form MB) with 5950x.
I know I should leave core alone if test is in progress but I needed to check something and I had an impression that something is slower, I mean slower load etc.

With wifi connection this problem does not occur (this MB have wifi), if I test core 0 or not.
Is this something normal when heavly using core 0 or is this MB quirk or cpu?
Can someone check if they have this problem too?


----------



## sp00n82

This is nothing that should be too worrying. Fast ethernet connections can actually use up a lot of CPU power, for example LTT has made some videos already where they show that a 100 Gigabyte connection can use 100% of all the available cores on a really fast system.

The issue here is probably that the Windows scheduler doesn't work correctly with balancing the load when a program uses 100% of a single core and has a forced affinity to that core, and the ethernet connections should also be handled by the same core. Prime95 is also set to a "high" priority in CoreCycler, meaning any "normal" activity is being pushed back (regular Prime95 runs use a "low" or even "idle" priority, so that issue shouldn't be as visible there).


----------



## rvborgh

Is there a way of getting this to work on systems with Powershell version 2? This seems like a useful tool for properly measuring stability on a per core basis for my 32/64 core quad socket Opteron 63xx with unlocked ES processors.


----------



## sp00n82

rvborgh said:


> Is there a way of getting this to work on systems with Powershell version 2? This seems like a useful tool for properly measuring stability on a per core basis for my 32/64 core quad socket Opteron 63xx with unlocked ES processors.


I don't know if it works on PowerShell 2. You could change the line


Code:


#requires -version 3.0

 to 2.0 or delete the line in the script-corecycler.ps1 file to see if it does.
It also checks for the availability of at least .NET 3.5 right below, which also might not exist on older Windows installations.

If it doesn't, you could try to upgrade PowerShell?
PowerShell 3.0: Download Windows Management Framework 3.0 from Official Microsoft Download Center
PowerShell 5.1: Download Windows Management Framework 5.1 from Official Microsoft Download Center

Windows 10 comes with PowerShell 5.0/5.1 by default, so that is the one I have developed it on.


Note that it will not work with PowerShell 6 and above, as these are rewrites and are still lacking some required functionality.


----------



## rvborgh

i did try editing that 3.0 to 2.0. Didn't work however. i'll see if i can upgrade the powershell.



sp00n82 said:


> I don't know if it works on PowerShell 2. You could change the line
> 
> 
> Code:
> 
> 
> #requires -version 3.0
> 
> to 2.0 or delete the line in the script-corecycler.ps1 file to see if it does.
> It also checks for the availability of at least .NET 3.5 right below, which also might not exist on older Windows installations.
> 
> If it doesn't, you could try to upgrade PowerShell?
> PowerShell 3.0: Download Windows Management Framework 3.0 from Official Microsoft Download Center
> PowerShell 5.1: Download Windows Management Framework 5.1 from Official Microsoft Download Center
> 
> Windows 10 comes with PowerShell 5.0/5.1 by default, so that is the one I have developed it on.
> 
> 
> Note that it will not work with PowerShell 6 and above, as these are rewrites and are still lacking some required functionality.


----------



## Zslick

Question for everyone. In setting to AVX2 (whether using Custom 1's in .cfg, or AVX2 designation without Custom settings), CoreCycler crashes instantaneously as soon as the program begins on every core. 

However, if I run outside of CoreCycler using AVX2 or AVX-512 on the newest version of P95, on all cores, I have no issues and can run with AVX2 or AVX-512 for hours or more. 

Is there a known bug/potential issue that may be causing instant crashes using CoreCycler on AVX2? Running a 7950X and have had no issues with CoreCycler functioning properly with y-cruncher or prime95 on any other combination of settings (SSE, AVX, x86 y-cruncher, etc.). Again, P95 runs AVX-512 and AVX2 just fine outside of CoreCycler.


----------



## sp00n82

With the potential support of AVX-512 in Ryzen 7000, Prime95 may automatically choose different settings than what CoreCycler tells it to do so far.

Can you provide the log files for CoreCycler and Prime95 for a crash, as well as the prime.txt and local.txt inside the test_programs/p95 directory?
And then also the prime.txt and local.txt files for a successful run without CoreCycler?

Eventually I would also need the Prime95 log file for a full successful run of all FFT sizes that are being tested in AVX-512, they probably differ from those with AVX2. But this will probably take multiple hours to complete, and you'd need to manually increase the maximum FFT size in Prime95's settings, at least for the other modes the default maximum setting wasn't the "true" maximum it could do.


----------



## blu3dragon

rvborgh said:


> i did try editing that 3.0 to 2.0. Didn't work however. i'll see if i can upgrade the powershell.


In case it helps, there is an alternative (more basic) script here that might work: GitHub - jasonpoly/per-core-stability-test-script: Test script developed for for easier testing of Zen 3 curve offsets


----------



## KedarWolf

Does Core Cycler run like if you set it 720-720 SSE with memory In-Place?


----------



## Zslick

@*sp00n82*

Upon further testing, I am thinking my 19-ZN2 ycruncher failures may be due to incompatibility/issues with Zen4/7950X. Hoping to test further. I've downloaded the newest ycruncher and overwritten it into the CC folder. How can I call the new "22-ZN4" instruction set for 7950X? ZN2 is named "*19-ZN2 ~ Kagari*"; what's 22-ZN4's full name if I was to use the newest version of ycruncher?


----------



## Zslick

Looks like it may be 22-ZN4 ~ Kizuna (in searching benchmarks records site), but get an error when trying to call "*22-ZN4 ~ Kizuna*".


----------



## KedarWolf

Zslick said:


> Looks like it may be 22-ZN4 ~ Kizuna (in searching benchmarks records site), but get an error when trying to call "*22-ZN4 ~ Kizuna*".


Try adding this to the script-corecycler.ps1 just add the '22-ZN4 ~ Kizuna',



Code:


'testModes'          = @(
            '00-x86',
            '04-P4P',
            '05-A64 ~ Kasumi',
            '08-NHM ~ Ushio',
            '11-SNB ~ Hina',
            '13-HSW ~ Airi',
            '14-BDW ~ Kurumi',
            '17-ZN1 ~ Yukina',
            '19-ZN2 ~ Kagari',
            '22-ZN4 ~ Kizuna',

And this:



Code:


# y-Cruncher specific settings
[yCruncher]

# The test modes for y-Cruncher
# See the \test_programs\y-cruncher\Binaries\Tuning.txt file for a detailed explanation
# "00-x86"          - 86/IA-32 since Pentium (BSWAP, CMPXCHG, CPUID, RDTSC, possibly others...)
# "04-P4P"          - SSE, SSE2, SSE3
# "05-A64 ~ Kasumi" - x64, SSE, SSE2, SSE3
# "08-NHM ~ Ushio"  - x64, SSE, SSE2, SSE3, SSSE3, SSE4.1
# "11-SNB ~ Hina"   - x64, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX
# "13-HSW ~ Airi"   - x64, ABM, BMI1, BMI2, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2
# "14-BDW ~ Kurumi" - x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2
# "17-ZN1 ~ Yukina" - x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2
# "19-ZN2 ~ Kagari" - x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2
#
# The following settings would be available as well, but they don't run on Ryzen CPUs!
# "11-BD1 ~ Miyu"   - x64, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, ABM, FMA4, XOP
# "17-SKX ~ Kotori" - x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2 AVX512-(F/CD/VL/BW/DQ)
# "18-CNL ~ Shinoa" - x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2 AVX512-(F/CD/VL/BW/DQ/IFMA/VBMI)
#
# "00-x86" should produce the highest boost clock on most tests
# "19-ZN2 ~ Kagari" is optimized for Zen2/3, but produces more heat and a lower boost clock on most tests
# Default: 19-ZN2 ~ Kagari
mode = 22-ZN4 ~ Kizuna


----------



## Zslick

Beautiful, that works. I saw that language in the ps1 file, but thought it was just UI script and not enablement script.

*So with a Zen4 7950X:* I tested the ZN1, ZN2, and ZN3 binaries directly from the ycruncher directory, and on BBP digit extraction they all failed instantaneously. This is with all other stress tests (P95, OCCT, LinPack, etc.) appearing to be stable on my computer. 22-ZN4 ~ Kizuna passes without any issues. So I'd assume there is some type of issue with Zen4 not being able to run ZN1 through ZN3 under AVX2. The ZN4 binary uses AVX-512 which has no issues for me. I chased ghosts for close to a week trying to get stable on a setup I assume is not possible to obtain stability (AVX2 ZN1-ZN3 under 7950X). Hopefully this is helpful for others to know, and should probably be noted somewhere (if I end up having a correct callout here).


----------



## KedarWolf

Zslick said:


> Beautiful, that works. I saw that language in the ps1 file, but thought it was just UI script and not enablement script.
> 
> *So with a Zen4 7950X:* I tested the ZN1, ZN2, and ZN3 binaries directly from the ycruncher directory, and on BBP digit extraction they all failed instantaneously. This is with all other stress tests (P95, OCCT, LinPack, etc.) appearing to be stable on my computer. 22-ZN4 ~ Kizuna passes without any issues. So I'd assume there is some type of issue with Zen4 not being able to run ZN1 through ZN3 under AVX2. The ZN4 binary uses AVX-512 which has no issues for me. I chased ghosts for close to a week trying to get stable on a setup I assume is not possible to obtain stability (AVX2 ZN1-ZN3 under 7950X). Hopefully this is helpful for others to know, and should probably be noted somewhere (if I end up having a correct callout here).


I'm glad that worked for you. I only have basic knowledge of how to tweak PowerShell scripts etc. but I've gotten okay at it from tweaking the Optimize-Offline script I use often.

I have no idea how to make a PowerShell script from scratch, just how to do basic tweaking of existing scripts.


----------



## sp00n82

Zslick said:


> Beautiful, that works. I saw that language in the ps1 file, but thought it was just UI script and not enablement script.
> 
> *So with a Zen4 7950X:* I tested the ZN1, ZN2, and ZN3 binaries directly from the ycruncher directory, and on BBP digit extraction they all failed instantaneously. This is with all other stress tests (P95, OCCT, LinPack, etc.) appearing to be stable on my computer. 22-ZN4 ~ Kizuna passes without any issues. So I'd assume there is some type of issue with Zen4 not being able to run ZN1 through ZN3 under AVX2. The ZN4 binary uses AVX-512 which has no issues for me. I chased ghosts for close to a week trying to get stable on a setup I assume is not possible to obtain stability (AVX2 ZN1-ZN3 under 7950X). Hopefully this is helpful for others to know, and should probably be noted somewhere (if I end up having a correct callout here).


Have you forwarded this info to the developer of y-cruncher?






y-cruncher - mersenneforum.org


http://www.numberworld.org/y-cruncher/



www.mersenneforum.org












GitHub - Mysticial/y-cruncher: Bug-Tracking and open-sourced parts of y-cruncher.


Bug-Tracking and open-sourced parts of y-cruncher. - GitHub - Mysticial/y-cruncher: Bug-Tracking and open-sourced parts of y-cruncher.




github.com


----------



## Zslick

I have not and am not familiar with their group, but am working with ASUS to understand if AVX2 may be an issue with the X670 Extreme/bios. I've found some threads where it was a known AGESA issue or something to that affect on a previous BIOS/board that was fixed.

Given that AVX2 may be compromised, is there any easy text that can be inserted into the Core Cycler ps1 script to use AVX-512? I ask because it looks like Prime95 may be using different sub-variants of AVX-512 with it not necessarily being as straight forward.


----------



## KedarWolf

Zslick said:


> I have not and am not familiar with their group, but am working with ASUS to understand if AVX2 may be an issue with the X670 Extreme/bios. I've found some threads where it was a known AGESA issue or something to that affect on a previous BIOS/board that was fixed.
> 
> Given that AVX2 may be compromised, is there any easy text that can be inserted into the Core Cycler ps1 script to use AVX-512? I ask because it looks like Prime95 may be using different sub-variants of AVX-512 with it not necessarily being as straight forward.


Try updating the prime95 to the latest beta from the forum?









Prime95 (30.9 Build 3) Download


Popular system stability test program.




www.techpowerup.com


----------



## Zslick

The Core Cycler ps1 script only has scripting relating up to AVX2 though as selections (regardless of the version of Prime95 installed). Of course, I can manually set affinities in task manager with the newest P95, but the goal here would be to get Core Cycler automated with AVX-512.


----------



## KedarWolf

Zslick said:


> The Core Cycler ps1 script only has scripting relating up to AVX2 though as selections (regardless of the version of Prime95 installed). Of course, I can manually set affinities in task manager with the newest P95, but the goal here would be to get Core Cycler automated with AVX-512.


Can you just open the new prime95 and tell me the AVX ,AVX2, AVX-512 etc. options available and not available?

Just take a screenshot. I need to know to finish tweaking the script-corecycler.ps1 for you.


----------



## Zslick

Really appreciate you all looking at this. My concern is different subsets of AVX-512 (like you see in the below link), and even beginning to spend time to put anything in the .ps1 script without knowing what Prime95 itself is calling. I can't find the Prime95 site now I saw earlier, but I saw different variants listed in some Prime95 code somewhere beyond just "AVX-512" (e.g., AVX-512F). But in the main Prime95 UI, the option is simply denoted as "Disable AVX-512" if you want to turn it off. 









Advanced Vector Extensions 512 (AVX-512) - x86 - WikiChip


Advanced Vector Extensions 512 (AVX-512) is collective name for a number of 512-bit SIMD x86 instruction set extensions. The extensions were formally introduced by Intel in July 2013 with first general-purpose microprocessors implementing the extensions introduced in July 2017.




en.wikichip.org


----------



## KedarWolf

Zslick said:


> Really appreciate you all looking at this. My concern is different subsets of AVX-512 (like you see in the below link), and even beginning to spend time to put anything in the .ps1 script without knowing what Prime95 itself is calling. I can't find the Prime95 site now I saw earlier, but I saw different variants listed in some Prime95 code somewhere beyond just "AVX-512" (e.g., AVX-512F). But in the main Prime95 UI, the option is simply denoted as "Disable AVX-512" if you want to turn it off.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Advanced Vector Extensions 512 (AVX-512) - x86 - WikiChip
> 
> 
> Advanced Vector Extensions 512 (AVX-512) is collective name for a number of 512-bit SIMD x86 instruction set extensions. The extensions were formally introduced by Intel in July 2013 with first general-purpose microprocessors implementing the extensions introduced in July 2017.
> 
> 
> 
> 
> en.wikichip.org


I need to see Prime95 open and the options available on your PC. I don't have my motherboard or RAM yet to check on my 7950x. I linked the latest Prime95 in my earlier post. I can't change what Prime95 actually uses, but I can make sure it runs with all available options in AVX-512 it can in core cycler.


----------



## KedarWolf

See my edits before you respond.


----------



## Zslick

Sure thing! Apologies. Let me know if I'm missing anything or additional context in your question. Image below (v 30.8 build 17).


----------



## KedarWolf

Zslick said:


> Sure thing! Apologies. Let me know if I'm missing anything or additional context in your question. Image below (v 30.8 build 17).
> 
> View attachment 2576579


Update the Prime95 folder to the latest Prime95 then try this script-corecycler.ps1

Rename and remove the .txt from it. You may need to enable Show Extensions in File Explorer.

Edit: Replace the config.ini and config.default.ini too.


----------



## KedarWolf

See my edits.


----------



## KedarWolf

I might have to change one tweak. Let me know if it works.


----------



## Zslick

Thanks. Not working yet (error directly below). 2nd screenshot is from the .ps1 file where I had seen AVX_512F being referenced along with AVX_512 (whether helpful or not).


----------



## KedarWolf

Try these.


----------



## KedarWolf

I had one mistake. Use the reuploaded config files.


----------



## Zslick

Thanks Kedar. Still getting the below errors. I looked at some of the "=" errors, but not obvious the cause to me.


----------



## Zslick

That is from the re-uploaded files as well (triple checked now again).


----------



## sp00n82

Note that I'm working on adding AVX-512 support to CoreCycler, but it's a bit more complicated than I had hoped.
I had to rewrite the log parser as well, since apparently with AVX-512 there can be "half" K FFT sizes (like 4608, which would be 4.5K) that don't appear as "... 4K passed!" in the log but instead as "... 4608 passed!" (without the appended "K"). Unfortunately 4608K is also a regular tested FFT size, so I need to distinguish these two (and others) to be able to determine if all FFT sizes were tested.

I can probably push a first beta version today.

And I can't really test this myself unfortunately, as I don't have a CPU with AVX-512 support. I tried to use the Intel SDE kit to emulate it, but then a single FFT size takes around 90 minutes to complete with my 5900x, so that's not really an option.


----------



## sp00n82

Zslick said:


> Really appreciate you all looking at this. My concern is different subsets of AVX-512 (like you see in the below link), and even beginning to spend time to put anything in the .ps1 script without knowing what Prime95 itself is calling. I can't find the Prime95 site now I saw earlier, but I saw different variants listed in some Prime95 code somewhere beyond just "AVX-512" (e.g., AVX-512F). But in the main Prime95 UI, the option is simply denoted as "Disable AVX-512" if you want to turn it off.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Advanced Vector Extensions 512 (AVX-512) - x86 - WikiChip
> 
> 
> Advanced Vector Extensions 512 (AVX-512) is collective name for a number of 512-bit SIMD x86 instruction set extensions. The extensions were formally introduced by Intel in July 2013 with first general-purpose microprocessors implementing the extensions introduced in July 2017.
> 
> 
> 
> 
> en.wikichip.org


Prime95 seems to use AVX-512F. There's also a mention of AVX-512PF in Prime95\source\gwnum\cpuid.h, but at least it isn't used to calculate Prime95's TortureWeak value (which defines which CPU instructions are available).

Y-Cruncher on the other hand seems to be able to use a variety of different AVX-512 instructions:












I've also opened an issue on Github regarding the problem with Y-Cruncher, maybe it's a code problem after all:








Possible problem with Ryzen 7000 on various tests · Issue #30 · Mysticial/y-cruncher


Unfortunately I cannot give these information first hand, but I've had a report that some binaries don't work if run with a Ryzen 7000 processor: So with a Zen4 7950X: I tested the ZN1, ZN2...




github.com


----------



## sp00n82

Also @Zslick or anyone else with a Ryzen 7000 CPU: I could use Prime95 log files for AVX-512, to be sure that I have identified all the tested FFT sizes.
I do have one log that was made on an Intel X299 platform, but to double check I'd really like to have a Ryzen log file as well.

Please run Prime95 with the following settings (Max FFT size 65536) to make sure that all of the possible FFT sizes are being tested:











Unfortunately there's no good way to know if a full iteration has been completed, the most likely indication is probably that an already tested FFT size is being repeated. On the very first iteration every FFT size should appear only once, but after that, the FFT sizes can repeat multiple times before all of the others have been tested again.
On the X299 platform the first iteration took 1:46h, but it hadn't completed a full second one after an additional 2:20h. Just to give you some ballpark numbers.


----------



## sp00n82

Zslick said:


> Beautiful, that works. I saw that language in the ps1 file, but thought it was just UI script and not enablement script.
> 
> *So with a Zen4 7950X:* I tested the ZN1, ZN2, and ZN3 binaries directly from the ycruncher directory, and on BBP digit extraction they all failed instantaneously. This is with all other stress tests (P95, OCCT, LinPack, etc.) appearing to be stable on my computer. 22-ZN4 ~ Kizuna passes without any issues. So I'd assume there is some type of issue with Zen4 not being able to run ZN1 through ZN3 under AVX2. The ZN4 binary uses AVX-512 which has no issues for me. I chased ghosts for close to a week trying to get stable on a setup I assume is not possible to obtain stability (AVX2 ZN1-ZN3 under 7950X). Hopefully this is helpful for others to know, and should probably be noted somewhere (if I end up having a correct callout here).


So the developer of Y-Cruncher replied, and it seems to be an issue for all Ryzen 7950x(?) CPUs:



> So it took ~3 weeks for someone besides myself to finally notice this. hahahaha
> 
> This is a bug in AMD's PBO curve. I noticed this on my engineering hardware back in August and reported it to them. And I surprisingly noticed it on retail hardware as well. AMD says it's been fixed internally, but they still need to push the patch out to all the motherboard vendors. No ETA for when.
> 
> The exact point of failure varies by chip, though both my engineering sample and the retail 7950X that I tested fail on single-threaded y-cruncher AVX tests (with different motherboards as well). I was told to turn off PBO to work around it, though I got the same effect by applying a -200 offset on the PBO without sacrificing all of PBO.
> 
> The problem seems to be that the 7950X cannot handle AVX above ~5.5 GHz. Intel uses license-based scaling where AVX(512) instructions run at drastically reduced speeds until the chip can apply the AVX(512) offset clock reduction. AMD here seems to rely on clock-stretching to handle the transient before it can clock down. But there's a limit to clock-stretching and my guess is that some AVX loads are able to overwhelm it and crash the chip.











Possible problem with Ryzen 7000 on various tests · Issue #30 · Mysticial/y-cruncher


Unfortunately I cannot give these information first hand, but I've had a report that some binaries don't work if run with a Ryzen 7000 processor: So with a Zen4 7950X: I tested the ZN1, ZN2...




github.com


----------



## Zslick

Awesome to have the confirmation, truly appreciate it Spoon! Just glad to know I don't have a faulty motherboard, or faulty processor. I did fully isolate and test my memory, so no issues originating there. I am still going to be trying a second processor tonight to see if I have better stability at more aggressive Curve Optimizer settings on SSE evenso.

I can confirm that when I disable PBO, all forms of AVX, AVX2, and AVX-512 work with zero crashes. I entirely concur that the issue only happens when PBO is enabled, and is even further exacerbated by AVX2 versus AVX or AVX-512. I'm able to scale back AVX and AVX512 to get them stable with CO, but AVX2 doesn't behave with PBO enabled what-so-ever.

As for the log files spoon, are you stating it'd help if I run a full test with the custom settings you called out and provide the log file? What's the name of the log file that will have this in it for you (I haven't tried to look yet after running)? I'll get that late today/tomorrow or sometime this week once I have the new processor in and get some tests in for basic stability first.


----------



## sp00n82

Zslick said:


> As for the log files spoon, are you stating it'd help if I run a full test with the custom settings you called out and provide the log file? What's the name of the log file that will have this in it for you (I haven't tried to look yet after running)? I'll get that late today/tomorrow or sometime this week once I have the new processor in and get some tests in for basic stability first.


I have received a log file just now, which confirmed the FFT sizes I had seen in the one from the X299 run, so I can push the new version soon.


----------



## Zslick

Awesome Spoon! I had a feeling AVX-512 would be more complex from all the variants I was seeing in doing quick searches here-and-there. Very appreciative of the work you are doing on this program.


----------



## sp00n82

Version 0.9.2.0 is online, which (hopefully) supports AVX-512. There could be bugs, as I have no real possibility to test this with AVX-512 due to the lack of a processor supporting it. Please report any bugs that you encounter.
You can activate AVX-512 for Prime95 by entering AVX512 in the mode setting for Prime95.
You can now also run 22-ZN4 ~ Kizuna for y-Cruncher, which is its AVX-512 test optimized for Ryzen 7000 CPUs.

I've now also included BoostTester and PBO2 Tuner in the /tools directory, along with a readme.txt file in that directory that explains what the various files are supposed to do.










Release v0.9.2.0 · sp00n/corecycler


Updated to Prime95 30.8b17 Updated to y-Cruncher 0.7.10 Build 9513 Added BoostTester and PBO2 Tuner in the /tools directory, and also added a readme.txt there that describes what the various tools ...




github.com


----------



## Zslick

Thanks Spoon.

Does anyone have any strong recommendations for detecting idle-induced (instant) reboots caused by under-volted cores on Curve Optimizer? It's been exceptionally challenging to find any program that does a good job of identifying the core causing the once-in-8-hours idle reboot failures. It's been easy finding failures outside of idle reboots; but in taking CO to the edge (of when only idle reboots happen), that's where it seems to become exceptionally challenging.

P95 Huge 1T SSE doesn't detect anything; AIDA64 cache 1T doesn't detect anything; and the new included CoreTester (although an exceptionally low-demand) doesn't seem to detect anything.

y-cruncher 00-x86 is able to induce an instant reboot/crash on individual cores, but sometimes it takes close to 15 passes before getting one failure. Would be nice if there was something other than this in more quickly identifying the core causing idle reboots. Thoughts?


----------



## KedarWolf

Zslick said:


> Thanks Spoon.
> 
> Does anyone have any strong recommendations for detecting idle-induced (instant) reboots caused by under-volted cores on Curve Optimizer? It's been exceptionally challenging to find any program that does a good job of identifying the core causing the once-in-8-hours idle reboot failures. It's been easy finding failures outside of idle reboots; but in taking CO to the edge (of when only idle reboots happen), that's where it seems to become exceptionally challenging.
> 
> P95 Huge 1T SSE doesn't detect anything; AIDA64 cache 1T doesn't detect anything; and the new included CoreTester (although an exceptionally low-demand) doesn't seem to detect anything.
> 
> y-cruncher 00-x86 is able to induce an instant reboot/crash on individual cores, but sometimes it takes close to 15 passes before getting one failure. Would be nice if there was something other than this in more quickly identifying the core causing idle reboots. Thoughts?


I can't comment on idle reboots and cores, my I can say on my 5950x disabling C-States, DF C-States and Idle Setting on Normal, not Low, helps. Otherwise, y-cruncher reboots me.

I think though on a 7950x etc. it's advised to leave C-States on, but I dunno for sure, won't have my 7950x up and running until the weekend.


----------



## Zslick

Can you clarify specifics around "Idle setting on normal" (BIOS setting?): What that setting is called exactly, where it's located, and on what brand of motherboard? Don't believe I've seen that setting anywhere in ASUS' BIOS, but would definitely want to play with it if it exists.

I will say it's definitely preferable to keep C-states on to downclock unused cores, to drop temps for the entire package since everything revolves around _[lower temps] = [greater performance headroom]_


----------



## KedarWolf

Zslick said:


> Can you clarify specifics around "Idle setting on normal" (BIOS setting?): What that setting is called exactly, where it's located, and on what brand of motherboard? Don't believe I've seen that setting anywhere in ASUS' BIOS, but would definitely want to play with it if it exists.
> 
> I will say it's definitely preferable to keep C-states on to downclock unused cores, to drop temps for the entire package since everything revolves around _[lower temps] = [greater performance headroom]_


C-States On will induce random reboots and I actually get better benches all around with it off.


----------



## KedarWolf

C-States, DF C-States and Idle Mode, PO setting helps too.


----------



## Zslick

Interesting, thanks for the screenshots (*Power Supply Idle Control*). I don't think I've seen anything like that setting on ASUS' X670E Extreme BIOS, but will check again tomorrow.

On the 7950X I’ve found that C-states on (default/auto) results in higher benches and frequencies (for single core) and it doesn’t impact/improve reboots so far. I’ll test C-states (off) again if I continue to hit a wall this week--good reminder to spend some more time there as a last resort at least.

I'll also say that in my time using y-cruncher, it will give power-related error messages without rebooting if you are well over (by more than -2) on having too aggressive of a CO setting. However, once you get close to the fence, instant reboots will happen instead which slows down the optimization process. I've not found another program or setting that as consistently induces crashes or notifications as well as y-cruncher. Would be nice if a different program (P95, AIDA, or OCCT) with automatic core cycling induced errors, logging, or crashes as quickly and consistently as y-cruncher (without it often being a crash that interrupts the data gathering process).


----------



## KedarWolf

Oh yes. I read you need it on for 7000 series.


----------



## Luggage

Zslick said:


> Interesting, thanks for the screenshots (*Power Supply Idle Control*). I don't think I've seen anything like that setting on ASUS' X670E Extreme BIOS, but will check again tomorrow.
> 
> On the 7950X I’ve found that C-states on (default/auto) results in higher benches and frequencies (for single core) and it doesn’t impact/improve reboots so far. I’ll test C-states (off) again if I continue to hit a wall this week--good reminder to spend some more time there as a last resort at least.
> 
> I'll also say that in my time using y-cruncher, it will give power-related error messages without rebooting if you are well over (by more than -2) on having too aggressive of a CO setting. However, once you get close to the fence, instant reboots will happen instead which slows down the optimization process. I've not found another program or setting that as consistently induces crashes or notifications as well as y-cruncher. Would be nice if a different program (P95, AIDA, or OCCT) with automatic core cycling induced errors, logging, or crashes as quickly and consistently as y-cruncher (without it often being a crash that interrupts the data gathering process).


With zen 3 OCCT stability certificate found a few more cores after weeks of corecycler and yc testing. But now the grace period is over for my license and you have to be a patreon :/


----------



## KedarWolf

y-cruncher and Core Cycler passing on my 7950x -30 all cores except 3 and 11 at 29, golden CPU.

Too bad about the motherboard though, two RAM slots are not working out of the box with zero bent pins. I need to RMA it.


----------



## Zslick

Are you running +200 on AutoOC/Core Boost? What motherboard? I've gone through two processors--don't see how people are getting legitimate stable at -30s. Is this also with y-cruncher, 1 thread, 00-x86, 9 minutes per core?


----------



## KedarWolf

ASROCK X670E Taichi, Boost and Scaler on Auto, Auto on Core in the main menu.

The Taichi has the exact same VRM specs are the Gigabyte X670E Xtreme at $500 CAD less. Plus it's passing TM5 at 6400 with the EXPO on my A-Die on and timings set to Aggressive at 1-1 2000.

I really want same motherboard but with working RAM slots. Someone might buy my 5950x, EVGA X570S Dark and my binned CL14 3600 Royal Elite soon. I'll buy a new Taichi, RMA the old one, sell it locally at a bit of a loss. 

I don't want downtime on this build at all.


----------



## KedarWolf

Zslick said:


> Are you running +200 on AutoOC/Core Boost? What motherboard? I've gone through two processors--don't see how people are getting legitimate stable at -30s. Is this also with y-cruncher, 1 thread, 00-x86, 9 minutes per core?


y-cruncher Kizuna HNT and C17. All cores.


----------



## Zslick

You should definitely try out y-cruncher 00-x86, 1 thread, as it will drive higher boost clocks and closer-to-idle-type scenarios. I get more failures out of it than anything, and still don't reach true idle crashes even with that.

I can run AVX or AVX512 all core all day long hitting 5.95ghz; but not 1T low-load 00-x86, still trying to get fully stable there.

You have significantly more headroom for aggressive COs at Boost Auto as well.


----------



## KedarWolf

This is -30 all cores except 3 and 11 at 29. 200 Boost, Auto Scaler.

It passes Core Cycler as well.



Code:


--------------------------------------------------------------------------------
-------------- CoreCycler v0.9.2.0 started at 2022-10-31 03:11:14 --------------
--------------------------------------------------------------------------------
Log Level set to: ......... 2 [Writing debug messages to log file]
Stress test program: ...... Y-CRUNCHER
Selected test mode: ....... 00-X86
Logical/Physical cores: ... 32 logical / 16 physical cores
Hyperthreading / SMT is: .. ON
Selected number of threads: 1
Runtime per core: ......... 9 MINUTES
Suspend periodically: ..... ENABLED
Restart for each core: .... OFF
Test order of cores: ...... DEFAULT (ALTERNATE)
Number of iterations: ..... 10000

--------------------------------------------------------------------------------
The log files for this run are stored in:
D:\CoreCycler-v0.9.2.0\CoreCycler-v0.9.2.0\logs\
 - CoreCycler:   CoreCycler_2022-10-31_03-11-11_YCRUNCHER_00-X86.log
--------------------------------------------------------------------------------


03:11:16 - Iteration 1
----------------------------------
03:11:16 - Set to Core 0 (CPU 0)
           Running for 9 minutes...
03:20:18 - Completed the test on Core 0 (CPU 0)
03:20:18 - Set to Core 8 (CPU 16)
           Running for 9 minutes...
03:29:21 - Completed the test on Core 8 (CPU 16)
03:29:21 - Set to Core 1 (CPU 2)
           Running for 9 minutes...
03:38:23 - Completed the test on Core 1 (CPU 2)
03:38:23 - Set to Core 9 (CPU 18)
           Running for 9 minutes...
03:47:25 - Completed the test on Core 9 (CPU 18)
03:47:25 - Set to Core 2 (CPU 4)
           Running for 9 minutes...
03:56:28 - Completed the test on Core 2 (CPU 4)
03:56:28 - Set to Core 10 (CPU 20)
           Running for 9 minutes...
04:05:30 - Completed the test on Core 10 (CPU 20)
04:05:30 - Set to Core 3 (CPU 6)
           Running for 9 minutes...
04:14:32 - Completed the test on Core 3 (CPU 6)
04:14:32 - Set to Core 11 (CPU 22)
           Running for 9 minutes...
04:23:34 - Completed the test on Core 11 (CPU 22)
04:23:34 - Set to Core 4 (CPU 8)
           Running for 9 minutes...
04:32:37 - Completed the test on Core 4 (CPU 8)
04:32:37 - Set to Core 12 (CPU 24)
           Running for 9 minutes...
04:41:39 - Completed the test on Core 12 (CPU 24)
04:41:39 - Set to Core 5 (CPU 10)
           Running for 9 minutes...
04:50:41 - Completed the test on Core 5 (CPU 10)
04:50:41 - Set to Core 13 (CPU 26)
           Running for 9 minutes...
04:59:43 - Completed the test on Core 13 (CPU 26)
04:59:43 - Set to Core 6 (CPU 12)
           Running for 9 minutes...
05:08:45 - Completed the test on Core 6 (CPU 12)
05:08:45 - Set to Core 14 (CPU 28)
           Running for 9 minutes...
05:17:48 - Completed the test on Core 14 (CPU 28)
05:17:48 - Set to Core 7 (CPU 14)
           Running for 9 minutes...
05:26:50 - Completed the test on Core 7 (CPU 14)
05:26:50 - Set to Core 15 (CPU 30)
           Running for 9 minutes...
05:35:52 - Completed the test on Core 15 (CPU 30)

05:35:52 - Iteration 2
----------------------------------
05:35:52 - Set to Core 0 (CPU 0)
           Running for 9 minutes...
05:44:54 - Completed the test on Core 0 (CPU 0)
05:44:54 - Set to Core 8 (CPU 16)
           Running for 9 minutes...
05:53:56 - Completed the test on Core 8 (CPU 16)
05:53:56 - Set to Core 1 (CPU 2)
           Running for 9 minutes...
06:02:59 - Completed the test on Core 1 (CPU 2)
06:02:59 - Set to Core 9 (CPU 18)
           Running for 9 minutes...
06:12:01 - Completed the test on Core 9 (CPU 18)
06:12:01 - Set to Core 2 (CPU 4)
           Running for 9 minutes...
06:21:02 - Completed the test on Core 2 (CPU 4)
06:21:02 - Set to Core 10 (CPU 20)
           Running for 9 minutes...
06:30:04 - Completed the test on Core 10 (CPU 20)
06:30:04 - Set to Core 3 (CPU 6)
           Running for 9 minutes...
06:39:06 - Completed the test on Core 3 (CPU 6)
06:39:06 - Set to Core 11 (CPU 22)
           Running for 9 minutes...
06:48:08 - Completed the test on Core 11 (CPU 22)
06:48:08 - Set to Core 4 (CPU 8)
           Running for 9 minutes...
06:57:10 - Completed the test on Core 4 (CPU 8)
06:57:10 - Set to Core 12 (CPU 24)
           Running for 9 minutes...
07:06:12 - Completed the test on Core 12 (CPU 24)
07:06:12 - Set to Core 5 (CPU 10)
           Running for 9 minutes...
07:15:14 - Completed the test on Core 5 (CPU 10)
07:15:14 - Set to Core 13 (CPU 26)
           Running for 9 minutes...
07:24:17 - Completed the test on Core 13 (CPU 26)
07:24:17 - Set to Core 6 (CPU 12)
           Running for 9 minutes...
07:33:19 - Completed the test on Core 6 (CPU 12)
07:33:19 - Set to Core 14 (CPU 28)
           Running for 9 minutes...
07:42:22 - Completed the test on Core 14 (CPU 28)
07:42:22 - Set to Core 7 (CPU 14)
           Running for 9 minutes...
07:51:24 - Completed the test on Core 7 (CPU 14)
07:51:24 - Set to Core 15 (CPU 30)
           Running for 9 minutes...
08:00:25 - Completed the test on Core 15 (CPU 30)

08:00:25 - Iteration 3
----------------------------------
08:00:25 - Set to Core 0 (CPU 0)
           Running for 9 minutes...
08:09:27 - Completed the test on Core 0 (CPU 0)
08:09:27 - Set to Core 8 (CPU 16)
           Running for 9 minutes...
08:18:30 - Completed the test on Core 8 (CPU 16)
08:18:30 - Set to Core 1 (CPU 2)
           Running for 9 minutes...
08:27:32 - Completed the test on Core 1 (CPU 2)
08:27:32 - Set to Core 9 (CPU 18)
           Running for 9 minutes...
08:36:34 - Completed the test on Core 9 (CPU 18)
08:36:34 - Set to Core 2 (CPU 4)
           Running for 9 minutes...
08:45:35 - Completed the test on Core 2 (CPU 4)
08:45:35 - Set to Core 10 (CPU 20)
           Running for 9 minutes...
08:54:38 - Completed the test on Core 10 (CPU 20)
08:54:38 - Set to Core 3 (CPU 6)
           Running for 9 minutes...


----------



## Zslick

What's the highest reported clock speed, of your best core, that you're achieving in HWiNFO with those settings? And meaning, highest reported clocks after idling for a while (not while under load)?

And thank you helpful information--continuing to try some other settings to see if I can fix my idle reboots.


----------



## KedarWolf

When running what? Like R23, I don't want to run Core Cycler single core and watch 9 minutes of every core.


----------



## Zslick

After 5 minutes of being mostly idle (using file explorer, or the most minimal tasks), what is the max-reported clock speeds of all your cores in HWiNFO? Completely unrelated to any particular test. Just wondering with the totality of your settings, what your cores are boosting to when close-to-idle.


----------



## sp00n82

You could also try the BoostTester in the /tools directory, it produces _very_ light load (unfortunately without any error checking).


----------



## Zslick

Thanks Spoon. I'll try it again (previously it didn't detect anything beyond y-cruncher's detections).

I think the issue I may have going on (that's causing instant Chrome crashes, and sometimes instant reboots) is that my Core 0 is unable to maintain stability at similar Curve Optimizer (CO) levels as all of my other cores. Given as such, because Core 0 has more activity than any other core, it's much more difficult to determine a proper CO level for Core 0. Further, core cycling is unable to detect a proper CO level for Core 0 because of it's inherent higher level of activity. Core 1 to Core 15 are coming in between -12 and -20 in CO, but Core 0 seems to be limited to -8 or worse.

One other thing that tipped me off is only *two *sets of WHEA errors I've encountered over two weeks, in which both pointed towards APIC ID 1 (Core 0).

I believe I may be stuck waiting for idle reboots, and program crashes, because Core 0 is more difficult to test. Does this sound legitimate, and/or does my logic hold? I'm working through the testing and will report back eventually. Unfortunate that it has taken weeks to determine where the issue is (If this ends up being the issue).


----------



## ManniX-ITA

sp00n82 said:


> You could also try the BoostTester in the /tools directory, it produces _very_ light load (unfortunately without any error checking).


Maybe use my custom version of BoostTester, the normal version is unable to trigger the maximum boost clock:









GitHub - mann1x/BoostTesterMannix


Contribute to mann1x/BoostTesterMannix development by creating an account on GitHub.




github.com


----------



## Luggage

Zslick said:


> Thanks Spoon. I'll try it again (previously it didn't detect anything beyond y-cruncher's detections).
> 
> I think the issue I may have going on (that's causing instant Chrome crashes, and sometimes instant reboots) is that my Core 0 is unable to maintain stability at similar Curve Optimizer (CO) levels as all of my other cores. Given as such, because Core 0 has more activity than any other core, it's much more difficult to determine a proper CO level for Core 0. Further, core cycling is unable to detect a proper CO level for Core 0 because of it's inherent higher level of activity. Core 1 to Core 15 are coming in between -12 and -20 in CO, but Core 0 seems to be limited to -8 or worse.
> 
> One other thing that tipped me off is only *two *sets of WHEA errors I've encountered over two weeks, in which both pointed towards APIC ID 1 (Core 0).
> 
> I believe I may be stuck waiting for idle reboots, and program crashes, because Core 0 is more difficult to test. Does this sound legitimate, and/or does my logic hold? I'm working through the testing and will report back eventually. Unfortunate that it has taken weeks to determine where the issue is (If this ends up being the issue).


If core 0 is one of your best a curve like that is not strange at all. The best cores are already running closer to optimal vid so they take less of a co offset.
My best cores are 0 and 5.


http://imgur.com/a/ogI09yn


----------



## Zslick

Great feedback. Thanks @ManniX-ITA will be trying that out.

@Luggage very similar curve to what I'm seeing on my 7950X. How did you work to determine your core 0 limit? Did you have to approach Core 0 differently? Were you ever having issues getting low power/failure data feedback through programs for Core 0? That seems to be my issue currently. I've never had a single failure of any type in P95, y-cruncher, AIDA64 in CoreCycling with Core 0--but have had two WHEA errors on Core 0 over two weeks. Core 0 seems much less responsive to any type of high boost (low utilization) scenarios through Core Cycling or stability testing.


----------



## Zslick

@ManniX-ITA what can be expected in terms of applicable end-user outputs/results from your variation of the program? System reboot; error messages within the UI window; nothing (i.e., program doesn't incite system reboots quickly if there's an issue)? It definitely seems to be working in terms of core activity--I've just yet to see any type of messages/hard reboots in running your version or the original yet.

Suffice to say, I do feel like all of my cores (except 0) are fully stable at this point from extensive y-cruncher 1T 00-x86 testing.


----------



## ManniX-ITA

Zslick said:


> @ManniX-ITA what can be expected in terms of applicable end-user outputs/results from your variation of the program? System reboot; error messages within the UI window; nothing (i.e., program doesn't incite system reboots quickly if there's an issue)? It definitely seems to be working in terms of core activity--I've just yet to see any type of messages/hard reboots in running your version or the original yet.


It's not a stability test indeed; just an extremely light workload to trigger the highest boost clock.
My version is slightly different; it's pausing briefly while switching core giving time to cool down the temperature, the next core is usually adjacent, and it does run a shorter workload followed by a small pause before the longer one.

This because while the workload is very light, the clock goes down 20-50 MHz after the code is running for a few hundreds milliseconds.
With the original, using HWInfo at 500ms pooling time, it's not enough for it to catch the highest clock peak.

The short workload will trigger the clock to the highest possible and the small pause will let HWInfo record the peak, for a little while in idling the core will keep the clock at the top.
When the longer workload runs you can catch what's the core sustained workload clock and how steady can be kept.

It doesn't trigger instability usually, the operation is so simple that hardly can fail.
Only extremely unstable cores can cause a hard reboot, when just going to that clock is enough to crash.


----------



## Zslick

Thanks ManniX! Appreciate you confirming the capabilities of the program, your version, and what to expect.


----------



## Zslick

General question: Has anyone noticed a clear level of causation (or connection) between the Curve Optimizer (CO) setting of one core impacting another core--especially across the two CCDs? Example: Adjust Core 8 from -15 to -20, and then Core 15 starts throwing errors sooner than previously? Or more aggressive adjustments to the 2nd CCD package effects the 1st package?

I think there may be a link between the two #1 performance cores; but for all the other cores, are they definitely independent of each other, or are there potential connections and impacts to stability across different cores' settings?


----------



## Luggage

Zslick said:


> General question: Has anyone noticed a clear level of causation (or connection) between the Curve Optimizer (CO) setting of one core impacting another core--especially across the two CCDs? Example: Adjust Core 8 from -15 to -20, and then Core 15 starts throwing errors sooner than previously? Or more aggressive adjustments to the 2nd CCD package effects the 1st package?
> 
> I think there may be a link between the two #1 performance cores; but for all the other cores, are they definitely independent of each other, or are there potential connections and impacts to stability across different cores' settings?


Not really because if core 15 throws errors I fix it directly… and I only adjust up so I wouldn’t adjust 8 from -15 to -20. _shrug_


----------



## KedarWolf

Zslick said:


> General question: Has anyone noticed a clear level of causation (or connection) between the Curve Optimizer (CO) setting of one core impacting another core--especially across the two CCDs? Example: Adjust Core 8 from -15 to -20, and then Core 15 starts throwing errors sooner than previously? Or more aggressive adjustments to the 2nd CCD package effects the 1st package?
> 
> I think there may be a link between the two #1 performance cores; but for all the other cores, are they definitely independent of each other, or are there potential connections and impacts to stability across different cores' settings?


Yes, I noticed that on my 5950x, if I changed some cores, others I that were previously stable were no longer stable. I had to redo them.


----------



## Zslick

Argh. Thanks for the confirmation Kedar.


----------



## ManniX-ITA

Zslick said:


> General question: Has anyone noticed a clear level of causation (or connection) between the Curve Optimizer (CO) setting of one core impacting another core--especially across the two CCDs? Example: Adjust Core 8 from -15 to -20, and then Core 15 starts throwing errors sooner than previously? Or more aggressive adjustments to the 2nd CCD package effects the 1st package?
> 
> I think there may be a link between the two #1 performance cores; but for all the other cores, are they definitely independent of each other, or are there potential connections and impacts to stability across different cores' settings?


Yes, the worst is when a core (usually one of the lowest quality) is borderline unstable; doesn't drop errors, only rarely, but makes another good core unstable. Wasted a lot of time to this...

Don't know why but if you check and record the VIDs during BoostTester you'll see that changing a CO count on any core will change the VIDs of almost all other cores.
On my 5950X usually 70% of cores are changing applied VID, rest more or less the same.

I apply a strategy of going down all cores by a fixed amount (-4,-6) then run a quick check with 720K and scale back only those who fails.
Then when I have a baseline of stable counts for all cores I scale back -4 all of them just to be sure (more or less) they are maybe not close to be borderline unstable.
Only then I start a deep testing one by one starting from the best cores.
This alleviates the issue and can shorten the calibration time.


----------



## Conradical

Veii said:


> Bit hard to avoid length, when the question/request is on a big unclear/unanswered topic
> Comes over bit rude, defining the way of asking for help
> 
> First important lesson;
> 
> dLDO_Injector will balance global requested VID, up to core requested VID ~ since AGESA 1.1.8.X
> Core requested VID will pass through FIT, in FIT PRE-Voltage limit (usually 50mV higher than the invisible voltage throttle wall)
> 2nd stage , it checks whenever this allowed voltage ~ passes within PPT, THM, TDC, EDC limit. Rather recognizes if amperage of X amount of cores for Y global VID requested ~ passes over set EDC FUSE limit (A)
> later cores frequency target check and so request Z VID by the V/F curve, by the architecture (mind you, every sample has a different range ~ they are not on the same scale)
> 
> What means "unstable" ~ is it;
> 
> *A* core can not hold frequency under AVX ! selected workload (loadline to droopy ?, AVX2 has a fixed voltage drop + loadline droop)
> *B* core is more than capable , but global VID was too low and other bad cores took away too much priority and dLDO ruined boost
> *C* also* B* ~ BUT, higher strap-stepping voltage couldn't be provided, because FIT detected a limit (most likely CCA limit) and had to throttle back
> *D* followup for *C* ~ but the reasoning purely was, because it reached ProcHot limit yet not reaching THM set limit. Soo every 10c it lost 100mhz maximum boost (an issue on 6 cores, but unclear if dual CCD PROCHOT is really accurate & extended) ~ mostly happens on AVX2 loads titled under CCA throttle
> * mostly it's *B* only. Cores are far more than capable but by default are plain simply overvolted soo they reach *C* first. They reach an artificial 1.4v wall by FIT
> (from 1.45 ~ 1.55v wall guys mileage & limit, will vary by CPU "version")
> _soo before they even get the ability to reach potential high clocks - they are throttled back as VID was *too high for FIT*_
> 
> Single Core is crashing ~ Usage;
> 
> if #3 out of 5 (0-5) cores, is unstable ~ then you give this core more negative CO offset (if *C* is the reason. But it's close to always this reason _~the bad core requesting too much VID~_, soo you try this first)
> if #3 continues to crash, you put it back where it was by AMD (values change magnitude, they do not override AMDs binning !) but you give everything around it a negative CO ~ soo dLDO will leave more for this "bad" core (this is now the case *A* in the core being just too hungry and not getting enough voltage ~ but this is very rare and close to never the case, as cores all are binned -/+ 30 CO steps by AMD unless it's an 6 core)
> Core by this time should be stable. If not, you continue in bigger steps. -2 all cores except this one, soo global VID remains identical
> (if scenario *C* is not reached and req vid doesn't surpass FIT-Pre-VID hardlimit)
> At this point you finally should have solved the dropping core issue ~ if the "unstable/drop" was not caused in the first place by being throttled back by reason *C or D *~ by reason FIT, not core quality
> 
> Boost is not reachable, cores are not first stage PPT, TDC, EDC throttled ~ but Strap is applied;
> Cores will be package throttled , but you didn't figure the reason why.
> If they are not PPT, TDC, EDC, THM, FIT-PRE-VID, PROCHOT ~ throttled & all of these 5 are held
> (FIT PRE will drop once prochot limit has reached, systematically and so lower "FIT Limit" systematically ~ which is extended by the scalar but not fully disabled)
> 
> 
> 
> 
> 
> 
> 
> 
> Also if cTDP & Package Power limit in AMD CBS - NBIO , are lifted (i put 400W because it's high enough)
> One event that is still possible , aside from *C *is
> 
> Cores being stable, yet being throttled back (package throttle) mostly belongs to lack of VDD18 rail or lack of VDDG CCD (which also is capable to "crash cores" without it being a VID reason)
> ======================================================
> I'll write next time a more clear tutorial how to work on "Single Core is crashing" scenario
> ~ once Hydra 1.0 (or free public version) has released and users have to experiment "in-windows" with CO limits
> As Hydra will also give you a "diagnosed" BIOS Value ~ field, it makes sense to catch support where it's needed. The scenario where the user extends fixed CO in order to extend V/F curve
> Just remember the quote
> ======================================================
> 
> What people use as a shortcut = -30 all core
> Is to prevent FIT-PRE-V to throttle back. as cores will move below this limit & try to reach the frequency
> What users do not think, is that -30 = -110mV ~ -120mV taken away VID / while Frequency to Voltage strap, will be tried to be set
> Either they
> A ~ reach the strap and have good cores, yet Effective clock never reaches that frequency
> B ~ they pull everything else down, because cores are not capable to run at individual frequency. CCX Delta & CCD Delta are a thing, but under closed disclosure. Cores have to run at the lowest frequency strap one core in the chain runs at ~ unless the core is fully hibernated, but not just idle-suspended
> 
> The "easy mode" is to run a global magnitude of -30 , and just add positive vcore offset till it's stable
> (till the worst core surely has enough voltage & all cores hold fully the peak freq strap)
> Positive vcore offset by VRMs is not detected inside the FIT-PRE-V scale.
> FIT-PRE only checks requested VID , but never supplied voltage
> FIT does check global supplied voltage ~ but their range lies in the 1.55+. Soo it only throttles on the 4th stage (emergency package throttle) if you overdo supplied positive vcore
> * Yet again, this information about the range is not shareable till X user under NDA leaks it and it get's public knowledge
> Sensor max voltages are far higher and bios offset allows to use a +100mV range at least.
> 
> Keep my word that Vermeer samples still have a lot of range in them, and +200 Mhz override ~ as SMNCLK peak, is too low. AMD has to finally free this limiter and allow us back +500Mhz overrides & more CO ranges.
> They should move this only inside AMD OVERCLOCKING ~ soo users are own fault if they have unstable units. Not artificially limit being sub 1.5v.
> 
> EDIT:
> The only reason , users -30 Global-CO passes ~ is because CPUs are binned inside -/+ 30 CO range out of the factory (not always but most of the time posts)
> If higher samples core quality (even bronze) does not pass this - it's reused as lower core sample or fully a single CCD unit with "different" V/F curve
> Dual CCD 6 & 8 core units - generally have a broken V/F curve of their Dual-CCD brothers. Soo often these samples fail to hold AMD's CO range by default, as VID per frequency strap (V/F) is messed up on such (reminder ~ 5600X, 5800X, 5900X, 5950X have different V/F Curve)
> These need generally a bit of positive offset, to fix WHEA #18 issues on stock stock (X1 scalar) without boardpartner cheatery enhancers
> Some users like me, also combine then droopy loadline + positive vcore ~ to as best as possible match Supplied TEL-V with VID-V
> 
> 
> Spoiler: Reused Example


Impeccable advice...ive studied your posts multiple times....any update on that "single core is crashing scenario", Veii?


----------



## Scoty

Ddoes anyone know if PBO2 tuner works with Ryzen 7000?


----------



## KedarWolf

Scoty said:


> Ddoes anyone know if PBO2 tuner works with Ryzen 7000?


It doesn't.


----------



## dspx

Hi everyone. I have started reading this thread, recently got a 5800X. What are best practices and recommended Prime95 settings for testing? I apologize but reading all 1075 posts would last forever.

Thanks in advance!


----------



## KedarWolf

PRIME95 SSE 720-720 FFTs 6 minutes really good at finding errors, plus y-cruncher 00-x86 at 9 minutes good too. Both overnight.


----------



## dspx

KedarWolf said:


> PRIME95 SSE 720-720 FFTs 6 minutes really good at finding errors, plus y-cruncher 00-x86 at 9 minutes good too. Both overnight.


Great, many thanks!

Once I have it stable I guess I should retest with AVX and AVX2, same settings?


----------



## Zslick

Wanted to provide some tips and recommendations after weeks and weeks of on-going CO optimizations for my *7950X*. Here's some key takeaways, and my opinions and insights from what I've gathered as it applies to *7950X*:


Start with CCD1 separately (if you're worried about any type of single core/gaming performance). Reason being: More aggressive negative CO values can be loaded up on CCD1, rather than balancing it across CCD1 and CCD2. There is some type of voltage balancing that happens across both CCDs when applying COs. The more you put into CCD2, the less you can put into CCD1. Max out CCD1 first.
You'll find that certain cores on CCD2 are directly related to the voltages of CCD1. A +/-CO on a particular core(s) on CCD2 will directly impact the sustainable CO of core(s) on CCD1. This is why CCD1 should be maxed out before working on CCD2.
You'll also find that certain cores within CCD1 are directly related to each other. Just because Core 4 fails, doesn't mean it's the core that should be decreased for optimal performance. For example: Core 4 is one of my #1 perfs, and has a direct relationship with my Core 1 (my #7 performer). Therefore, when I get a failure on Core 4, I pull back on the CO for Core 1 because it's a lower performer than my Core 4 (top performer).

Establish absolutely stability (100+ successful runs of "11-SNB ~ Hina" y-cruncher 2-thread) across your perf #1 cores (your two best cores) on CCD1 before doing anything else. I've had failures after 50 successes on one individual core. That's 8.7 minutes * 100 = 14.5 hours per core.
00-x86 1thread y-cruncher will not work for Core 0 in testing for instability. I'd surmise this is because Core 0 has so many background processes always running, and 00-x86 tests closer-to-idle boosting values which is less feasible when background processes are constantly running. Good news is Hina does work (next bullet).
I've found that Hina (the highest AVX-based set without AVX2/AVX-512) is the best for testing. It will land you ~2 values higher (in absolute value) than 00-x86 on CO, and captures everything 00-x86 does and more. This means it tests stability in a strenuous enough capacity to be applicable to both the low and high end vs. 00-x86, and will get you to a value that accounts for any idle instability as well. Other P95/OCCT AVX tests I tried were not capturing idle instability because they weren't strenuous enough; however Hina y-cruncher 2 thread does.
P95 does not capture errors as well as Hina 2-thread.
AVX2 is definitely broken currently on 7950X until AMD pushes AGESA 1.0.0.4 to motherboard vendors for a new BIOS rollout. It generates errors and is not accurate in testing. OCCT AVX2 single core throws thousands of errors instantly (if you are using PBO2 with an AutoOC+), so this is repeatable and obvious. This is why Hina should currently be used.
AVX-512 as a simultaneous all-core test seems to work and behave, but I'm not confident yet if it's a good test for single core based on the bugginess in AMD's AGESA. Single core AVX-512 seemed to error out too quickly. Therefore, I'm just going with AVX since it's applicable to my setup anyhow (no applications I use utilize anything >AVX; and waiting for AMD/ASUS to push a BIOS update so I have more confidence in AVX2/AVX-512).


----------



## sil3nt3

Zslick said:


> Wanted to provide some tips and recommendations after weeks and weeks of on-going CO optimizations for my *7950X*. Here's some key takeaways, and my opinions and insights from what I've gathered as it applies to *7950X*:
> 
> 
> Start with CCD1 separately (if you're worried about any type of single core/gaming performance). Reason being: More aggressive negative CO values can be loaded up on CCD1, rather than balancing it across CCD1 and CCD2. There is some type of voltage balancing that happens across both CCDs when applying COs. The more you put into CCD2, the less you can put into CCD1. Max out CCD1 first.
> You'll find that certain cores on CCD2 are directly related to the voltages of CCD1. A +/-CO on a particular core(s) on CCD2 will directly impact the sustainable CO of core(s) on CCD1. This is why CCD1 should be maxed out before working on CCD2.
> You'll also find that certain cores within CCD1 are directly related to each other. Just because Core 4 fails, doesn't mean it's the core that should be decreased for optimal performance. For example: Core 4 is one of my #1 perfs, and has a direct relationship with my Core 1 (my #7 performer). Therefore, when I get a failure on Core 4, I pull back on the CO for Core 1 because it's a lower performer than my Core 4 (top performer).
> 
> Establish absolutely stability (100+ successful runs of "11-SNB ~ Hina" y-cruncher 2-thread) across your perf #1 cores (your two best cores) on CCD1 before doing anything else. I've had failures after 50 successes on one individual core. That's 8.7 minutes * 100 = 14.5 hours per core.
> 00-x86 1thread y-cruncher will not work for Core 0 in testing for instability. I'd surmise this is because Core 0 has so many background processes always running, and 00-x86 tests closer-to-idle boosting values which is less feasible when background processes are constantly running. Good news is Hina does work (next bullet).
> I've found that Hina (the highest AVX-based set without AVX2/AVX-512) is the best for testing. It will land you ~2 values higher (in absolute value) than 00-x86 on CO, and captures everything 00-x86 does and more. This means it tests stability in a strenuous enough capacity to be applicable to both the low and high end vs. 00-x86, and will get you to a value that accounts for any idle instability as well. Other P95/OCCT AVX tests I tried were not capturing idle instability because they weren't strenuous enough; however Hina y-cruncher 2 thread does.
> P95 does not capture errors as well as Hina 2-thread.
> AVX2 is definitely broken currently on 7950X until AMD pushes AGESA 1.0.0.4 to motherboard vendors for a new BIOS rollout. It generates errors and is not accurate in testing. OCCT AVX2 single core throws thousands of errors instantly (if you are using PBO2 with an AutoOC+), so this is repeatable and obvious. This is why Hina should currently be used.
> AVX-512 as a simultaneous all-core test seems to work and behave, but I'm not confident yet if it's a good test for single core based on the bugginess in AMD's AGESA. Single core AVX-512 seemed to error out too quickly. Therefore, I'm just going with AVX since it's applicable to my setup anyhow (no applications I use utilize anything >AVX; and waiting for AMD/ASUS to push a BIOS update so I have more confidence in AVX2/AVX-512).


thanks for the info i was going crazy with the avx tests and thought my processor was having issues not knowing it needs an agesa update. trying (Hina" y-cruncher 2-thread) but I noticed that the maximum boost frequency stops at 5.6ghz when 1 thread reaches 5.7 so in this way you will never test the stability of the max boost, am I wrong?


----------



## Zslick

You won’t *directly* test stability of max boost with Hina; however, you will indirectly ensure stability of max boost that would happen from other tests because Hina is a more “difficult test”. Hina will get you to more conservative CO values, vs. a test like 00-x86 that will *always* land you at more extreme CO values. The more extreme CO values are only max boost stable in non-AVX applications, but not always AVX stable. Hina will cover all your bases for SSE and AVX (max boost or not).

For example: When I only use 00-x86 1 thread and test to my required benchmark of 100 successful passes per core, I arrive at -30 on core #2 and #3. However for Hina 2 thread to be stable, I arrive at -20 and -21. Hina kills two birds with one stone, and lands me at CO values that will be max boost stable (00-x86), idle load stable, and also full-throttle AVX stable (Hina). Hina for me always results in a more conservative CO value for every single core that covers me in stability up through AVX. It also allows you to test core 0 which 00-x86 can’t accurately do at all (at least in my experience). It also seems far more aggressive than any test I could find in P95, AIDA64, or OCCT, arriving at a more bullet-proof level of stability across the board.

This is just my experience based on now multiple months of trial and error (12 hours a day), exceptionally large sample sizes, and actual end results further correlated against real-world stability. Not theorycraft. My fine tuning is still on-going based on Hina, since I'm having to re-baseline (00-x86 did not capture all of my instability). AVX stability in reality is very important, since programs like Chrome utilize those instruction sets. Running a full repertoire of cycler tests on both 00-x86 and something AVX-based (like Hina) is untenable for most people (from a time perspective), and definitely not worth it once you can prove/show that a test like Hina 2 thread indirectly captures boost stability anyhow.

It also appears ASUS (in the case of my X670E Extreme) has released a new BIOS as of November 16th based on a new AGESA. All I can say here is that performance has not decreased, and it did solve several bugs/issues I was seeing with boot compatibility/issues. So far, it looks like CO values from BIOS 705 will remain true to BIOS 805, not requiring any re-baselining or adjusting (I'll know 100% by tomorrow morning, but right now am 95% confident in that). It does not appear to have fixed the single-core AVX2 errors seen in OCCT, so I'd still be cautious in assuming any type of consistency/reliability exists around AVX2 (and maybe AVX512). I'm still personally only testing for SSE/AVX until I see evidence of AVX2 being fixed. Again for me, I really have no tangible concerns around AVX2/AVX512 yet, since I don't utilize any of those instruction sets in real-world applications anyhow.


----------



## sil3nt3

Zslick said:


> You won’t *directly* test stability of max boost with Hina; however, you will indirectly ensure stability of max boost that would happen from other tests because Hina is a more “difficult test”. Hina will get you to more conservative CO values, vs. a test like 00-x86 that will *always* land you at more extreme CO values. The more extreme CO values are only max boost stable in non-AVX applications, but not always AVX stable. Hina will cover all your bases for SSE and AVX (max boost or not).
> 
> For example: When I only use 00-x86 1 thread and test to my required benchmark of 100 successful passes per core, I arrive at -30 on core #2 and #3. However for Hina 2 thread to be stable, I arrive at -20 and -21. Hina kills two birds with one stone, and lands me at CO values that will be max boost stable (00-x86), idle load stable, and also full-throttle AVX stable (Hina). Hina for me always results in a more conservative CO value for every single core that covers me in stability up through AVX. It also allows you to test core 0 which 00-x86 can’t accurately do at all (at least in my experience). It also seems far more aggressive than any test I could find in P95, AIDA64, or OCCT, arriving at a more bullet-proof level of stability across the board.
> 
> This is just my experience based on now multiple months of trial and error (12 hours a day), exceptionally large sample sizes, and actual end results further correlated against real-world stability. Not theorycraft. My fine tuning is still on-going based on Hina, since I'm having to re-baseline (00-x86 did not capture all of my instability). AVX stability in reality is very important, since programs like Chrome utilize those instruction sets. Running a full repertoire of cycler tests on both 00-x86 and something AVX-based (like Hina) is untenable for most people (from a time perspective), and definitely not worth it once you can prove/show that a test like Hina 2 thread indirectly captures boost stability anyhow.
> 
> It also appears ASUS (in the case of my X670E Extreme) has released a new BIOS as of November 16th based on a new AGESA. All I can say here is that performance has not decreased, and it did solve several bugs/issues I was seeing with boot compatibility/issues. So far, it looks like CO values from BIOS 705 will remain true to BIOS 805, not requiring any re-baselining or adjusting (I'll know 100% by tomorrow morning, but right now am 95% confident in that). It does not appear to have fixed the single-core AVX2 errors seen in OCCT, so I'd still be cautious in assuming any type of consistency/reliability exists around AVX2 (and maybe AVX512). I'm still personally only testing for SSE/AVX until I see evidence of AVX2 being fixed. Again for me, I really have no tangible concerns around AVX2/AVX512 yet, since I don't utilize any of those instruction sets in real-world applications anyhow.


perfect, thank you for the explanation and the advice I will immediately get to work on my curve optimizer 😁


----------



## konawolv

Zslick said:


> Wanted to provide some tips and recommendations after weeks and weeks of on-going CO optimizations for my *7950X*. Here's some key takeaways, and my opinions and insights from what I've gathered as it applies to *7950X*:
> 
> 
> Start with CCD1 separately (if you're worried about any type of single core/gaming performance). Reason being: More aggressive negative CO values can be loaded up on CCD1, rather than balancing it across CCD1 and CCD2. There is some type of voltage balancing that happens across both CCDs when applying COs. The more you put into CCD2, the less you can put into CCD1. Max out CCD1 first.
> You'll find that certain cores on CCD2 are directly related to the voltages of CCD1. A +/-CO on a particular core(s) on CCD2 will directly impact the sustainable CO of core(s) on CCD1. This is why CCD1 should be maxed out before working on CCD2.
> You'll also find that certain cores within CCD1 are directly related to each other. Just because Core 4 fails, doesn't mean it's the core that should be decreased for optimal performance. For example: Core 4 is one of my #1 perfs, and has a direct relationship with my Core 1 (my #7 performer). Therefore, when I get a failure on Core 4, I pull back on the CO for Core 1 because it's a lower performer than my Core 4 (top performer).
> 
> Establish absolutely stability (100+ successful runs of "11-SNB ~ Hina" y-cruncher 2-thread) across your perf #1 cores (your two best cores) on CCD1 before doing anything else. I've had failures after 50 successes on one individual core. That's 8.7 minutes * 100 = 14.5 hours per core.
> 00-x86 1thread y-cruncher will not work for Core 0 in testing for instability. I'd surmise this is because Core 0 has so many background processes always running, and 00-x86 tests closer-to-idle boosting values which is less feasible when background processes are constantly running. Good news is Hina does work (next bullet).
> I've found that Hina (the highest AVX-based set without AVX2/AVX-512) is the best for testing. It will land you ~2 values higher (in absolute value) than 00-x86 on CO, and captures everything 00-x86 does and more. This means it tests stability in a strenuous enough capacity to be applicable to both the low and high end vs. 00-x86, and will get you to a value that accounts for any idle instability as well. Other P95/OCCT AVX tests I tried were not capturing idle instability because they weren't strenuous enough; however Hina y-cruncher 2 thread does.
> P95 does not capture errors as well as Hina 2-thread.
> AVX2 is definitely broken currently on 7950X until AMD pushes AGESA 1.0.0.4 to motherboard vendors for a new BIOS rollout. It generates errors and is not accurate in testing. OCCT AVX2 single core throws thousands of errors instantly (if you are using PBO2 with an AutoOC+), so this is repeatable and obvious. This is why Hina should currently be used.
> AVX-512 as a simultaneous all-core test seems to work and behave, but I'm not confident yet if it's a good test for single core based on the bugginess in AMD's AGESA. Single core AVX-512 seemed to error out too quickly. Therefore, I'm just going with AVX since it's applicable to my setup anyhow (no applications I use utilize anything >AVX; and waiting for AMD/ASUS to push a BIOS update so I have more confidence in AVX2/AVX-512).


I just posted something on this on the Zen 4 thread. AVX2 is busted on Zen 4 currently. Even running tests like 3dmark CPU profile, it will insta crash even moderate CO tunes. Thats because its AVX2.

Sigh.. this is really annoying. Ive never used y-cruncher. I may, again, shelve my CO tune journey until they iron that out.


----------



## Zslick

Just use Core Cycler y-cruncher Hina. If you’re not using AVX2 in real world applications, just don’t worry about it and optimize for AVX only. Once they fix AVX2, hopefully the AVX baselines will match up to AVX2 (thereotically with the correct implementation of clock stretching they could).

But if all else fails, enabling +200 boost, 10x scalar, with no offsets is still a very easy and solid guaranteed option in the interim at the least.


----------



## TMavica

Del


----------



## konawolv

Zslick said:


> Just use Core Cycler y-cruncher Hina. If you’re not using AVX2 in real world applications, just don’t worry about it and optimize for AVX only. Once they fix AVX2, hopefully the AVX baselines will match up to AVX2 (thereotically with the correct implementation of clock stretching they could).
> 
> But if all else fails, enabling +200 boost, 10x scalar, with no offsets is still a very easy and solid guaranteed option in the interim at the least.


The problem is i dont know what out there will use AVX2. Outside of OCing and benchmarking, i only use my computer for things like powershell coding and using RDP and web browsers to access my lab, and then, of course, gaming.

I play mostly COD MW2 and Warzone. I know that COD uses AVX and who knows, maybe AVX2.

EDIT: Seems like it is only AVX. COD supports Sandy Bridge CPUs, which, to my knowledge, dont support AVX2.


----------



## mongoled

What is "HINA" and "00-x86" that is referred to in this thread? Ive been using Y-Cruncher for several years now and have never seen these terms mentioned before. 

If these are the algorithms used for specific tests i.e. Y-Cruncher test 1, test 2 etc, why not call them by the name used in the Y-Cruncher GUI as so others who are not familiar with Y-Cruncher can understand what's being spoken about in a more helpful manner?


----------



## ManniX-ITA

mongoled said:


> If these are the algorithms used for specific tests i.e. Y-Cruncher test 1, test 2 etc, why not call them by the name used in the Y-Cruncher GUI as so others who are not familiar with Y-Cruncher can understand what's being spoken about in a more helpful manner?


You probably forgot 
These are the binaries (implementation of the algos), usually you don't need to select the binary is automatic.
But it's very useful to force testing without using specific instructions with CC.



Code:


# The test modes for y-Cruncher
# See the \test_programs\y-cruncher\Binaries\Tuning.txt file for a detailed explanation
# "00-x86"          - 86/IA-32 since Pentium (BSWAP, CMPXCHG, CPUID, RDTSC, possibly others...)
# "04-P4P"          - SSE, SSE2, SSE3
# "05-A64 ~ Kasumi" - x64, SSE, SSE2, SSE3
# "08-NHM ~ Ushio"  - x64, SSE, SSE2, SSE3, SSSE3, SSE4.1
# "11-SNB ~ Hina"   - x64, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX
# "13-HSW ~ Airi"   - x64, ABM, BMI1, BMI2, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2
# "14-BDW ~ Kurumi" - x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2
# "17-ZN1 ~ Yukina" - x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2
# "19-ZN2 ~ Kagari" - x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2

Curious how this 20-ZN3 is for testing... not optimized for speed could be nice for testing.


----------



## TMavica

Trying 22-ZN4 ~ Kizuna now, 22-ZN4 ~ Kizuna or 11-SNB ~ Hina which is better?


----------



## Zslick

Use Hina for 7950X, because AVX2+ is not stable yet on AMD's current AGESA 1.0.0.3 A+D. If you don't have an 7950X, someone else is probably better to answer.


----------



## Zslick

@sp00n82 is it possible to remove certain tests (e.g., BKT, N32) from y-cruncher core cycles? I attempted to adjust stressTest.cfg in the Binaries folder, but it gets force overwritten upon starting any core cycle.


----------



## sp00n82

Zslick said:


> @sp00n82 is it possible to remove certain tests (e.g., BKT, N32) from y-cruncher core cycles? I attempted to adjust stressTest.cfg in the Binaries folder, but it gets force overwritten upon starting any core cycle.


You would need to go to the Initialize-yCruncher function inside the script and change the $configEntries array variable to not include the tests that you don't want.

I could probably make this configurable sometime in the future.


----------



## Zslick

Thanks @sp00n82 , should of thought to check the .ps1 file as well.

So lines 3142 through 3149 that have the _'beginning and ending single quote' _around the entire lines inclusive of BKT, N32, etc.? I'll try editing later today for sure.

The way it's written almost looks like those lines are commented out (excluded), but I assume any type of text requires single quotes around the entire line and are actually included in the code and not just comments.


----------



## sp00n82

Comments in PowerShell are denoted with a hash sign (#), so yeah, this is a mult-line text variable (more precisely an array of text entries, each line is an entry).


----------



## mongoled

ManniX-ITA said:


> You probably forgot
> These are the binaries (implementation of the algos), usually you don't need to select the binary is automatic.
> But it's very useful to force testing without using specific instructions with CC.
> 
> 
> 
> Code:
> 
> 
> # The test modes for y-Cruncher
> # See the \test_programs\y-cruncher\Binaries\Tuning.txt file for a detailed explanation
> # "00-x86"          - 86/IA-32 since Pentium (BSWAP, CMPXCHG, CPUID, RDTSC, possibly others...)
> # "04-P4P"          - SSE, SSE2, SSE3
> # "05-A64 ~ Kasumi" - x64, SSE, SSE2, SSE3
> # "08-NHM ~ Ushio"  - x64, SSE, SSE2, SSE3, SSSE3, SSE4.1
> # "11-SNB ~ Hina"   - x64, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX
> # "13-HSW ~ Airi"   - x64, ABM, BMI1, BMI2, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2
> # "14-BDW ~ Kurumi" - x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2
> # "17-ZN1 ~ Yukina" - x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2
> # "19-ZN2 ~ Kagari" - x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2
> 
> Curious how this 20-ZN3 is for testing... not optimized for speed could be nice for testing.


Hi!
No, not forgetting, more simple than that, lack of knowledge, so thanks for bringing this to my attention.



Now to investigate, im thinking of changing my 5600X to a 5700G to have something new to play with, before doing so need to research if I can get the single threaded CPU performance of the 5600X with the 5700G


----------



## ManniX-ITA

mongoled said:


> Now to investigate, im thinking of changing my 5600X to a 5700G to have something new to play with, before doing so need to research if I can get the single threaded CPU performance of the 5600X with the 5700G


Hardly, it's weaker than a 5600X.
With a pretty hard OC you can get it to a bit more than stock 5600X.






Micro-Star International Co., Ltd MS-7C02 - Geekbench Browser


Benchmark results for a Micro-Star International Co., Ltd MS-7C02 with an AMD Ryzen 7 5700G processor.



browser.geekbench.com





Don't know the memory controller of the 5700G.
I have a 5600G and it's very very weak.
You can get some decent results, only with some very specific workloads, only if you can get the MCLK in sync at very high clocks, 4400+.
In general, guess because of the caches, most workloads doesn't scale up with MCLK like with the X version.


----------



## mongoled

ManniX-ITA said:


> Hardly, it's weaker than a 5600X.
> With a pretty hard OC you can get it to a bit more than stock 5600X.
> 
> 
> 
> 
> 
> 
> Micro-Star International Co., Ltd MS-7C02 - Geekbench Browser
> 
> 
> Benchmark results for a Micro-Star International Co., Ltd MS-7C02 with an AMD Ryzen 7 5700G processor.
> 
> 
> 
> browser.geekbench.com
> 
> 
> 
> 
> 
> Don't know the memory controller of the 5700G.
> I have a 5600G and it's very very weak.
> You can get some decent results, only with some very specific workloads, only if you can get the MCLK in sync at very high clocks, 4400+.
> In general, guess because of the caches, most workloads doesn't scale up with MCLK like with the X version.


Thanks for your insight.

For sure it wont be easy, Cezanne vs Vermeer.

And as you have said, with my RAM I would hope to be aiming somewhere around that clock, but I have yet to find results for B-die overclocking on 5700g. Most peeps seem to be using over ICs that scale to higher frequencies, seeing that my Bdie can do 4133 stable on this 5600x, I hope that they can keep scaling on 5700G.

Will wait to hear from other peeps before deciding to pull the trigger



With regards to the 5600g, is it also EDC limited ?


----------



## konawolv

thank you @Zslick

I used hina to tune a non AVX2 CO set up.

I found errors immediately that 6+ iterations of p95 avx didnt find.

I was able to game last night without crashes.

It still crashes on 3dmark CPU profile benchmark once it gets down to single thread. But, thats expected based on your findings of having issues with single thread avx2 throwing far too many errors.


----------



## KedarWolf

@sp00n82

With y-cruncher 22-ZN4 ~ Kizuna and I think for other tests too, C17 isn't enabled by default.

I changed the script-corecycler.ps1 to the below to add it.



Code:


$configEntries = @(
        '{'
        '    Action : "StressTest"'
        '    StressTest : {'
        '        AllocateLocally : "true"'
        $coresLine
        $memoryLine
        '        SecondsPerTest : 60'
        '        SecondsTotal : 0'
        '        StopOnError : "true"'
        '        Tests : ['
        '            "BKT"'
        '            "BBP"'
        '            "SFT"'
        '            "FFT"'
        '            "N32"'
        '            "N64"'
        '            "HNT"'
        '            "VST"'
        '            "C17"'
        '        ]'
        '    }'
        '}'
    )

Now I get the below:



Code:


 #   Tag - Test Name               Mem/Thread   Component        CPU------Mem
11   BKT - Basecase + Karatsuba      27.8 KiB   Scalar Integer    -|--------
12   BBP - BBP Digit Extraction        small    AVX512 Float      |---------
13   SFT - Small In-Cache FFT         253 KiB   AVX512 Float      -|--------
14   FFT - Fast Fourier Transform    12.3 MiB   AVX512 Float      ---------|
15   N32 - Classic NTT (32-bit)      12.0 MiB   AVX512 Integer    -------|--
16   N64 - Classic NTT (64-bit)      12.6 MiB   AVX512 Integer    ------|---
17   HNT - Hybrid NTT                12.6 MiB   Mixed Workload    -----|----
18   VST - Vector Transform          12.4 MiB   AVX512 Float      -------|--
19   C17 - Code 17 Experiment        12.5 MiB   AVX512 Mixed      -------|--


----------



## dimkatsv

KedarWolf said:


> With y-cruncher 22-ZN4 ~ Kizuna and I think for other tests too, C17 isn't enabled by default


Can confirm for other tests (well, except one for AVX512 as i cannot run them anyways)
And i wondered why, because C17 is one nasty ##### of a test.


----------



## KedarWolf

Deleted


----------



## sp00n82

Yeah, I left out C17 because originally AVX512 wasn't an option.
Seems I have some work to do.


----------



## dimkatsv

sp00n82 said:


> Yeah, I left out C17 because originally AVX512 wasn't an option.


Isn't C17 not require from you to have AVX512? I do have this one on 5600X as option in y-cruncher for a long time.


----------



## KedarWolf

Replace the files from the zip in the Core Cycler folder for 7000 series CPUs.

It allocates 26.4GB of memory and runs only SFT, HNT, and C17 with AVX512, '22-ZN4 ~ Kizuna', the actual tests that find errors over all others.


----------



## KedarWolf

And here's '11-SNB ~ Hina' with just HNT and C17 for everyone else.


----------



## KedarWolf

@sp00n82

I noticed something watching both Core Cycler windows with y-cruncher. If you set y-cruncher to 9 minutes and have 9 tests run, the 9 tests take some longer than 3 minutes so when Core Cycler changes cores, not all the tests are done. So you'll be on CPU 15 in Core Cycler, but only 10 Interations of the nine tests will have been completed as they are not synced.

Any way to get the script to sync each CPU cycle to when the tests all finish??


----------



## KedarWolf

@sp00n82 

What is the reason for the CPU Power Check code?

I had to remove that code as it pops up sometimes but doesn't seen vital to the actual y-cruncher testing.


----------



## dimkatsv

KedarWolf said:


> Any way to get the script to sync each CPU cycle to when the tests all finish??


Set y-Cruncher to 10 minutes. 
You added new test, it nominal run is 1 minute. So overall you now get 9 tests + headroom instead of 8 tests + headroom.


----------



## KedarWolf

KedarWolf said:


> @sp00n82
> 
> What is the reason for the CPU Power Check code?
> 
> I had to remove that code as it pops up sometimes but doesn't seen vital to the actual y-cruncher testing.


Arrrg! CPU Usage is too low checks driving me insane. The script passes except for that and I can't figure out how to disable it.


----------



## KedarWolf

dimkatsv said:


> Set y-Cruncher to 10 minutes.
> You added new test, it nominal run is 1 minute. So overall you now get 9 tests + headroom instead of 8 tests + headroom.


That doesn't work. You can't keep the CPU Cycle in the first window in sync with the test Interactions cycle in the second window.

I can get it really close by using seconds instead of minutes, but the script needs to be changed so that the CPU Cycle matches the Interactions cycle, not a timed CPU Cycle that never stays in sync.


----------



## sp00n82

@KedarWolf
y-Cruncher has no log output whatsoever, so there's no way to determine if there was an error or how far into the tests it has proceeded.
You could increase the runtime per core to a time with a safe margin and set the restart test program for each core flag, this should make sure that all tests can run through.

The CPU check is there because there's no way for the script to tell if y-Cruncher failed, except for looking at the CPU usage.
The CPU usage uses the Windows Performance Counters, which sadly seems to be very fragile and often breaks out of the blue for no reason whatsoever.
I have a batch file in the /tools directory which tries to fix some common issues with them, but there's no guarantee it will.


----------



## dimkatsv

KedarWolf said:


> You can't keep the CPU Cycle in the first window in sync with the test Interactions cycle in the second window.


Enable "Restart test program for each core" then? I use it every time, and seeming not have any problem with Y-Cruncher
I, personally use Prime95 SSE 72-32768 test. But it is because my AVX instructions are more stable than SSE. . . And Y-Cruncher is less sensitive overall than Prime95 for me... And of course i reset test run for every core, so there would be no random shift
But, tbh, 3-6 hour "quick" tests are really tyring.


----------



## sp00n82

I've just added version 0.9.3.0, which allows you to define the tests that should be performed by y-Cruncher (and also how much memory to use).
So you now can customize this to e.g. include C17. Note that C17 only works for AVX2 and AVX512 workloads though, so an error will be thrown if you try to use it with anything below 13-HSW ~ Airi.

I've also included a new disableCpuUtilizationCheck setting, which if set to 1, will disable the periodic check for the CPU utilization.
You should only use this if you're having problems with this check, as without it there's no way to determine if a stress test program like y-Cruncher is still running (Prime95 creates a log file that includes error messages, so it doesn't require it, but it's still helpful for e.g. immediate program crashes where no log files is generated, etc).
You should also first try to get your Windows Performance Counters up and running before setting this flag, refer to the readme.txt file and the /tools/enable_performance_counter.bat batch file, which may help in this case.

And lastly I've added @ManniX-ITA's version of BoostTester in the /tools folder as well.









Releases · sp00n/corecycler


Stability test script for PBO & Curve Optimizer stability testing on AMD Ryzen processors - sp00n/corecycler




github.com


----------



## KedarWolf

sp00n82 said:


> I've just added version 0.9.3.0, which allows you to define the tests that should be performed by y-Cruncher (and also how much memory to use).
> So you now can customize this to e.g. include C17. Note that C17 only works for AVX2 and AVX512 workloads though, so an error will be thrown if you try to use it with anything below 13-HSW ~ Airi.
> 
> I've also included a new disableCpuUtilizationCheck setting, which if set to 1, will disable the periodic check for the CPU utilization.
> You should only use this if you're having problems with this check, as without it there's no way to determine if a stress test program like y-Cruncher is still running (Prime95 creates a log file that includes error messages, so it doesn't require it, but it's still helpful for e.g. immediate program crashes where no log files is generated, etc).
> You should also first try to get your Windows Performance Counters up and running before setting this flag, refer to the readme.txt file and the /tools/enable_performance_counter.bat batch file, which may help in this case.
> 
> And lastly I've added @ManniX-ITA's version of BoostTester in the /tools folder as well.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Releases · sp00n/corecycler
> 
> 
> Stability test script for PBO & Curve Optimizer stability testing on AMD Ryzen processors - sp00n/corecycler
> 
> 
> 
> 
> github.com


Perfect!! I still get mismatch errors and stuff if cores are unstable with


sp00n82 said:


> I've just added version 0.9.3.0, which allows you to define the tests that should be performed by y-Cruncher (and also how much memory to use).
> So you now can customize this to e.g. include C17. Note that C17 only works for AVX2 and AVX512 workloads though, so an error will be thrown if you try to use it with anything below 13-HSW ~ Airi.
> 
> I've also included a new disableCpuUtilizationCheck setting, which if set to 1, will disable the periodic check for the CPU utilization.
> You should only use this if you're having problems with this check, as without it there's no way to determine if a stress test program like y-Cruncher is still running (Prime95 creates a log file that includes error messages, so it doesn't require it, but it's still helpful for e.g. immediate program crashes where no log files is generated, etc).
> You should also first try to get your Windows Performance Counters up and running before setting this flag, refer to the readme.txt file and the /tools/enable_performance_counter.bat batch file, which may help in this case.
> 
> And lastly I've added @ManniX-ITA's version of BoostTester in the /tools folder as well.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Releases · sp00n/corecycler
> 
> 
> Stability test script for PBO & Curve Optimizer stability testing on AMD Ryzen processors - sp00n/corecycler
> 
> 
> 
> 
> github.com



Perfect!!

I had to delete this from the performance counters .bat file or I'd get need to run as admin even if I ran it as admin or trusted installer.



Code:


:: We need administrator rights
net session >nul 2>&1

if %ErrorLevel% NEQ 0 (
    echo Fatal Error: This script requires administrator privileges!
    pause
    GOTO :EOF
)


----------



## KedarWolf

@sp00n82

Your script in the Tools folder fixed my CPU Utilization problem.

Now I don't need to disable it.

And thanks for being able to choose the memory amount and tests.

I find with y-cruncher just SFT, HNT, and C17 are sufficient and much faster to run.

With that and Prime95 AVX512, I got the below totally stable.


----------



## sil3nt3

KedarWolf said:


> @sp00n82
> 
> Your script in the Tools folder fixed my CPU Utilization problem.
> 
> Now I don't need to disable it.
> 
> And thanks for being able to choose the memory amount and tests.
> 
> I find with y-cruncher just SFT, HNT, and C17 are sufficient and much faster to run.
> 
> With that and Prime95 AVX512, I got the below totally stable.
> 
> View attachment 2585575
> 
> 
> View attachment 2585574


I would also like to try this method, the 14.5h one is really too much :/ how long does ycruncher (1 or 2 thread) SFT, HNT, and C17 run whit 24gb ram per core ? and then Prime95 AVX512 how should I use it? all core or single core? and for how long? thank you


----------



## dimkatsv

sil3nt3 said:


> how long does ycruncher (1 or 2 thread) SFT, HNT, and C17 run whit 24gb ram per core ?


By default with multicore it takes about 2.3 GB per core on 32GB of RAM
And runtime is specified by application that made a call. CoreCycler uses 60 seconds runtime per test


----------



## sil3nt3

dimkatsv said:


> By default with multicore it takes about 2.3 GB per core on 32GB of RAM
> And runtime is specified by application that made a call. CoreCycler uses 60 seconds runtime per test


yes I know I was asking @KedarWolf how he used the tests and for how long to calculate stability.


----------



## dhnguyenit

I have a feeling that yCruncher is not very reliable for AM5. I have been running 17-yukina + C17 for 7 hours and got no errors. Fire up 3DMark stress test and bump, driver crashed, so I had to lower curve again for unstable curves that I found before, then it passed the stress. Fire up my game (POE) and it crashes in 10min. Now I lower CO for all the cores except Core 0 by 5, and it got stable again.


----------



## sil3nt3

dhnguyenit said:


> I have a feeling that yCruncher is not very reliable for AM5. I have been running 17-yukina + C17 for 7 hours and got no errors. Fire up 3DMark stress test and bump, driver crashed, so I had to lower curve again for unstable curves that I found before, then it passed the stress. Fire up my game (POE) and it crashes in 10min. Now I lower CO for all the cores except Core 0 by 5, and it got stable again.


this is because both 3dmark and poe use avx2 which are not stable with zen4 and you have to wait for an agesa update (1.0.0.4?) to fix it.


----------



## dhnguyenit

sil3nt3 said:


> this is because both 3dmark and poe use avx2 which are not stable with zen4 and you have to wait for an agesa update (1.0.0.4?) to fix it.


But when I lower my CO curve, both of them work great again, and 17-yukina has AVX2 included.

# "17-ZN1 ~ Yukina" - x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2


----------



## KedarWolf

sil3nt3 said:


> I would also like to try this method, the 14.5h one is really too much :/ how long does ycruncher (1 or 2 thread) SFT, HNT, and C17 run whit 24gb ram per core ? and then Prime95 AVX512 how should I use it? all core or single core? and for how long? thank you


I use Prime95 AVX512 768-768 FFTs. It finds errors really quick.

One cycle of y-cruncher with just those tests takes about 1 hour and ten minutes. Best to let it run overnight and if you have 32GB of RAM, say use 27GB of memory.

Here is my .cfg for y-cruncher. for Prime95 just change the test type to 'stressTestProgram = PRIME95', it's already set too. I attached the files as well.

Also, run the .bat file as admin, then reboot first.



Code:


# General settings
[General]

# The program to perform the actual stress test
# The following programs are available:
# - PRIME95
# - AIDA64
# - YCRUNCHER
# You can change the test mode for each program in the relavant [sections] below.
# Note: For AIDA64, you need to manually download and extract the portable ENGINEER version and put it
#       in the /test_programs/aida64/ folder
# Note: AIDA64 is somewhat sketchy as well
# Default: PRIME95
stressTestProgram = YCRUNCHER


# Set the runtime per core
# You can define a specific runtime per core, by entering a numeric value in seconds,
# or use 'h' for hours, 'm' for minutes and 's' for seconds
# Examples: 360 = 360 seconds
#           1h4m = 1 hour, 4 minutes
#           1.5m = 1.5 minutes = 90 seconds
#
# Automatic runtime:
# You can also set it to "auto", in which case it will perform one full run of all the FFT sizes in the selected
# Prime95 preset for each core, and when that is finished, it continues to the next core and starts again
# For Aida64 and y-Cruncher, the "auto" setting will default to 10 Minutes per core
#
# Below are some examples of the runtime for one iteration for the various tests on my 5900X with one thread
# The first iteration is also usually the fastest one
# Selecting two threads usually takes *much* longer than one thread for one iteration in Prime95
# - Prime95 "Smallest":     4K to   21K - [SSE] ~3-4 Minutes   <|> [AVX] ~8-9 Minutes    <|> [AVX2] ~8-10 Minutes
# - Prime95 "Small":       36K to  248K - [SSE] ~4-6 Minutes   <|> [AVX] ~14-19 Minutes  <|> [AVX2] ~14-19 Minutes
# - Prime95 "Large":      426K to 8192K - [SSE] ~18-22 Minutes <|> [AVX] ~37-44 Minutes  <|> [AVX2] ~38-51 Minutes
# - Prime95 "Huge":      8960K to   MAX - [SSE] ~13-19 Minutes <|> [AVX] ~27-40 Minutes  <|> [AVX2] ~33-51 Minutes
# - Prime95 "All":          4K to   MAX - [SSE] ~40-65 Minutes <|> [AVX] ~92-131 Minutes <|> [AVX2] ~102-159 Minutes
# - Prime95 "Moderate":  1344K to 4096K - [SSE] ~7-15 Minutes  <|> [AVX] ~17-30 Minutes  <|> [AVX2] ~17-33 Minutes
# - Prime95 "Heavy":        4K to 1344K - [SSE] ~15-28 Minutes <|> [AVX] ~43-68 Minutes  <|> [AVX2] ~47-73 Minutes
# - Prime95 "HeavyShort":   4K to  160K - [SSE] ~6-8 Minutes   <|> [AVX] ~22-24 Minutes  <|> [AVX2] ~23-25 Minutes
# - y-Cruncher: ~10 Minutes
# Default: 6m
runtimePerCore = 6m


# Periodically suspend the stress test program
# This can simulate load changes / switches to idle and back
# Setting this to 1 will periodically suspend the stress test program, wait for a bit, and then resume it
# You should see the CPU load and clock speed drop significantly while the program is suspended and rise back up again
# Note: This will increase the runtime of the various stress tests as seen in the "runtimePerCore" setting by roughly 10%
# Default: 1
suspendPeriodically = 1


# The test order of the cores
# Available modes:
# Default:    On CPUs with more than 8 physical cores: 'Alternate'. Otherwise 'Random'
# Alternate:  Alternate between the 1st core on CCD1, then 1st on CCD2, then 2nd on CCD1, then 2nd on CCD2, etc.
#             This should distribute the heat more evenly and possibly allow for higher clocks on CPUs with 2 CCDs
# Random:     A random order
# Sequential: Cycle through the cores in numerical order
#
# You can also define your own testing order by entering a list of comma separated values.
# The list will be processed as provided, which means you can test the same core multiple times per iteration.
# Do note however that the "coresToIgnore" setting still takes precedence over any core listed here.
# The enumeration of cores starts with 0
# Example: 5, 4, 0, 5, 5, 7, 2
#
# Default: Default
coreTestOrder = 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15


# Skip a core that has thrown an error in the following iterations
# If set to 0, this will test a core in the next iterations even if has thrown an error before
# Default: 1
skipCoreOnError = 0


# Stop the whole testing process if an error occurred
# If set to 0 (default), the stress test programm will be restarted when an error
# occurs and the core that caused the error will be skipped in the next iteration
# Default: 0
stopOnError = 0


# The number of threads to use for testing
# You can only choose between 1 and 2
# If Hyperthreading / SMT is disabled, this will automatically be set to 1
# Currently there's no automatic way to determine which core has thrown an error
# Setting this to 1 causes higher boost clock speed (due to less heat)
# Default: 1
# Maximum: 2
numberOfThreads = 1


# The max number of iterations
# High values are basically unlimited (good for testing over night)
# Default: 10000
maxIterations = 10000


# Ignore certain cores
# Comma separated list of cores that will not be tested
# The enumeration of cores starts with 0
# Example: coresToIgnore = 0, 1, 2
# Default: (empty)
coresToIgnore = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15


# Restart the stress test process when a new core is selected
# This means each core will perform the same sequence of tests during the stress test
# Note: The monitor doesn't seem to turn off when this setting is enabled
#
# Important note:
# One disadvantage of this setting is that it has the potential to limit the amount of tests that the stress test program
# can run.
# In Prime95 for example, each FFT size will run for roughly 1 minute (except for very small ones), so if you want to make
# sure that Prime95 runs all of the available FFT sizes for a setting, you'll have to extend the "runtimePerCore" setting
# from the default value to something higher.
# For example the "Huge"/SSE preset has 19 FFT entries, and tests on my 5900X showed that it roughly takes 13-19 Minutes
# until all FFT sizes have been tested. The "Large"/SSE seems to take between 18 and 22 Minutes.
# I've included the measured times in the comment for the "runtimePerCore" setting above.
#
# If this setting is disabled, there's a relatively high chance that each core will eventually pass through all of the
# FFT sizes since Prime95 doesn't stop between the cores and so it evens out after time.
#
# Default: 0
restartTestProgramForEachCore = 1


# Set a delay between the cores
# If the "restartTestProgramForEachCore" flag is set, this setting will define the amount of seconds between the end of the
# run of one core and the start of another
# If "restartTestProgramForEachCore" is 0, this setting has no effect
# Default: 15
delayBetweenCores = 5


# Debug setting to disable the periodic CPU utilization check
#
# Important:
# Normally you should not need to set this, as it is the only way to determine for certain test programs (like y-Cruncher)
# if the stress test is still running or if there has been an error.
# However on some systems this seems to report incorrect values, which causes the script to throw an error despite
# the stress test program still running fine, so here is a way to disable this behavior.
#
# Note: The check for the CPU utilization uses the Windows Performance Counters, which can be corrupted for unknown
#       reasons. Please see the readme.txt and the /tools/enable_performance_counter.bat file for a possible way
#       to fix these issues. There's no guarantee that it works though.
#
# Default: 0
disableCpuUtilizationCheck = 0




# Prime95 specific settings
[Prime95]

# The test modes for Prime95
# SSE:    lightest load on the processor, lowest temperatures, highest boost clock
# AVX:    medium load on the processor, medium temperatures, medium boost clock
# AVX2:   heavy load on the processor, highest temperatures, lowest boost clock
# AVX512: only available for certain CPUs (Ryzen 7000, some Intel Alder Lake, etc)
# CUSTOM: you can define your own settings for Prime. See the "customs" section further below
# Default: SSE
mode = AVX512


# The FFT size preset to test for Prime95
# These are basically the presets as present in Prime95, plus an additional few
# Note: If "mode" is set to "CUSTOM", this setting will be ignored
# Smallest:     4K to   21K - Prime95 preset text: "tests L1/L2 caches, high power/heat/CPU stress"
# Small:       36K to  248K - Prime95 preset text: "tests L1/L2/L3 caches, maximum power/heat/CPU stress"
# Large:      426K to 8192K - Prime95 preset text: "stresses memory controller and RAM" (although dedicated memory stress testing is disabled here by default!)
# Huge:      8960K to   MAX - anything beginning at 8960K up to the highest FFT size (32768K for SSE/AVX, 51200K for AVX2, 65536K for AVX512)
# All:          4K to   MAX - 4K to up to the highest FFT size (32768K for SSE/AVX, 51200K for AVX2, 65536K for AVX512)
# Moderate:  1344K to 4096K - special preset, recommended in the "Curve Optimizer Guide Ryzen 5000"
# Heavy:        4K to 1344K - special preset, recommended in the "Curve Optimizer Guide Ryzen 5000"
# HeavyShort:   4K to  160K - special preset, recommended in the "Curve Optimizer Guide Ryzen 5000"
#
# You can also define you own range by entering two FFT sizes joined by a hyphen, e.g 36-1344
#
# Default: Huge
FFTSize = 768-768




# Aida64 specific settings
[Aida64]

# The test modes for Aida64
# Note: "RAM" consumes basically all of the available memory and makes the computer pretty slow
#       You can change the amount of RAM being used / tested with the "maxMempory" setting below
# CACHE: Starts Aida64 with the "Cache" stress test
# CPU:   Starts Aida64 with the "CPU" stress test
# FPU:   Starts Aida64 with the "FPU" stress test
# RAM:   Starts Aida64 with the "Memory" stress test
# You can also combine multiple stress tests like so: CACHE,CPU,FPU
# Default: CACHE
mode = CACHE


# Use AVX for Aida64
# This enables or disables the usage of AVX instructions during Aida64's stress tests
# Default: 0
useAVX = 0


# The maximum memory allocation for Aida64
# Sets the maximum memory usage during the "RAM" stress test in percent
# Note: Setting this too high can cause your Windows to slow down to a crawl!
# Default: 90
maxMemory = 90




# y-Cruncher specific settings
[yCruncher]

# The test modes for y-Cruncher
# See the \test_programs\y-cruncher\Binaries\Tuning.txt file for a detailed explanation
# "00-x86"          - 86/IA-32 since Pentium (BSWAP, CMPXCHG, CPUID, RDTSC, possibly others...)
# "04-P4P"          - SSE, SSE2, SSE3
# "05-A64 ~ Kasumi" - x64, SSE, SSE2, SSE3
# "08-NHM ~ Ushio"  - x64, SSE, SSE2, SSE3, SSSE3, SSE4.1
# "11-SNB ~ Hina"   - x64, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX
# "13-HSW ~ Airi"   - x64, ABM, BMI1, BMI2, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2
# "14-BDW ~ Kurumi" - x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2
# "17-ZN1 ~ Yukina" - x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2
# "19-ZN2 ~ Kagari" - x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2
# "20-ZN3 ~ Yuzuki" - x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2
#
# The following settings are available as well, but they seem to be intended for Intel CPUs and don't run on Ryzen 3000/5000 CPUs
# "11-BD1 ~ Miyu"   - x64, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, ABM, FMA4, XOP
# "17-SKX ~ Kotori" - x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2, AVX512-(F/CD/VL/BW/DQ)
# "18-CNL ~ Shinoa" - x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2, AVX512-(F/CD/VL/BW/DQ/IFMA/VBMI)

# The follwing setting is intended for Ryzen 7000 CPUs and doesn't run on Ryzen 3000/5000 CPUs
# "22-ZN4 ~ Kizuna" - x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2, AVX512-(F/CD/VL/BW/DQ/IFMA/VBMI/GFNI)
#
# "00-x86" should produce the highest boost clock on most tests
# "19-ZN2 ~ Kagari" is optimized for Zen 2/3 (Ryzen 3000/5000), but produces more heat and a lower boost clock on most tests
# "22-ZN4 ~ Kizuna" is optimized for Zen 4 (Ryzen 7000) and uses AVX-512 instructions (it will crash if no AVX-512 is supported on your CPU)
# Default: 00-x86
mode = 22-ZN4 ~ Kizuna


# Set the test algorithms to run for y-Cruncher
# y-Crunchers offers various different "tests" that it can run, here you can select which ones
# Tag - Test Name               Component        CPU------Mem
# BKT - Basecase + Karatsuba    Scalar Integer    -|--------
# BBP - BBP Digit Extraction    Floating-Point    |---------    depending on the selected mode uses SSE, AVX, AVX2 or AVX512
# SFT - Small In-Cache FFT      Floating-Point    -|--------    depending on the selected mode uses SSE, AVX, AVX2 or AVX512
# FFT - Fast Fourier Transform  Floating-Point    ---------|    depending on the selected mode uses SSE, AVX, AVX2 or AVX512
# N32 - Classic NTT (32-bit)    Scalar Integer    -----|----    depending on the selected mode uses SSE, AVX, AVX2 or AVX512
# N64 - Classic NTT (64-bit)    Scalar Integer    ---|------    depending on the selected mode uses SSE, AVX, AVX2 or AVX512
# HNT - Hybrid NTT              Mixed Workload    -----|----
# VST - Vector Transform        Floating-Point    ------|---    depending on the selected mode uses SSE, AVX, AVX2 or AVX512
# C17 - Code 17 Experiment      AVX2/512 Mixed    ---|------    depending on the selected mode uses AVX2 or AVX512
#
# Important:
# "C17" (Code 17 Experiment) will only work with a AVX2 and AVX512 workload (so with mode "13-HSW ~ Airi" and above)
#
# Use a comma separated list
# Default: BKT, BBP, SFT, FFT, N32, N64, HNT, VST
tests = C17


# Memory allocation for y-Cruncher
# This allows you to customize the allocated memory for y-Cruncher
# Set the value in bytes (e.g. 1 GiB = 1073741824)
# The default value uses 12.8 MiB for one resp. 25.3 MiB for two threads
#
# Default: Default
memory = 28991029248




# Log specific settings
[Logging]

# The name of the log file
# The "mode" parameter, the selected stress test program and test mode, as well as the start date & time will be
# added to the name, with a .log file ending
# Default: CoreCycler
name = CoreCycler


# Set the log level
# 0: Do not log or display additional information
# 1: Write additional information to the log file (verbose)
# 2: Write even more information to the log file (debug)
# 3: Also display the verbose messages in the terminal
# 4: Also display the debug messages in the terminal
# Default: 2
logLevel = 2




# Custom settings for Prime95
[Custom]


# This needs to be set to 1 for AVX mode
# (and also if you want to set AVX2 below)
CpuSupportsAVX = 0

# This needs to be set to 1 for AVX2 mode
CpuSupportsAVX2 = 0

# This also needs to be set to 1 for AVX2 mode on Ryzen
CpuSupportsFMA3 = 0

# This needs to be set to 1 for AVX512 mode
CpuSupportsAVX512 = 0

# The minimum FFT size to test
# Value for "Smallest FFT":   4
# Value for "Small FFT":     36
# Value for "Large FFT":    426
MinTortureFFT = 4

# The maximum FFT size to test
# Value for "Smallest FFT":   21
# Value for "Small FFT":     248
# Value for "Large FFT":    8192
MaxTortureFFT = 8192

# The amount of memory to use in MB
# 0 = In-Place
TortureMem = 0

# The max amount of minutes for each FFT size during the stress test
# Note: It may be much less than one minute, basically it seems to be "one run or one minute, whichever is less"
TortureTime = 1


----------



## sil3nt3

dhnguyenit said:


> But when I lower my CO curve, both of them work great again, and 17-yukina has AVX2 included.
> 
> # "17-ZN1 ~ Yukina" - x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2


apparently not all tests on avx2/512 crash but only some with the curve set too low 👀



KedarWolf said:


> I use Prime95 AVX512 768-768 FFTs. It finds errors really quick.
> 
> One cycle of y-cruncher with just those tests takes about 1 hour and ten minutes. Best to let it run overnight and if you have 32GB of RAM, say use 27GB of memory.
> 
> Here is my .cfg for y-cruncher. for Prime95 just change the test type to 'stressTestProgram = PRIME95', it's already set too. I attached the files as well.
> 
> Also, run the .bat file as admin, then reboot first.
> 
> 
> 
> Code:
> 
> 
> # General settings
> [General]
> 
> # The program to perform the actual stress test
> # The following programs are available:
> # - PRIME95
> # - AIDA64
> # - YCRUNCHER
> # You can change the test mode for each program in the relavant [sections] below.
> # Note: For AIDA64, you need to manually download and extract the portable ENGINEER version and put it
> #       in the /test_programs/aida64/ folder
> # Note: AIDA64 is somewhat sketchy as well
> # Default: PRIME95
> stressTestProgram = YCRUNCHER
> 
> 
> # Set the runtime per core
> # You can define a specific runtime per core, by entering a numeric value in seconds,
> # or use 'h' for hours, 'm' for minutes and 's' for seconds
> # Examples: 360 = 360 seconds
> #           1h4m = 1 hour, 4 minutes
> #           1.5m = 1.5 minutes = 90 seconds
> #
> # Automatic runtime:
> # You can also set it to "auto", in which case it will perform one full run of all the FFT sizes in the selected
> # Prime95 preset for each core, and when that is finished, it continues to the next core and starts again
> # For Aida64 and y-Cruncher, the "auto" setting will default to 10 Minutes per core
> #
> # Below are some examples of the runtime for one iteration for the various tests on my 5900X with one thread
> # The first iteration is also usually the fastest one
> # Selecting two threads usually takes *much* longer than one thread for one iteration in Prime95
> # - Prime95 "Smallest":     4K to   21K - [SSE] ~3-4 Minutes   <|> [AVX] ~8-9 Minutes    <|> [AVX2] ~8-10 Minutes
> # - Prime95 "Small":       36K to  248K - [SSE] ~4-6 Minutes   <|> [AVX] ~14-19 Minutes  <|> [AVX2] ~14-19 Minutes
> # - Prime95 "Large":      426K to 8192K - [SSE] ~18-22 Minutes <|> [AVX] ~37-44 Minutes  <|> [AVX2] ~38-51 Minutes
> # - Prime95 "Huge":      8960K to   MAX - [SSE] ~13-19 Minutes <|> [AVX] ~27-40 Minutes  <|> [AVX2] ~33-51 Minutes
> # - Prime95 "All":          4K to   MAX - [SSE] ~40-65 Minutes <|> [AVX] ~92-131 Minutes <|> [AVX2] ~102-159 Minutes
> # - Prime95 "Moderate":  1344K to 4096K - [SSE] ~7-15 Minutes  <|> [AVX] ~17-30 Minutes  <|> [AVX2] ~17-33 Minutes
> # - Prime95 "Heavy":        4K to 1344K - [SSE] ~15-28 Minutes <|> [AVX] ~43-68 Minutes  <|> [AVX2] ~47-73 Minutes
> # - Prime95 "HeavyShort":   4K to  160K - [SSE] ~6-8 Minutes   <|> [AVX] ~22-24 Minutes  <|> [AVX2] ~23-25 Minutes
> # - y-Cruncher: ~10 Minutes
> # Default: 6m
> runtimePerCore = 6m
> 
> 
> # Periodically suspend the stress test program
> # This can simulate load changes / switches to idle and back
> # Setting this to 1 will periodically suspend the stress test program, wait for a bit, and then resume it
> # You should see the CPU load and clock speed drop significantly while the program is suspended and rise back up again
> # Note: This will increase the runtime of the various stress tests as seen in the "runtimePerCore" setting by roughly 10%
> # Default: 1
> suspendPeriodically = 1
> 
> 
> # The test order of the cores
> # Available modes:
> # Default:    On CPUs with more than 8 physical cores: 'Alternate'. Otherwise 'Random'
> # Alternate:  Alternate between the 1st core on CCD1, then 1st on CCD2, then 2nd on CCD1, then 2nd on CCD2, etc.
> #             This should distribute the heat more evenly and possibly allow for higher clocks on CPUs with 2 CCDs
> # Random:     A random order
> # Sequential: Cycle through the cores in numerical order
> #
> # You can also define your own testing order by entering a list of comma separated values.
> # The list will be processed as provided, which means you can test the same core multiple times per iteration.
> # Do note however that the "coresToIgnore" setting still takes precedence over any core listed here.
> # The enumeration of cores starts with 0
> # Example: 5, 4, 0, 5, 5, 7, 2
> #
> # Default: Default
> coreTestOrder = 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
> 
> 
> # Skip a core that has thrown an error in the following iterations
> # If set to 0, this will test a core in the next iterations even if has thrown an error before
> # Default: 1
> skipCoreOnError = 0
> 
> 
> # Stop the whole testing process if an error occurred
> # If set to 0 (default), the stress test programm will be restarted when an error
> # occurs and the core that caused the error will be skipped in the next iteration
> # Default: 0
> stopOnError = 0
> 
> 
> # The number of threads to use for testing
> # You can only choose between 1 and 2
> # If Hyperthreading / SMT is disabled, this will automatically be set to 1
> # Currently there's no automatic way to determine which core has thrown an error
> # Setting this to 1 causes higher boost clock speed (due to less heat)
> # Default: 1
> # Maximum: 2
> numberOfThreads = 1
> 
> 
> # The max number of iterations
> # High values are basically unlimited (good for testing over night)
> # Default: 10000
> maxIterations = 10000
> 
> 
> # Ignore certain cores
> # Comma separated list of cores that will not be tested
> # The enumeration of cores starts with 0
> # Example: coresToIgnore = 0, 1, 2
> # Default: (empty)
> coresToIgnore = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
> 
> 
> # Restart the stress test process when a new core is selected
> # This means each core will perform the same sequence of tests during the stress test
> # Note: The monitor doesn't seem to turn off when this setting is enabled
> #
> # Important note:
> # One disadvantage of this setting is that it has the potential to limit the amount of tests that the stress test program
> # can run.
> # In Prime95 for example, each FFT size will run for roughly 1 minute (except for very small ones), so if you want to make
> # sure that Prime95 runs all of the available FFT sizes for a setting, you'll have to extend the "runtimePerCore" setting
> # from the default value to something higher.
> # For example the "Huge"/SSE preset has 19 FFT entries, and tests on my 5900X showed that it roughly takes 13-19 Minutes
> # until all FFT sizes have been tested. The "Large"/SSE seems to take between 18 and 22 Minutes.
> # I've included the measured times in the comment for the "runtimePerCore" setting above.
> #
> # If this setting is disabled, there's a relatively high chance that each core will eventually pass through all of the
> # FFT sizes since Prime95 doesn't stop between the cores and so it evens out after time.
> #
> # Default: 0
> restartTestProgramForEachCore = 1
> 
> 
> # Set a delay between the cores
> # If the "restartTestProgramForEachCore" flag is set, this setting will define the amount of seconds between the end of the
> # run of one core and the start of another
> # If "restartTestProgramForEachCore" is 0, this setting has no effect
> # Default: 15
> delayBetweenCores = 5
> 
> 
> # Debug setting to disable the periodic CPU utilization check
> #
> # Important:
> # Normally you should not need to set this, as it is the only way to determine for certain test programs (like y-Cruncher)
> # if the stress test is still running or if there has been an error.
> # However on some systems this seems to report incorrect values, which causes the script to throw an error despite
> # the stress test program still running fine, so here is a way to disable this behavior.
> #
> # Note: The check for the CPU utilization uses the Windows Performance Counters, which can be corrupted for unknown
> #       reasons. Please see the readme.txt and the /tools/enable_performance_counter.bat file for a possible way
> #       to fix these issues. There's no guarantee that it works though.
> #
> # Default: 0
> disableCpuUtilizationCheck = 0
> 
> 
> 
> 
> # Prime95 specific settings
> [Prime95]
> 
> # The test modes for Prime95
> # SSE:    lightest load on the processor, lowest temperatures, highest boost clock
> # AVX:    medium load on the processor, medium temperatures, medium boost clock
> # AVX2:   heavy load on the processor, highest temperatures, lowest boost clock
> # AVX512: only available for certain CPUs (Ryzen 7000, some Intel Alder Lake, etc)
> # CUSTOM: you can define your own settings for Prime. See the "customs" section further below
> # Default: SSE
> mode = AVX512
> 
> 
> # The FFT size preset to test for Prime95
> # These are basically the presets as present in Prime95, plus an additional few
> # Note: If "mode" is set to "CUSTOM", this setting will be ignored
> # Smallest:     4K to   21K - Prime95 preset text: "tests L1/L2 caches, high power/heat/CPU stress"
> # Small:       36K to  248K - Prime95 preset text: "tests L1/L2/L3 caches, maximum power/heat/CPU stress"
> # Large:      426K to 8192K - Prime95 preset text: "stresses memory controller and RAM" (although dedicated memory stress testing is disabled here by default!)
> # Huge:      8960K to   MAX - anything beginning at 8960K up to the highest FFT size (32768K for SSE/AVX, 51200K for AVX2, 65536K for AVX512)
> # All:          4K to   MAX - 4K to up to the highest FFT size (32768K for SSE/AVX, 51200K for AVX2, 65536K for AVX512)
> # Moderate:  1344K to 4096K - special preset, recommended in the "Curve Optimizer Guide Ryzen 5000"
> # Heavy:        4K to 1344K - special preset, recommended in the "Curve Optimizer Guide Ryzen 5000"
> # HeavyShort:   4K to  160K - special preset, recommended in the "Curve Optimizer Guide Ryzen 5000"
> #
> # You can also define you own range by entering two FFT sizes joined by a hyphen, e.g 36-1344
> #
> # Default: Huge
> FFTSize = 768-768
> 
> 
> 
> 
> # Aida64 specific settings
> [Aida64]
> 
> # The test modes for Aida64
> # Note: "RAM" consumes basically all of the available memory and makes the computer pretty slow
> #       You can change the amount of RAM being used / tested with the "maxMempory" setting below
> # CACHE: Starts Aida64 with the "Cache" stress test
> # CPU:   Starts Aida64 with the "CPU" stress test
> # FPU:   Starts Aida64 with the "FPU" stress test
> # RAM:   Starts Aida64 with the "Memory" stress test
> # You can also combine multiple stress tests like so: CACHE,CPU,FPU
> # Default: CACHE
> mode = CACHE
> 
> 
> # Use AVX for Aida64
> # This enables or disables the usage of AVX instructions during Aida64's stress tests
> # Default: 0
> useAVX = 0
> 
> 
> # The maximum memory allocation for Aida64
> # Sets the maximum memory usage during the "RAM" stress test in percent
> # Note: Setting this too high can cause your Windows to slow down to a crawl!
> # Default: 90
> maxMemory = 90
> 
> 
> 
> 
> # y-Cruncher specific settings
> [yCruncher]
> 
> # The test modes for y-Cruncher
> # See the \test_programs\y-cruncher\Binaries\Tuning.txt file for a detailed explanation
> # "00-x86"          - 86/IA-32 since Pentium (BSWAP, CMPXCHG, CPUID, RDTSC, possibly others...)
> # "04-P4P"          - SSE, SSE2, SSE3
> # "05-A64 ~ Kasumi" - x64, SSE, SSE2, SSE3
> # "08-NHM ~ Ushio"  - x64, SSE, SSE2, SSE3, SSSE3, SSE4.1
> # "11-SNB ~ Hina"   - x64, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX
> # "13-HSW ~ Airi"   - x64, ABM, BMI1, BMI2, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2
> # "14-BDW ~ Kurumi" - x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2
> # "17-ZN1 ~ Yukina" - x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2
> # "19-ZN2 ~ Kagari" - x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2
> # "20-ZN3 ~ Yuzuki" - x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2
> #
> # The following settings are available as well, but they seem to be intended for Intel CPUs and don't run on Ryzen 3000/5000 CPUs
> # "11-BD1 ~ Miyu"   - x64, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, ABM, FMA4, XOP
> # "17-SKX ~ Kotori" - x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2, AVX512-(F/CD/VL/BW/DQ)
> # "18-CNL ~ Shinoa" - x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2, AVX512-(F/CD/VL/BW/DQ/IFMA/VBMI)
> 
> # The follwing setting is intended for Ryzen 7000 CPUs and doesn't run on Ryzen 3000/5000 CPUs
> # "22-ZN4 ~ Kizuna" - x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2, AVX512-(F/CD/VL/BW/DQ/IFMA/VBMI/GFNI)
> #
> # "00-x86" should produce the highest boost clock on most tests
> # "19-ZN2 ~ Kagari" is optimized for Zen 2/3 (Ryzen 3000/5000), but produces more heat and a lower boost clock on most tests
> # "22-ZN4 ~ Kizuna" is optimized for Zen 4 (Ryzen 7000) and uses AVX-512 instructions (it will crash if no AVX-512 is supported on your CPU)
> # Default: 00-x86
> mode = 22-ZN4 ~ Kizuna
> 
> 
> # Set the test algorithms to run for y-Cruncher
> # y-Crunchers offers various different "tests" that it can run, here you can select which ones
> # Tag - Test Name               Component        CPU------Mem
> # BKT - Basecase + Karatsuba    Scalar Integer    -|--------
> # BBP - BBP Digit Extraction    Floating-Point    |---------    depending on the selected mode uses SSE, AVX, AVX2 or AVX512
> # SFT - Small In-Cache FFT      Floating-Point    -|--------    depending on the selected mode uses SSE, AVX, AVX2 or AVX512
> # FFT - Fast Fourier Transform  Floating-Point    ---------|    depending on the selected mode uses SSE, AVX, AVX2 or AVX512
> # N32 - Classic NTT (32-bit)    Scalar Integer    -----|----    depending on the selected mode uses SSE, AVX, AVX2 or AVX512
> # N64 - Classic NTT (64-bit)    Scalar Integer    ---|------    depending on the selected mode uses SSE, AVX, AVX2 or AVX512
> # HNT - Hybrid NTT              Mixed Workload    -----|----
> # VST - Vector Transform        Floating-Point    ------|---    depending on the selected mode uses SSE, AVX, AVX2 or AVX512
> # C17 - Code 17 Experiment      AVX2/512 Mixed    ---|------    depending on the selected mode uses AVX2 or AVX512
> #
> # Important:
> # "C17" (Code 17 Experiment) will only work with a AVX2 and AVX512 workload (so with mode "13-HSW ~ Airi" and above)
> #
> # Use a comma separated list
> # Default: BKT, BBP, SFT, FFT, N32, N64, HNT, VST
> tests = C17
> 
> 
> # Memory allocation for y-Cruncher
> # This allows you to customize the allocated memory for y-Cruncher
> # Set the value in bytes (e.g. 1 GiB = 1073741824)
> # The default value uses 12.8 MiB for one resp. 25.3 MiB for two threads
> #
> # Default: Default
> memory = 28991029248
> 
> 
> 
> 
> # Log specific settings
> [Logging]
> 
> # The name of the log file
> # The "mode" parameter, the selected stress test program and test mode, as well as the start date & time will be
> # added to the name, with a .log file ending
> # Default: CoreCycler
> name = CoreCycler
> 
> 
> # Set the log level
> # 0: Do not log or display additional information
> # 1: Write additional information to the log file (verbose)
> # 2: Write even more information to the log file (debug)
> # 3: Also display the verbose messages in the terminal
> # 4: Also display the debug messages in the terminal
> # Default: 2
> logLevel = 2
> 
> 
> 
> 
> # Custom settings for Prime95
> [Custom]
> 
> 
> # This needs to be set to 1 for AVX mode
> # (and also if you want to set AVX2 below)
> CpuSupportsAVX = 0
> 
> # This needs to be set to 1 for AVX2 mode
> CpuSupportsAVX2 = 0
> 
> # This also needs to be set to 1 for AVX2 mode on Ryzen
> CpuSupportsFMA3 = 0
> 
> # This needs to be set to 1 for AVX512 mode
> CpuSupportsAVX512 = 0
> 
> # The minimum FFT size to test
> # Value for "Smallest FFT":   4
> # Value for "Small FFT":     36
> # Value for "Large FFT":    426
> MinTortureFFT = 4
> 
> # The maximum FFT size to test
> # Value for "Smallest FFT":   21
> # Value for "Small FFT":     248
> # Value for "Large FFT":    8192
> MaxTortureFFT = 8192
> 
> # The amount of memory to use in MB
> # 0 = In-Place
> TortureMem = 0
> 
> # The max amount of minutes for each FFT size during the stress test
> # Note: It may be much less than one minute, basically it seems to be "one run or one minute, whichever is less"
> TortureTime = 1



Thanks, first i try with prime95 or with ycruncher ? and only tests = C17 for yc in settings?


----------



## KedarWolf

sil3nt3 said:


> apparently not all tests on avx2/512 crash but only some with the curve set too low 👀
> 
> 
> 
> 
> Thanks, first i try with prime95 or with ycruncher ? and only tests = C17 for yc in settings?


You need a 7000 series CPU to use AVX512 though.


----------



## sil3nt3

KedarWolf said:


> You need a 7000 series CPU to use AVX512 though.


7950x and asus hero x670e here


----------



## KedarWolf

See the previous post, I had the y-cruncher setting wrong, fixed it with the new .txt.


----------



## sp00n82

KedarWolf said:


> coreTestOrder = 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15


Note that with this explicit setting, CPUs with less than 16 cores will throw an error once it exceeds its maximum core number.
If you want to just do a sequential run anyway (i.e. 0, 1, 2, ...), just use Sequential as the setting here.

Of course it might be set up this way so that you can remove cores that you treat as stable quickly, and that's fine, just be aware of the above caveat when sharing/using such configs. It would suck if your over-night run ended early because it threw a fatal error because of this.


// Edit
Also I just noticed that you have a lot of cores on the coresToIgnore list, so anyone using your config will have to change this list as well first.


----------



## KedarWolf

sp00n82 said:


> Note that with this explicit setting, CPUs with less than 16 cores will throw an error once it exceeds its maximum core number.
> If you want to just do a sequential run anyway (i.e. 0, 1, 2, ...), just use Sequential as the setting here.
> 
> Of course it might be set up this way so that you can remove cores that you treat as stable quickly, and that's fine, just be aware of the above caveat when sharing/using such configs. It would suck if your over-night run ended early because it threw a fatal error because of this.
> 
> 
> // Edit
> Also I just noticed that you have a lot of cores on the coresToIgnore list, so anyone using your config will have to change this list as well first.


I fixed the lists and reattached them to the posts.

I forgot I had cores ignored that never failed on multiple runs so was only testing the cores that did fail.

When I'm done testing only those few cores, I let y-cruncher run overnight, all cores, one night, then Prime95 the next night.


----------



## re23071998

I have ryzen 5 5500 + asrock a320m-hdv.
will there be any support for pbo2 tuner?


----------



## dimkatsv

re23071998 said:


> I have ryzen 5 5500 + asrock a320m-hdv.
> will there be any support for pbo2 tuner?


Do you have PBO settings available in BIOS? 
I thought 5500 is locked chip. And especially on base tier mobo it might not be possible if it cannot be done through BIOS.


----------



## re23071998

dimkatsv said:


> Do you have PBO settings available in BIOS?
> I thought 5500 is locked chip. And especially on base tier mobo it might not be possible if it cannot be done through BIOS.


yea i dont have any of those in bios.
cpu itself is unlocked, and this mobo had oc feature before until the bios got updated (which i have to do, so that i can use this cpu, unfortunately)

im only interested in undervolting.
hope theres is a way to do it just like any intel cpu with throtlestop.


----------



## dimkatsv

re23071998 said:


> im only interested in undervolting.


Try to use vcore offset, then, i suppose?


----------



## re23071998

dimkatsv said:


> Try to use vcore offset, then, i suppose?


which tool to use?


----------



## sp00n82

re23071998 said:


> which tool to use?


VCore offset is done in the BIOS (if it supports it).
Maybe PBO2 Tuner could work as well, I think this is the latest version:








5800X3D Owners


========================= UPDATE: fixed in Debug-CLI.7z this is the last version? is it recommend to use LLC (to negate vdrop)?




www.overclock.net


----------



## re23071998

sp00n82 said:


> VCore offset is done in the BIOS (if it supports it).
> Maybe PBO2 Tuner could work as well, I think this is the latest version:
> 
> 
> 
> 
> 
> 
> 
> 
> 5800X3D Owners
> 
> 
> ========================= UPDATE: fixed in Debug-CLI.7z this is the last version? is it recommend to use LLC (to negate vdrop)?
> 
> 
> 
> 
> www.overclock.net


as i said before, theres no oc options in the bios.

i have tried pbo2 tuner -30 all cores, applied.
but i dont think it changed anything. voltage is still the same in hwinfo


----------



## dimkatsv

re23071998 said:


> i have tried pbo2 tuner -30 all cores, applied.
> but i dont think it changed anything. voltage is still the same in hwinfo


Well... Again, If BIOS doesn't support it, you won't be able to change it.
Only thing you can try to do is VCore offset. But it should be under voltages list setup, not anything else. For me it isn't even listed under OC tab


----------



## ManuDibango

Hey guys, 
I've been using PBO2 Tuner on my 5800x3D, works like a charm. One aspect keeps me wondering... 
I'm new around here, so forgive the naive question: 
does anyone know what's inside the PBO2 tuner software ? Is it from a github repo ? sources ? (does it contain a Trojan ? )
I hope not to offend anyone, but I think the point matters ... 
Cheers, 
Manu


----------



## dimkatsv

ManuDibango said:


> does anyone know what's inside the PBO2 tuner software ? Is it from a github repo ? sources ? (does it contain a Trojan ? )


You can check it with VirusTotal if you are that worried. It is locally sourced tool.
For how long it exists, if it contains virus, VirusTotal would've gotten it sorted out


Spoiler


----------



## ManuDibango

dimkatsv said:


> You can check it with VirusTotal if you are that worried. It is locally sourced tool.
> For how long it exists, if it contains virus, VirusTotal would've gotten it sorted out
> ...


Thanks for the reply and screens. I did not know VirusTotal, interesting !
I did not intend to challenge the author who helped so many people, but still wanted to ask if anyone had spent some time considering this security aspect, since it is not open source. It was AFAIK not openly shared, what are the contents / API / libraries used.
For sure I have also scanned the binaries before using it


----------



## sp00n82

In at least the debug version you can see the libraries it uses.
The biggest one is the JSON library (which you could replace with your own downloaded version I guess) and the main library is the ZenStates-Core.dll, which is probably this one: GitHub - irusanov/ZenStates-Core: ZenStates-Core

The .exe itself is pretty small, probably too small to carry any additional malicious payload. It could potentially include a downloader to get any such stuff, but there are also tools available that scan such files for any outgoing connections (I think VirusTotal also has a tab for this).


----------



## sp00n82

Btw, in the commit list for the ZenStates library repository I've seen a couple of commits regarding Zen4 (Raphael), so maybe building the dll from the current repository (not the latest release, that's from May) and overwriting the ZenStates-Core.dll file in the PBO2 Tuner directory could enable support on Ryzen 7000 as well.
It's a long shot but maybe worth a try.


----------



## KedarWolf

sp00n82 said:


> Btw, in the commit list for the ZenStates library repository I've seen a couple of commits regarding Zen4 (Raphael), so maybe building the dll from the current repository (not the latest release, that's from May) and overwriting the ZenStates-Core.dll file in the PBO2 Tuner directory could enable support on Ryzen 7000 as well.
> It's a long shot but maybe worth a try.


I have the newest beta downloaded from the Zen Timings Discord. I'm on my way home from work now, will try.


----------



## AlderaaN

KedarWolf said:


> I have the newest beta downloaded from the Zen Timings Discord. I'm on my way home from work now, will try.


Hello,
Had any luck with it?


----------



## KedarWolf

AlderaaN said:


> Hello,
> Had any luck with it?


VDIMM and VDDQ wrong, other than that it's nearly perfect.


----------



## AlderaaN

Zslick said:


> Wanted to provide some tips and recommendations after weeks and weeks of on-going CO optimizations for my *7950X*. .
> 
> P95 does not capture errors as well as Hina 2-thread.
> 
> AVX2 is definitely broken currently on 7950X until AMD pushes AGESA 1.0.0.4 to motherboard vendors for a new BIOS rollout. It generates errors and is not accurate in testing. OCCT AVX2 single core throws thousands of errors instantly (if you are using PBO2 with an AutoOC+), so this is repeatable and obvious. This is why Hina should currently be used.
> AVX-512 as a simultaneous all-core test seems to work and behave, but I'm not confident yet if it's a good test for single core based on the bugginess in AMD's AGESA. Single core AVX-512 seemed to error out too quickly. Therefore, I'm just going with AVX since it's applicable to my setup anyhow (no applications I use utilize anything >AVX; and waiting for AMD/ASUS to push a BIOS update so I have more confidence in AVX2/AVX-512).


Following Shamino's post of BIOS 0902, which seems to include AGESA AM5 PI v1.0.0.4, have you had any success with AVX2/AVX512 y-cruncher workloads above "HINA" ?

Thanks!


----------



## sil3nt3

AlderaaN said:


> Following Shamino's post of BIOS 0902, which seems to include AGESA AM5 PI v1.0.0.4, have you had any success with AVX2/AVX512 y-cruncher workloads above "HINA" ?
> 
> Thanks!


7950X Asus Hero X670E On 902 BIOS AGESA AM5 PI 1.0.0.4 (RAM DEF NO XMP For Safety)

Quick Test On My Bad Core (1) With Medium Load Boostit (LLC 5)

CoreCycler 0.9.3.0 Hina AVX -20 10MiN (PASS)
CoreCycler 0.9.3.0 Kizuna AVX512 Curve -18 10MiN (PASS)
CoreCycler 0.9.3.0 Kagari AVX2 -10 10MiN Reboot/Blue Screen WatchDog/Freeze (2MiN FAIL BBP TEST)
CoreCycler 0.9.3.0 Kagari AVX2 -0 10MiN Reboot/Blue Screen WatchDog/Freeze (2MiN FAIL BBP TEST)

Quick Test On My Bad Core (1) Without Medium Load Boostit (LLC 5)

CoreCycler 0.9.3.0 Hina AVX -20 10MiN (PASS)
CoreCycler 0.9.3.0 Kizuna AVX512 Curve -18 10MiN (PASS)
CoreCycler 0.9.3.0 Kagari AVX2 -10 10MiN Reboot/Blue Screen WatchDog/Freeze (3MiN FAIL SFT TEST)
CoreCycler 0.9.3.0 Kagari AVX2 -0 10MiN Reboot/Blue Screen WatchDog/Freeze (3MiN FAIL BBP TEST)

Quick Test On My Bad Core (1) Bios Default PBO/MediumLoadBoostit Disable (4.5GHZ)

CoreCycler 0.9.3.0 Kagari AVX2 -0 10MiN (PASS)

If There's A Problem, I Don't Think They've Fixed It...


----------



## sp00n82

sp00n82 said:


> Btw, in the commit list for the ZenStates library repository I've seen a couple of commits regarding Zen4 (Raphael), so maybe building the dll from the current repository (not the latest release, that's from May) and overwriting the ZenStates-Core.dll file in the PBO2 Tuner directory could enable support on Ryzen 7000 as well.
> It's a long shot but maybe worth a try.


The latest official ZenStates release now apparently has Zen4 (Raphael) support.








Release v1.6.7 · irusanov/ZenStates-Core


Raphael support Full Changelog: v1.6.6...v.1.6.7




github.com


----------



## zosh_4389

Saiger0 said:


> wing arguments "-30 -30 -30 -30 -30 -30 -30 -30 95 60 90


I tried doing the same but when I got to start PBO2 on start up but its asking for a password. How do I get round this? Do you know?


----------



## streetTV

bro can you just make a option to load it on windows startup. **** man


----------



## Saiger0

zosh_4389 said:


> I tried doing the same but when I got to start PBO2 on start up but its asking for a password. How do I get round this? Do you know?


I believe you have to enable the following settings: (sry its in german just follow it by eye)


----------



## Frosted racquet

@sp00n82 I have a weird issue, was wondering if you or anyone else reading this have seen this?
CoreCycler is always crashing windows when testing core 6 according to its logs, but Event Viewer has core 0 WHEA 18 Bus/Interconnect error logged instead of core 6.
When I set all cores' CO to 0, it doesn't crash in 10h testing with CoreCycler. When core 0 is set to 0 CO and the rest to -30 I crash, but now that I have decreased the core 6 undervolt and others to -30 things seem to be more stable.

During testing, I can see Core 0 also experiencing slight load from YCruncher, maybe that's why Windows gets confused?
Why is Windows blaming Core 0 when according to CoreCycler it's core 6 that was being tested when the crash occurred?
Is WHEA 18 Bus/Interconnect related to aggressive CO or can it be Memory Controller related? I seem to remember that I was only getting Cache Hierarchy errors before
Thanks


----------



## blackie

sil3nt3 said:


> this is because both 3dmark and poe use avx2 which are not stable with zen4 and you have to wait for an agesa update (1.0.0.4?) to fix it.


Could you please confirm if PoE means "Path of Exile"? I have just installed the game just to TEST my CPU and ... played 8 hours straight, it's very addictive. And my 7700x runs without problems.


----------



## dhnguyenit

blackie said:


> Could you please confirm if PoE means "Path of Exile"? I have just installed the game just to TEST my CPU and ... played 8 hours straight, it's very addictive. And my 7700x runs without problems.


Yeah POE = PathOfExile
My cpu with CO 10-30 passed the CoreCyler but restart when playing it. I’m now running with CO -10 all cores instead, no problem, but I will upgrade to 7800X3D.


----------



## blackie

Thanks. I have problems to get my Kingston Fury Renegade 6000CL32 (KF560C32RSK2-32) stable with XMP profiles except [email protected] on Asus B650E-F(0821 bios).
Waiting for a BIOS update to improve stability on 6000CL32 XMP profile.
On 48000CL38 XMP profile my 7700x is CoreCycler/PoE stable with CO -30, 3DMark stable with CO -8.


----------



## gvansly1

ManniX-ITA said:


> As far as I know there's still the VID limit to 1.425V above 140A EDC.
> It does hurt dramatically performances in MT (clocks are higher of course due to the low power).
> Unless there's a specific reason (like the tFPM stuttering bug fix for Win11), better to run lower than 1.2.0.4.


Manni... I know this is an old post, but nonetheless, which VID limit, how do I test and what do I look for to see if I have this issue. Thanks


----------



## Talos7

Any suggestions on good PPT and other values for better thermals, others than the -30 curve ?
still around 80 with 5600x :/


----------



## Kaliz

Talos7 said:


> Any suggestions on good PPT and other values for better thermals, others than the -30 curve ?
> still around 80 with 5600x :/


95W 75A 110A.


----------

