X670 / X870 resource thread

[Shamino]

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

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

ocpak/octools

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


Test BIOSes:

Spoiler

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


DOCP/EXPO Tweaked: (for simple timings tightening)


strixe-e 1515 

strixe-f 1515 

strix e a 1515 

crosshair hero 1515 

crosshair gene 1515 

crosshair extreme 1515 

creator 670 1515

creator b650 1515

strix 650E I

strix 670 itx

for crosshair and strix e-e:

explanation of segment2 Loadline:

customize a heterogenous loadline for a dual segment workload range.

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

Adds for x3d

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





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

Can combine multiple algos for ccd priority so combinations are wide

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

[Silent_Scone]

---

@AegisFLCL wrote:

several other people on OCN seem to be running into issues where one post you can run 30-40k coverage in kahru and other stability tests, but subsequent posts you can fail at varying coverage rates; its an issue of consistency and as far as we can tell it could be the motherboard hardware/bios.

This can be par for the course when pushing platform limits, though. There is quite a bit of disparity between what is electrically valid at [POST] and passing memory stress tests from within the operating system. If conducting a warm reset or powering the AC on and off is enough to create instability, the signal margins aren't sufficient enough at the applied overclock.

I'll see if we can get some clarity on VDDP behaviour.

[AegisFLCL]

If it’s a case of electrical properties or signal integrity, does the training process alter termination settings/drive strengths that arent exposed within the dram timings menu such as, but not limited to, processor ck, ca, cs?

The main termination settings from boot to boot are set to static values (at least anything reported by zen timings), so its confusing as to stability would change boot to boot (electrically/signal integrity) unless some of these other termination values are being auto determined differently during training each post.

[Silent_Scone]

 If every condition was identical between subsequent restarts and power cycles you probably wouldn't be looking for these answers. The fact these difficulties are occurring high up in the frequency spectrum also aligns with this, as the margins are far tighter. The system cannot accommodate an unlimited number of drivers to perfectly match impedance for every possible scenario. Instead, it must make use of the closest match available, which may not be sufficient. 1:2 ratios are currently off the reservation as there is no official validation for anything above 6400MT. If there's any room for improvement [in terms of auto ruling] I'd just advise you to watch this space for now.

For the time being, I would aim for a frequency the system is comfortable being at whilst being stable. In your case, I would expect X670 chipset to receive any updates before entry level, though.

[GRABibus]

Hi,

I am in same situation of AEGISFLCL.

I own Strixe-e and even 7400 1:2 is impossible to stabilize. When I say stabilize, I mean consistent at least 30000% coverage in Karhu’s boot to boot.

I can pass 40k coverage.

I reboot, relaunch Karhu’s, and fail at 110% coverage….

I am also very active on OCN and only strix owners and 1 hero owner have this issue.

Gigabyte 2DPC boards don’t have these limitations.

this is very frustrating and boring.

Either it is training which doesn’t work well either board limitation.

if it is training, we count on Asus to solve this.

thanks.

[Silent_Scone]

Hey GRABibus,

Hope you're well. Let me know the memory kit PN please

[GRABibus]

Hey man,

I am well, thanks. Hope you also !

here is the kit I use :

https://www.gskill.com/product/165/374/1668740013/F5-7800J3646H16GX2-TZ5RS

But I am pretty sure the issue is board/bios  related.

.

[Silent_Scone]

Thanks, your questions aren't going unheard. 👍

Always need to know what memory is being used. Just be mindful that GSKILL hasn't done any validation on AM5 for that kit. The voltage guardband instilled by the vendor is often not transferable across platforms (yet another reason why the QVL exists), so your mileage is always going to vary.

[GRABibus]

Thanks !

so, which kit 7800/8000 would you advise me to test ?

[GRABibus]

One of the great Overclocker on OCN tested the Team Group 8000kit, same bad results on strix.

Is this kit approved on AM5 ?

[Silent_Scone]

Doubtful, given it's 8000MT. I'd be asking yourself how many CPUs can even do those frequencies unconditionally, too. Some of that is up in the air currently. These types of validation processes can be time-consuming, and mostly done at launch. These are questions that hopefully can be addressed soon.