[Sammelthread] Ryzen RAM OC + mögliche Limitierungen

[Bread]

@Tatilica then again, the solution looks pretty much the same for each sample that hits 4000: vSOC ~1,15-1,25+ / VDDP ~0,88-1,0 / CCD 0,98-1,10+ / IOD 1,05-1,15+. ProcODT varies. Here is one similar to your voltages with 4000 / ProcODT 48 , here one also similar in voltages but with ProcODT 36,9, and here an example with super-low everything.

Btw how come it shows like this?

 

[Veii]

Btw how come it shows like this?

Agesa boost.
New AGESA is very different from before.

I do experience full sounddriver dropouts and restarts if CO drop is too strong now. This is new (pci link instability)
And coreclk has a two stage boost (hwinfo not reporting strap boost)
But yes, many changes

We have to verify your boards NIC is fine, before continuing further.
I dont have that problem because mine is dead
But else the Rev2 on my board needed a FW update.
Rev1 needed an rma, unfixable by fw. Rev3 is fine by driver updates.
Killer branch & Realtek needed FW driver and OS driver updates to mitigate dropouts;
// Dont think it ever was resolved.

Speaking of
@RedF sorry to use you for that, and sorry to use you for ropbench earlier.
Can you screenshot/rewrite the tutorial and reupload the patches i supplied , from the dc channel ~ for intel lan
Its good for them to be online and required to be on latest FW.
Chance remains high and i have no trust the supply-chain fixed their FW issues per se.
As not all was fixable just by driver blobs.

 

[unifyx]

@Veei

So you need this screen from the NIC while high FCLK or at a stable FCLK?

Can send you a screenshot a bit later.

 

[Veii]

@Veei

So you need this screen from the NIC while high FCLK or at a stable FCLK?

Can send you a screenshot a bit later.

Just what is build in,
Because HW plays a role here.

ZenPT reads FW of chip
FW collects data based on system runtime
Even if one disables whea log, chip collects data and accidents that happen till a certain margin of acceptable errors is reached.
^ till system restart, then counter resets
All cpus have margin of acceptable errors. (FIT meaning). Non are error free;
Margin-errors are corrected internally, before ever a report is created.
This you can read out.

Optimally you know your situation when it begins to log #19s and can replicate that
Then videolog that with ZenPT , soo we see whats going on
95% chance its CPU and not Board related.

If nothing shows up, its link towards and PCH towards I/O logging a missed report.
Thats the whole meaning of #19
(nearly always, up to report given on #19 error),
It means "log vanished in void" .
Send out, asked for responde, received nothing.
Report vanished = #19 is logged by CPU, and OS reports that as a potential-critical issue with empty reportdata

It never had anything to do with "stability or performance".
The spam-log of it in the early days (mostly due PCH) was just degrading performance

Fraction of CPUs,
Mostly those who were taken out of supply chain, downgraded, fused away and updated with less cores.
Those dont have such bugged reports anymore. Neither AM5
// as FW patch is newer
My daily is one of such,an early 16 core down to a 6 core.

For dual CCDs its mostly CCD00 that vanishes the logs (if inter cpu)
CCD01 always was fine. But disabling CCD00 was hard in the early days.

Else yes,
Just the device-manager screenshot i gave before, but for ethernet.
Mine's dead,soo has no chance of bad reports haha

 

[Tatilica]

@Tatilica there is a chance that you arent at all
But also a chance that it doesnt matter, as critical reports ≠ instability

All the logs for you report zero, even in verbose.
You need to have reports of #42, per active sensor
And report of #5 on successfull initialization of target sensor.
Those appear every successfull boot.

Both are missing here, soo chance is high that its service and group policy is disabled on win 10
On win 11 such is harder, soo i dont think you are on it.

Suppressor was used to prevent dpc spikes due to error spam
At the time the spam was due to NIC issues and chipset issues in general (600errors/sec) without being a performance penalty

Such is not needed anymore and full stability + log free should be targeted.
// NIC FW reflash may not be needed anymore, but i need to verify myself. No trust, but "should" be resolved by now on last 2-3 AGESA and with latest drivers.
Log free doensnt mean clean log. It means no warnings in there.
Vebose logging remains required, to approve sensors are even active.

---

You may be at 6/10 sensors, may be at 10/10
But currently its unknown because event-viewer service appears disabled. Or log was cleaned

Sensor active log depends on what FW is on the Chip
(microcode + X, patches over to ARM inside chip, on boot if required)
And what settings Boardpartner configured for corresponding bios defaults.
Any case , no logs there means they are disabled on OS level.
Soo please look for a fix.

Yeap got this, but kernel #42 & #5 are still there on Verbose, I saw couple of them this morning after boot, they aren't being bother me much, as wheas19's were gone, I hope 🙏
I'am at work, away from home, but my little girl are still playing CP2007 by many hours now, I will check info log after I'll being at home asap, thx

 

[Veii]

Yeap got this, kernel #42 & #5 are still there on Verbose, I saw them this morning after boot, but they aren't being bother me much, as wheas19's were gone, I hope🙃
I'am at work, away from home, but my little girl are still playing even this time by many hours, I will check later info log, thx

They will come once, every boot.

It never had anything to do with "stability or performance".
The spam-log of it in the early days (mostly due PCH) was just degrading performance

The problem is that HWInfo will force an ask-reposonse, which increases the already complicated state
Of random response-logs vanishing and creating #19
// Those can come like said before many times ~ from everywhere. Every Peripheral from CPU till PCH till IO.
// Its soo silly to fixate perspective on stability, when neither stability nor package-throttle are responsible for log-vanish (19)

The one that actually means instability on cores side is #18.
#19 is just an empty response log and rarely it got data in it.
Sometimes it does, hence tracking what it reports ~ is important.
// Allowing win to log everything CPU reports, on Verbose even more important

But often #19 its just empty, so in such state one can check ZenPT if the counter got +100 and something bad happened
or its just +1 corrected, every our or so.

This is how it should look

Clean and empty

This is what it may log, as system unexpected shutdown information.
But thats all.
no critical #18 and no silly #19.

Beitrag automatisch zusammengeführt: 25.04.2024

But often #19 its just empty, so in such state one can check ZenPT if the counter got +100 and something bad happened
or its just +1 corrected, every our or so.

Example from before , here

[Sammelthread] - Ryzen RAM OC + mögliche Limitierungen

Set your logger to capture everything. Do not trust HWInfo to capture WHEA. Do not trust the OS to capture WHEA as a Faultcondition. Set it up to verbose so it actually starts to capture anything Hey @Veii, after tweaking whole night and get rid of bclk as suggested, Global C-states disabled...

www.hardwareluxx.de

Nicely or not so nicely phrased.
Because it became annoying reading the same thing over and over "Its unstable, #19 belongs to stability".
Literally talking to a wall on this Forum. ~ feeling
It has soo little to do with it, haha

Vs how it should be

Maybe last sensor gets up to 40 for 24h system usage.
It was a bit worse, soo "i worked on my voltages a bit"
Now it doesnt sit at 36 at all.
Logs even more rare anything, that will be corrected by the CPU anyways.

Their names are slightly wrong, the data of sensors remain correct.
So please start logging and give me usable data, if you want my help.
We can work on the stability and package-throttle topic later. They are split and have nothing to do with the vanishing-log situation;

 

[unifyx]

@Veei

here you have it

 

[Tatilica]

But often #19 its just empty, so in such state one can check ZenPT if the counter got +100 and something bad happened
or its just +1 corrected, every our or so

Hey @Veii please need a screen from where I should look after Wheas counter, I'am not very familiar with ZenPT, but wanna download it from your zip attached here, thx?

 

[Veii]

Hey @Veii please need a screen from where I should look after Wheas counter

@Veii i

here you have it

So much towards "they improved/fixed it finally"
I cant see that 🙈
Funnily enough, there are couple X3Ds and newer CPU reports (newer substrate) that get 2000+ running.
But 2067 is very hard. GL on 2100.

FCLK overboosts
LCLK doesnt hold to set limiters
"MP5" (bad name) Sensor collected 800+ reports of done corrections since the system boot up.
It wasnt WHEA worthy, but ... it happens. Soo something on your setup causes issues.
Probably HW piece, because no trust. I never trust them fixing it.
Its always running after somebody with this issue.
At least AM5 behaves, for now. Or i dont see much of it, because 2000 FCLK finally is the default.

I ment the ethernet NIC, not the wireless, but the same tab that lists everything
Havent heard or read any reports of the wireless one having issues.

 

[unifyx]

oh, for the ethernet, I have it disabled in the BIOS bc I dont use it. should I enable it, to take a screenshot? or is disabled... diabled and does not interfere?

 

[Veii]

oh, for the ethernet, I have it disabled in the BIOS bc I dont use it. should I enable it, to take a screenshot? or is disabled... diabled and does not interfere?

Make a verbose custom view
This is just that the service runs, but not what it outputs.
It collects data from two different places, hence sensor-tools reports like OCCT & HWInfo cant be trusted on their reporting

Disabling it doesnt remove it from the ACPI table in UEFI.
Removing DXE data from ROM may deactivate it, but it remains powered and connected. Based on our old experience.
Nuking its FW soo it halts and stop on init, appears to be a coincidental fix. I accidentally wiped mines FW

No, if Realtek you should have FW Blob patches and need to stay on the latest drivers
If Intel, i got FW Flash tools for that. If intel Rev3, we are safe.
If intel Rev1, there is no help. RMA was~

Of course it can be other things related to PCH too
But that was the most common victim so far.
Their introduced SATA & NVMe driver "patches" who first caused issues and havoc - are just a side issue.
It can be anything and everything creating logs , soo i need data to isolate things slowly.

You still will package throttle on FCLK and still may or may not become unstable
But thats a very far away topic without connection to the sensor logs.
Because we can see, not even 1800:1800 is safe from that HW&FW issue.

Its good to see that this were not 10k++ log spam
But its still very bad.
You would need to be sub 50, to call it fully log free.
Eh probably near 100 makes no issues except random hangups maaybe.
But 500+ is something to consider still misbehaving

 

[unifyx]

I hope I am doing it right...

I dont know, if I have to mention that I am on AGESA 1.2.0.3C

 

[Veii]

Create custom view top right

Those two sensors..
Realtek 8125B (-CG?) should just need driver updates to be fine.
I can find 7D12 ID, but not 7D13 yet.

 

[unifyx]

I just updated the drivers

Beitrag automatisch zusammengeführt: 25.04.2024

now, this is how it looks like with FCLK 1933

it only shows ID20

what I can see so far is, that thease fluctuations are only in idle going FCLK over 2000 and LCLK over 600. when under load, there is no fluctuation. it stays FCLK 1933 and LCLK 592.5.

 

[Veii]

it only shows ID20

what I can see so far is, that thease fluctuations are only in idle going FCLK over 2000 and LCLK over 600. when under load, there is no fluctuation. it stays FCLK 1933 and LCLK 592.5.

Yea something still triggers reports
Sorry i didnt see, there was no ping

Wanted to share something , but that something triggered a bug, which maybe triggered another bug, aand i killed my OS
Any case
Here are the drivers for Realtek NIC. ~attached~

And take a look at this ~ for Realtek ALC

Release 6.0.9652.1, 6.0.9655.1 and 6.0.9658.1 · pal1000/Realtek-UAD-generic

Partial WHQL notice Due to Realtek not providing regular updates to HDXRTU.CAT, HDXRT.inf, HDXRTSST.inf and HDX_GenericExt_RTK.inf, it wasn't possible to make a Realtek UAD Generic package for old ...

github.com

instead of using Boardparter "enhancements"

It was what bricked my OS, but that was a side issue.
I had before strange audio driver crashes since updating my browser (with their silly AI integration) and may have gotten something malecious
Because nuking the drivers from the OS, prevented it to run explorer
On reinstall all works fine. Be sure to make a system restore ~ although script will make one.

For nuking old drivers and their traces:

GitHub - lostindark/DriverStoreExplorer: Driver Store Explorer [RAPR]

Driver Store Explorer [RAPR]. Contribute to lostindark/DriverStoreExplorer development by creating an account on GitHub.

github.com

Intel Wireless i know comes with their own FW blob
Intel Bluetooth for APTX & LDAC support i had driver+fw blobs
~ but i'll have to bother somebody to upload me them from the DC servers.

Powerplan you can use what i uploaded

Beitrag automatisch zusammengeführt: 25.04.2024

Around 1.2 SOC should be plenty for anything higher than 1900 FCLK
You can go up to 1.9v on CPU1P8, but 1.88 should also be plenty till 2033 FCLK
PCH voltage is fine to run at 1.07v even 1.08v. 1.07 is fully ok

LCLK 310-593 is fine too ,but with an RTX GPU or RDNA3 you may enable their LCLK PCI Tweak
(i need to check now if all audio issues remain resolved, as they always were till like 1-2 weeks ago)
I dont use chipset drivers, they no need.

And if you miss something in bios, there surely still is an uniffy-X bios modding community/discord.
I may ask around if you cant find them anymore.

 

[unifyx]

yea, I think 1933 with only ID20 is fine to run, but at 1966 it starts with ID19. Will try your powerplan.

I am on a XOC BIOS, you can just please ask, wich BIOS is more stable to work with higher FCLK.

 

[Veii]

I am on a XOC BIOS, you can just please ask, wich BIOS is more stable to work with higher FCLK.

Always latest, sorry
1207 AGESA was ok
But after that everything changed

I would still pick always the latest and keep in mind every voltage value and CO behaves differently

 

[unifyx]

Always latest, sorry
1207 AGESA was ok
But after that everything changed

I would still pick always the latest and keep in mind every voltage value and CO behaves differently

the thing is, that 1.2.0.3C is the last XOC BIOS called A44O. There is no newer BIOS with everything unlocked.

 

[Veii]

the thing is, that 1.2.0.3C is the last XOC BIOS called A44O. There is no newer BIOS with everything unlocked.

Yes, got to ask - but also , you should update~
What type of unlock are you looking for - which option ?

 

[unifyx]

Yes, got to ask - but also , you should update~
What type of unlock are you looking for - which option ?

CBS and PBS

 

[Veii]

CBS and PBS

Aber was davon?
CBS verlinkt MSI.

 

[Tatilica]

@Tatilica then again, the solution looks pretty much the same for each sample that hits 4000: vSOC ~1,15-1,25+ / VDDP ~0,88-1,0 / CCD 0,98-1,10+ / IOD 1,05-1,15+. ProcODT varies. Here is one similar to your voltages with 4000 / ProcODT 48 , here one also similar in voltages but with ProcODT 36,9, and here an example with super-low everything.

Btw how come it shows like this?
Anhang anzeigen 993443

Hi guys, mistery solved, it was old version Zen 1.26 quilty for that, new ver.1.31 looks bclk included btw
As for your OCN samples from examples, first one similar was 5800X, second also similar was 5950X and super-low everything is indeed 5800X3D owned by my friendly questionable mine italian user in dispute on IF2000, the only one on this planet who is pretending are running X3D Wheas free (in HWinfo, no Verbose) but only in games & daily app, but guess he can get with eas a lot wheas in some tests, if he want to run them for, but he won't, full discussion in here, he only want to test TM5 1usmus endless 50cycles, happy me🙃

 

[Veii]

Hi guys, mistery solved, it was old version Zen 1.26 quilty for that, new ver.1.31 looks bclk included btw

Yes , maybe also
But new Agesa does behave different in terms of clock straps.
You can see that if you compare hwmonitor strap and zenPT or hwinfo effective
Or ropbench vs hwmonitors strap

I'm not sure when it came, but it was noticable at least on 1207.
Probably havent seen it before, but was a thing.
Or was side-influenced of CO drop correction

Having dynamic FCLK would be good too, haha.
It wont be unlocked back - i dont believe.

 

[Tatilica]

But new Agesa does behave different in terms of clock straps.
You can see that if you compare hwmonitor strap and zenPT or hwinfo effective

Having dynamic FCLK would be good too, haha.
It wont be unlocked back - i dont believe.

Hi legend, here's your requested data, if you can please take me help looking at how my setup was running in extra-long 12 hours gaming session, your input may help, guess all fine, kinda abussing CP 🧐

 

[Veii]

Hi legend, here's your requested data, if you can please take me help looking at how my setup was running in extra-long 12 hours gaming session, your input may help, guess all fine, kinda abussing CP 🧐

Hii hi,

This still tiny bit overboosts even if you capped it at 593, but you dont log anything

In the sense, the CPU doesnt log anything bad and doesnt even try to correct

Its how it always should have been , well done~
Can you do two more tests for me please.

Get
~attached~ and run Core2Core please

Then enable back LCLK DPM and set min to 310-592
Run again ropbench. I'd like to compare something
Check ZenPT after you run it again and have ropbench closed.

Do not open HWInfo in any of those instances, they bother each other.
Those overboosts dont bother you now, but will bother you past 2000FCLK
Better to get them under control now.

EDIT:
Also , as great as this looks now
It doesnt mean its stable at all or doesnt throttle, just so far looks like its all behaving.
Stability and throttle are completely different worlds.
At least no silly bugs that trigger WHEA. CPU has logged nothing from Board side so far.

 

[Tatilica]

Hii hi,
Anhang anzeigen 993951
This still tiny bit overboosts even if you capped it at 593, but you dont log anything
Anhang anzeigen 993952
In the sense, the CPU doesnt log anything bad and doesnt even try to correct

Its how it always should have been , well done~
Can you do two more tests for me please.

Get
~attached~ and run Core2Core please
Anhang anzeigen 993955
Then enable back LCLK DPM and set min to 310-592
Run again ropbench. I'd like to compare something
Check ZenPT after you run it again and have ropbench closed.

Do not open HWInfo in any of those instances, they bother each other.
Those overboosts dont bother you now, but will bother you past 2000FCLK
Better to get them under control now.

EDIT:
Also , as great as this looks now
It doesnt mean its stable at all or doesnt throttle, just so far looks like its all behaving.
Stability and throttle are completely different worlds.
At least no silly bugs that trigger WHEA. CPU has logged nothing from Board side so far.

Great, thx man, I'll do check Rop asap IF2000
Need to ask indeed for my daily stable most used Profile 3866+102.25 bclk, why lclk 593 looks great inline in compare 615 Eff IF2000, cause 3954 C15 GearOFF has no capped 593, no PBO Limits, Offset voltage -0.0375 applied, but same Curve perCore & DPM disable 🙃

 

[Veii]

Great, thx man, I'll do check Rop asap IF2000

Too many steps at once
FCLK2000 can wait.

Sorry, im not sure i understand the other half of the message.
We talk about your 1967 illustration.
I dont know how it looks at 2000 native.
And i dont know how long runtime is before you check ZenPT

You generally should give up BLCK till you reach your target clock
And also work to get GDM away

Doing memOC and FCLK OC at the same time will lead to nowhere except just confusion.
There is no need to run FCLK synced when testing and tuning for it.

Oh i also see you put a filter on WHEA logger again.

 

[Tatilica]

Too many steps at once
FCLK2000 can wait.

Sorry, im not sure i understand the other half of the message.
We talk about your 1967 illustration.
I dont know it looks at 2000 native.
And i dont know how long runtime is before you check ZenPT

You generally should give up BLCK till you reach your target clock
And also work to get GDM away

Doing memOC and FCLK OC at the same time will lead to nowhere except just confusion.
There is no need to run FCLK synced when testing and tuning for it.

Oh i also see you put a filter on WHEA logger again.

Sorry my bad, 1967 illustration LCLK 593 capped has 101.75 bclk =IF2000 1:1:1
Just checked Rop both your scenarios, first run lclk 593 capped DPM OFF & second run min.310-max.592 DPM ON
Seems clear for me that DPM enabled 310-592 put back LCLK Effective inline, so pls forget about the second half of the previous msg👍
EDIT: just checked lclk 593 capped for DPM ON, same story 615 EFF reapeared again, so doesn't matter for DPM OFF or OFF 593 is not for me, great thx

 

[Veii]

Yea its fine, it can be a bit better tho.
To stay sub 40 value for 1-2h gaming.

Can you remove BCLK and run native 2000 FCLK strap.
Sadly c2c is a bit too inconsistent but its also for me the same.
There are no latency spikes, soo nothing happens internally. Its clean.

i would do now:
2000 FCLK strap, force 100mhz blck
Check aida write bandwidth
Then we'll continue from there with mem GDM off (later)

I expect it to hit 31999MB/s.
At worst 31998

---

EDIT:
Please dont forget,
1967 to 2000 is doable. It shouldnt be too hard.
But, 2033 and then 2067 is hard !
If you skip steps and make big jumps, youll waste months if not years to hunt your own caused issues

Its ok to not scale gear1 high and step by step note down voltages required.
Then do the opposite and verify stability on Gear 2 desynced MCLK from UCLK with low known FCLK
If both are fine, which is unlikely to oneshot ~ then you scale up.
Not ! At the same time. Dont do 5 steps at once.

Beitrag automatisch zusammengeführt: 27.04.2024

EDIT: just checked lclk 593 capped for DPM ON, same story 615 EFF reapeared again, so doesn't matter for 593 DPM OFF or OFF

Most of it is your powerplan and (lack of) idle states.
I barely peak it high
It stays near 400 range and can boost to what i gave it.

Could be a BCLK thing shifting the range
BLCK can mess with too many clocks.
It shouldnt be used.

 

[Tatilica]

Yea its fine, it can be a bit better tho.
To stay sub 40 value for 1-2h gaming.

There are no latency spikes, soo nothing happens internally. Its clean.

Yup, will do native 2000 FCLK strap, and pure 1T Gear off, step by step, better I enjoy my left day off with family now and stick with IF2000 bclk included, testing in progress, wish me luck, thx much