Hello guys again,
any advice what to set differently?
any advice what to set differently?
I'm going to disable Bank Group Swap and Gear down mode just to see what would happen with the 2933 MHz.My mismatched 48GB RAM kit (4 sticks) with my Ryzen 1600 and Asrock B450m Pro4 (1.40V DRAM limitation by the board)
The motherboard uses a daisy chain topography for the memory slots. I put the 3600 MHz kit in the "slower" slots.
Currently the 2933 MHz at 16-18-18-36-54 timing with T1 command rate + Gear Down Mode + Power Down Mode + Bank Group Swap on auto + BGS alt on auto is stable after running memtesthelper for about 36 hours.
At 3000 MHz, it was stable for about 12 hours, and then when I restarted to computer and ran the memtesthelper again, it threw a memory error in a few minutes. 3133 MHz throws errors almost as soon as I start the stability test.
I tried using T2 and disabled the power down mode with 3200 and 3133 MHz with the same timings, but both of them threw errors almost as soon as I started the memtesthelper.
I understand the CPU, motherboard and the different RAM kits are a major handicap to the RAM overclocking. I'm curious if there's still a way to go beyond the current 2933 MHz setting.
The reason why I added 32GB to my original 16GB kit is because Cities Skylines uses a little over 30GB RAM by itself, and that's after pruning the Steam Workshop subscriptions. I'm missing about 1000 props/textures for the custom buildings I'm using in order to cut down on memory usage back when I just had the 16 GB kit. Maybe I could have searched hard for a 32GB kit that matched closer to my 16GB kit.
I am currently testing 3066 MHz with Power Down Mode disabled + Bank Group Swap disabled + BGS alt enabled.
EDIT: The 3066 MHz attempt also threw memory errors.
On Gigabyte X570 Aorus Xtreme:its not "always" that way with every board, to get FULL turning OFF of DF-Cstates
on my MSI board, one has to set power supply idle control to "typical current idel" and set DF-States to OFF.
if one does not set typical current idle then DF-Cstates remain "half" active leaving package state active while C6 state is off.
this way im talking above manages this, (do note that i didnt set anything in zenstates i just opened it to show DF-Cstates are indeed off)
unless i missed something somewhere and its not 100% off?
I couldn't have those changes stick after reboot or actually influence Package C6-States on B550 Gigabyte Aorus Pro V2 with 126.96.36.199A AGESA BIOSes. What AGESA does your BIOS use?On Gigabyte X570 Aorus Xtreme:
Typical Current Idle : Package C6-States are OFF
Low Current Idle : Package C6-States are ON
There isn't another setting around to adjust this "Package C6-States"
Core C6-States can be adjusted in AMD CBS settings with the DF-Cstates.
It tests single core, while you fail multicore. So no wonder. Total powerbudget and total heat are not tested. Please use HWiNFO to know what kind of power/volts/temps you get per-core, it's available in latest version.Surprised 24 hours of CoreCycler hadn't picked up on this
Not all cores are stable at higher frequencies.Hmm, I auto'd out my memory voltage settings and was going to try that first with y-cruncher before my CPU curve but at the last second in the BIOS I also tried dropping the auto oc boost frequency from +100 to +75.
Yeah, I know, should try one thing or one set of values at a time, but anyway, now my y-cruncher is over an hour in on its way to 10.
So it's looking like my reboot might have been too large a CPU boost value for my curve or some memory voltage settings. The fun of stability on the line, finding out that tiny bit of instability that is only cropping up rarely.
Gonna guess its the +100mhz on CPU in combination with a curve value that might need increased by like 1 or 2 notches. Dropping to +75 looks like it might have made it happy for now. Surprised 24 hours of CoreCycler hadn't picked up on this but here is a good reminder to use multiple stability testing apps.
The auto voltage values on my memory are very close to the manual settings I had dialed in. So I don't think it's the memory voltages.
AGESA 188.8.131.52b, F34I couldn't have those changes stick after reboot or actually influence Package C6-States on B550 Gigabyte Aorus Pro V2 with 184.108.40.206A AGESA BIOSes. What AGESA does your BIOS use?
Yup I'm figuring out that is what it is. I spent about a week with CoreCyler and guides trying to reign in my curve and stability test it but obviously staying with one app has shown its limitations. Tbf I didn't know about y-cruncher until I joined in with this topic.Not all cores are stable at higher frequencies.
The AUTO OC Boost settings just sets the maximum clocks allowed higher. So if you don't want overboost, you set it to a lower value or disable it overall.
I use this with my 3800X to limit clocks @ 4600Mhz for stability issues where the cores aren't stable at higher frequencies if I fully tweak it to maximum performance.
AGESA 220.127.116.11b, F34
The latest & greatest.
@Audioboxer see also this.Only CoreCycler ?
CoreCycler for me is just a primer for finding something that looks to be OK, after I found something its then onto Y-Cruncher to see if its stable, if Y-Cruncher crashes on specific tests (N32/N64 are particularly sensitive to CO) I tweak CO on core that crashed then hone in Y-Cruncher just to run on the crashing test.
Once its stopped crashing on the particular core I return to Y-Cruncher full test suite.
After Y-Cruncher is stable I do another CoreCycler, then use the system normally for an extended period of time to possibly catch idle crashes before moving to other types of stress tests
Thanks. I'm glad I'm learning all this now rather than plodding on thinking my CPU settings were locked in due to CoreCyler. It's making me wonder if some of my past errors in TM5 runs were contributed to by an unstable CPU curve 😤
I do feel between 18-22-22 and 19-19-19 everything looks fine
Even the added latency by the SETUP times (63)
Also very glad to see the SETUP timings "pattern" functions well ~ very very happy
Aside from the 8-9ns added ontop, it was kind of expected
You have 12ns ontop , soo there seems to be more than one issue ~ maybe 1.8v rail being too weak higher MCLK (which can easily make 1-2ns difference ~ if it's lacking)
But else,it looks normal
The increase tho is quite high ~ i think to match the same ns latency for 1900, you needed a 5000+ result , or near 4800+
@Nighthog is the person to ask S
Only if you run memclk=fclk=uclk. If you don't run it like that there has to be a delay to synchronize memclk and fclk clocks, and that delay varies nontrivially, because it probably involves some algebra and modulus arithmetic on clock numerators (for 1900 it's 57/3, numerator is 57, for 1933 it's 58/3, numerator is 58, etc). For example, here is me going from 3600-1800 to 3600-1900 and 3600-2000 and getting lower latency on 3600-2000. Actually on fclk 1933, 1967 and 2000 latency was similar and much less than on fclk 1900.the loss of bandwidth as it should be increasing with mclk, but it actually goes down.
I find the gains are really small for the amount of power you draw when you push the PPT boundary. There's really not much left to squeeze out of the 5900X/5950X if your ambient temps aren't like 10+ deg Celsius and/or you don't have a beefy custom loop with lots of thermal capacity to absorb the amount of heat these chip throw out.Notice it maxed out my EDC, but I assume that is quite normal for this. My settings are 270 PPT, 150 TDC and 190 EDC.
Yup, you're likely right.I find the gains are really small for the amount of power you draw when you push the PPT boundary. There's really not much left to squeeze out of the 5900X/5950X if your ambient temps aren't like 10+ deg Celsius and/or you don't have a beefy custom loop with lots of thermal capacity to absorb the amount of heat these chip throw out.
I settled with 145W PPT, 105A TDC and 170A EDC for my daily PBO power limits.
My ambient temps are usually at least 30 deg Celsius on most days, just to give a frame of reference. Max Tdie temp on my 5900X are around 86 deg Celsius, cooled using a 360mm EK-aio.
Only if you run memclk=fclk=uclk. If you don't run it like that there has to be a delay to synchronize memclk and fclk clocks, and that delay varies nontrivially, because it probably involves some algebra and modulus arithmetic on clock numerators (for 1900 it's 57/3, numerator is 57, for 1933 it's 58/3, numerator is 58, etc). For example, here is me going from 3600-1800 to 3600-1900 and 3600-2000 and getting lower latency on 3600-2000. Actually on fclk 1933, 1967 and 2000 latency was similar and much less than on fclk 1900.
tldr: you can try different fclk to lower latency instead of or in addition to varying memclk
Here you goThat would be extremely fast!
The first cycle takes less time than the last cycles.
I do believe CPU frequency does play a role, but in @craxton case he is using a 5800x, where as I am using a 5600x so logically the 5800x sustained mhz should be higher than what I can achieve.
Can you double check your values for completed 25 cycles TM5 runs as im confident that there are not too many peeps who have posted faster times than what I have posted while using a 5600x with 32GB I could understand a time within 2:40 mins while using flat 14s but 2:30 is a big stretch