[Sammelthread] Ryzen RAM OC + mögliche Limitierungen
- Ersteller Reous
- Erstellt am
unifyx
Profi
Ja, hatte ich auch schon drin. Aber grad die Riegel wieder durch meine b-die ersetzt. Genug Ausflug nach CJR
Ich brauch den Rechner wieder ...
HWLuxx , alle ~ scheinen sich zu starke ODTs angewöhnt zu haben. // 20 oder 24er waren ein Zen1/1+ Thema
Mich wundert es nicht (dass man öfters das selbe sieht), aber nun ja es ist ein Problem
The Professor
Legende
Mit S8B sind die auch kein Thema. Einfach gebrauchte S8B nehmen und nicht mit CJR krackselnHWLuxx , alle ~ scheinen sich zu starke ODTs angewöhnt zu haben. // 20 oder 24er waren ein Zen1/1+ Thema
Mich wundert es nicht (dass man öfters das selbe sieht), aber nun ja es ist ein Problem
ODTs sind eher ein Mainboard Thema & leicht ein CPU Thema (da procODT Einfluss).Mit S8B sind die auch kein Thema. Einfach gebrauchte S8B nehmen und nicht mit CJR krackseln
DIMM-PCB sensitivity (zwischen RTTs), leider existent~
Aber es hat weniger IC Einfluss
OEM CJR ~ 1.54v
// etwa 3800C 15-22 ~ viel zu hohe RCD aber naja, bin Hynix amateur
.
RevE & B-Die ~ 1.65v
Ich weiß es nicht
Ich hab zu wenig 16GB DDR4 DIMM's Erfahrung
Aber ich weiß dass man sich (seit Z1 Zeiten) in diesem Forum angewöhnt hat, vieel zu starke ODTs zu rennen.
7-3-3 dauerte leider sehr lange, bis es die Boardpartner endlich akzeptierten. 🤭
1.5-2 Jahre voller hin und her.
Anstelle 031 oder 731 ~ welches viel zu stark ist.
Beitrag automatisch zusammengeführt:
Ah , die CJR halten ebenso das 4600er limit wie meine A0 B-diesviel zu hohe RCD aber naja, bin Hynix amateur
Liegt am DIMM-PCB leider.
Und etwas am Nutzer vor dem Keyboard
Rev.E war 4800 full stable, und 5000 MT/s gerade so.
Zuletzt bearbeitet:
The Professor
Legende
Natürlich Mainboard spielt da mit, aber die meisten ordentlichen AM4 Boards mit B550 und X570 bekommen das schon hin.ODTs sind eher ein Mainboard Thema & leicht ein CPU Thema (da procODT Einfluss).
DIMM-PCB sensitivity (zwischen RTTs), leider existent~
Ah , die CJR halten ebenso das 4600er limit wie meine A0 B-dies
Liegt am DIMM-PCB leider.
Und etwas am Nutzer vor dem Keyboard
Rev.E war 4800 full stable, und 5000 MT/s gerade so.
Ja S8B bekommen irgendwann nen harten Wall. Deswegen haben die ganzen 4800-5000MHz Riegel zumindest die 3 Kits wo es gibt, keine Samsung Chips mehr.
Zuletzt bearbeitet:
Yup, week two TM5 #2 + VST, b-die rocks, thx @VeiiJa, hatte ich auch schon drin. Aber grad die Riegel wieder durch meine b-die ersetzt. Genug Ausflug nach CJR
Anhänge
-
5800X3D_3954CL15_GearOFF_102,25_BCLK_PBOLimitsOFF_CO-PerCore_LCLK DPM off #2.png -
5800X3D_3954CL15_GearOFF_102.25_PBOLimitsOFF_CO-PerCore_LCLK DPM off #.png -
5800X3D_3954CL15_GearOFF_102.25_PBOLimitsOFF_CO-PerCore_LCLK DPM off.png -
58X3D_ROG1440_144hz_High_DLSS3Performance+RayTPsycho_copy_2480x1440.png
@Tatilica I find it hard to understand what your message is.
The settings you present are great, it's impressive how you OC'ed your CPU and RAM - but you showed more or less the same several times here. Is there another message to be seen? Do I oversee something?
For me personall y the only relevant information would be, which magic I have to launch to get rid of the WHEAs at IF 2000 - a magic I guess which doesn't exist ;-)
The settings you present are great, it's impressive how you OC'ed your CPU and RAM - but you showed more or less the same several times here. Is there another message to be seen? Do I oversee something?
For me personall y the only relevant information would be, which magic I have to launch to get rid of the WHEAs at IF 2000 - a magic I guess which doesn't exist ;-)
Hi guys, these message was short: setup stability
Cause found same issues retesting Profile after time, surely being stable in all initial tests
As for IF2000 on X3D, nope, doesn't exist wheas free, can't get rid of them, just but roll back to 5000 non X
Cause found same issues retesting Profile after time, surely being stable in all initial tests
As for IF2000 on X3D, nope, doesn't exist wheas free, can't get rid of them, just but roll back to 5000 non X
Zuletzt bearbeitet:
You target a
Its no wonder
I will have to check tonight how far you are of me on CPU-Z
Somewhy think, i match you with the 5600X
What i only dislike is that you only test VST.
Its bad practice and comes from the intel XOC base. Which was bad practice there too~
Generally doesnt do too much on Zen, because the designs differ.
You need FFT+ N64 + VT3. Key is mixed load and mixed instruction sets soo BranchPredictor is more confused.
At best just all and that looped for 5 loops. Soo 72min is a decent "entry !" stability.
What i also dont like is your high pushed tWTRS
Its for CPU stability but nevertheless waste of time on writes
You may want to move between value = RRDS [CCDS] or lower.
Try to see if you can sustain WTRS 5 and then WTRS 4
If there is an issue slightly increase WTRL and RTP (together)
We target at least WTRS 4.
TM5 first, y-cruncher suite later.
Should be plenty for this. But not just VST or VT3
You may or may not see small uplift in those low mem-size Benchmate tests,
But you will see an increase on cache to mem to cache communication (if stable)
Beitrag automatisch zusammengeführt:
Everything goes around your RCD value - soo that should be your very first priority to lower that
Whatever it takes, 2ndaries and terts up
But in your case you may start back @ ground zero.
Because BLCK tuning is silly. Eh locking FMAX too but oh well~
Take a look:
@RedF @Wolf87 @zebra_hun @Mtorrent
Someday our userbase will learn that lower is not better~~
But till then you will be the black sheep that doesnt understand;
Just a warning from me to you, as you'll face criticism by ppl.
Memory subsystem on AMD is decently understandable.
But you still are at the mercy of internal communication, before ever bothering with mem.
Run RopBench first
I want a clean , no programms , barely services no mousemovement
~ test
// sequential cores , memory latency and core 2 core
Then focus on WTRS stability without introducing new variables & no voltage change !
We target value 4, later target value 2 - but thats too much torture at first
Then i want to see an SiSoftware Sandra (Inter thread) benchmark + log
And only then we go to RCD targeting value 15.
Idcare if "its hard"
you can do it, but not with BLCK shenanigans.Your BCLK and Clock shenanigans we'll verify with those two programms if they do anything helpful whatsoever
Or its just virtual clock that has no internal weight & may perform "faster" due to L$ & SOCCLK being higher which is relative to coreCLK
Zuletzt bearbeitet:
Yes indeed
Nono man
if you take my help, you gotta deliver better & beat me
^ peaks to 672 but current AGESA is too dynamic in boost, doesnt hold it ~ maybe some CO value is suboptimal
I don't know what's "good"
but 434p per thread (12)
vs
418p / thread (16)
Please work hard 💪
Tbh i've never testet with Cpu-Z
Score probably is bad
, soo that means you have to work even harder~~// I would love to run 5.15GHz boost (know it can do 2c 5.05 easily) with 4.9 sustained, but AMD doesn't like fun;
// Hydra is too slow vs PBO especially current BoostAlgo + has overhead cost. Unfortunately RSMU is slow;
EDIT:
At least there is more L1+L2$ ~ but if we do math per core blob
142GB/s L2, 280GB/s L1
151GB/s L2, 300GB/s L1
L3 Blob is then shared between both core complex sides.
Yea no, fight fight ~ i want better scores from you
Uploaded both, in case one RopBench doesnt like current AGESA.
^ no throttling on 6 core SSE/Game load
Maybe its time to abandon BLCK shenanigans and beat me with hard work and higher FCLK
I'm confident we can manage the 2000. You're currently 7.24% behind.
Should be closer to 5% with 2000 FCLK and bit more work~~
Zuletzt bearbeitet:
Hi, precisely as you said, standard stability is what I was looking for my X3D in BCLK scenario & 4x8 sticks, cause we cannot compare higher 5600x clocks potential or straight mem IF2000 benefits🤕You target ahighnormal standard of stability tests
Its no wonder
I owned one before, better binned and was so sorry after I sell it in my previous build, now I can run only lower clock speeds & mem freq on X3D normal target, but in different Vcache architecture indeed, which compensate here in all games FPS boost, happy me as single player usage only😋
Beitrag automatisch zusammengeführt:
Regarding score cpu-z is no go for me where X3D can bench higher than 5600x, cause YES peaks to 672 for me too 😜Yes indeed
Nono man
if you take my help, you gotta deliver better & beat me
Anhang anzeigen 990361
^ peaks to 672 but current AGESA is too dynamic in boost, doesnt hold it ~ maybe some CO value is suboptimal
AMD Ryzen 5 5600X @ 4848.87 MHz - CPU-Z VALIDATOR
[azyejg] Validated Dump by DESKTOP-TATILI (2021-03-21 10:02:13) - MB: Asus ROG STRIX X470-I GAMING - RAM: 16384 MB
valid.x86.fr
Anhänge
Zuletzt bearbeitet:
I do i do
For this bricked SKU its on 65° ThermalBoost Max
And on 1.3(25)v VID-MAX.
The 25mV more "freedom" are only granted if i dont exceed EDC of 90A
But given this sample does pull vampire power because a whole CCD exists ~ i hit it.
I wouldn't push you, if i didnt think there is headroom
Single 4850 @ 1.29 is as plenty as multi SSE at 4800 ~ on same limit.
I know dual 4950 needs bellow 1.3v but AMD doesnt like fun~
// limits FMAX to prevent their boost algo reaching 1.62v requests, but limits CO range too to prevent silly users running -30 or -60 CO steps
// because limited CO can result in a constant "stutter request", holding for fractional time X clock withing target VID limit set. Which is baad.
And my IF needs bit of voltage too, outside the first ghost CCD.
// i know it pulls power, AMD can try to tell its not that way, but its always been on this sample;
Why i push you,
Because Frontend CoreClk is not everything.
Especially on X3D which is an efficient substrate.
You dont care about coreclk if subsystem is slow. // your first priority should be FCLK and low tRCD, also no CO & Cache throttle;
Sure L3 Cache boosts by frontend clock, but so does also CO autocorrect and sample package throttle on at least 8+ different occasions/variables.
// it being more advanced with newer AGESAs
You make up the lack of coreClk but pushing other stuff, its not soo important ~ if "other stuff" is slower
But "other stuff is guaranteed slower" if you throttle in any possible way. Which you will do
I cant fully prevent it on my side, but at least its only thermal peak and voltage max anymore.
Soo an AIO and its "workable" with~
I want you to match it, at very least come close.
You get WHEA due to "XYZ being corrected". It reaching "max allowed corrections" & then OS sees a report.
Why ? because thats what it can do to preserve stability, if package throttle is not enough
// with BLCK you push front and backend up, which will cause issues ~ its not even a question.
// some you can downclock and rebalance but not everything. AMD users barely have access
// there is stuff we can do, soo first no BCLK and sanity checking everything.
Now further down, to 4
// EDIT: i didnt notice its an old GDM on score, nono work on this and lower it. Its wasteful.
Later away with BLCK till we sanity check if you always reach boost max and then target 2000 FCLK, minimum.
Zuletzt bearbeitet:
Bread
Experte
I find it hard to follow - I thought it was agreed that IF2000 with 5800X3D is not possible without WHEA 19?
Was it ?
I am certain he agreed to give up and wasnt possible for him
But when that was, and how it is today. I forgot when it was;
Seeing that he isnt that close as i expected, and how close i am to "higher average X3Ds".
I expected the gap being bigger, especially in the Cache department.
Nono, there is stuff to do and ways
Most definitely will not work ontop of BLCK,
But key reason is ~ "ich werde mit der Zeit schlauer"
Thats all,
Just always learning. Every day, 6 years DDR4 & now DDR5 ongoing;
Zuletzt bearbeitet:
No no, I already decided to follow our master Jedi @Veii route, already OCN fellows miss him there, I barely hard found his master piece AM4 work in here, thx HWLuxx community too
EDIT: I'am confident IF2000 is possible without wheas party, just but lack of time, cause I really know how time consuming mem tweak it is, but I'll check tonight 🤫 maybe my beloved protector wife can't see me spend another days by tweaking himera straight IF2000 wheas free on X3D, again🤕
Zuletzt bearbeitet:
unifyx
Profi
Ich bin da unschlüssig. Da ist soviel Unwissen bis hin zum Schamanentum mit dieser Frage verbunden. Ich hab jetzt im letzten Monat 4 Stück vom 5800X3D durchgenudelt. 3 hatten bei ungünstigen Bedingungen die WHEAs in 100er-Paketen, einer wirft nur relativ wenige in TM5. Aber mit welcher Magie man die letzten in den Griff bekommt, hab ich nicht gesehen. Ich geh soweit, dass ich sage, die mit den 100er-Paketen sind garnicht zu gebrauchen. Ob man mit den anderen etwas anfangen kann - ich glaubs nicht.
Es wird nichts mit Timings zu tun haben. Dass riesige Spannungen was helfen, konnte ich hier bei meiner #4 vor zwei oder drei Seiten hier falsifizieren. Ich glaub, wie es Bread sagt (glaub ich war es), dass es ja ein Problem des Speichercontrollers in der CPU und nicht im RAM ist. Also wie müsste man die CPU einstellen, damit es zu möglichst keinen WHEA 19 kommt?
AGESA mögen da potentiell nen Einfluss haben können, aber ich wüsste auch nicht, welche davon. Mirt wurde geraten, "ganz alte" zu verwenden - aber die unterstützen dann den X3D nicht.
Und nicht jeder, der sein IF2000 Setting postet, hat wirklich keine WHEAs.
Es wird nichts mit Timings zu tun haben. Dass riesige Spannungen was helfen, konnte ich hier bei meiner #4 vor zwei oder drei Seiten hier falsifizieren. Ich glaub, wie es Bread sagt (glaub ich war es), dass es ja ein Problem des Speichercontrollers in der CPU und nicht im RAM ist. Also wie müsste man die CPU einstellen, damit es zu möglichst keinen WHEA 19 kommt?
AGESA mögen da potentiell nen Einfluss haben können, aber ich wüsste auch nicht, welche davon. Mirt wurde geraten, "ganz alte" zu verwenden - aber die unterstützen dann den X3D nicht.
Beitrag automatisch zusammengeführt:
Nein, meines Wissens gibts die. Zumindest behauptet von Leuten, wo ich nicht davon ausgeh, dass die Lügen. Aber ich denk, es sind extrem wenige Chips.
Und nicht jeder, der sein IF2000 Setting postet, hat wirklich keine WHEAs.
unifyx
Profi
@unifyx
Ich denke, die SOC Spannung und LLC können vielleicht was helfen. Dann die 3 Nebenspannungen sowie die Spannungsversorgung der CPU. PBO und CO?
So, jetzt haben wir zuviele Variable und jeder Testcycle kostet, hm, 5 min? (Neustart ins Bios, Werte ändern, Save, Neustart ins Windows, HWinfos an, TM5 an bis die ersten WHEAs kommen)
Da hab ich garnicht die Zeit für so ausgedehnte Testreihen, wobei auch nicht klar ist, ob das überhaupt was bringt.
Ich war bei vorheriger AGSA 120B (Asus 4702) bei nem Setting soweit, dass ich nach 2 min TM5 (Extreme1@anta777) bei genau 2 WHEAs war. Die 120Ca wirft mir etwas mehr WHEAs. IF2000 vorausgesetzt. Ich sag bei nie ne Verbesserung wenn ich auf 1966 oder 1933 runterging.
Ich denke, die SOC Spannung und LLC können vielleicht was helfen. Dann die 3 Nebenspannungen sowie die Spannungsversorgung der CPU. PBO und CO?
So, jetzt haben wir zuviele Variable und jeder Testcycle kostet, hm, 5 min? (Neustart ins Bios, Werte ändern, Save, Neustart ins Windows, HWinfos an, TM5 an bis die ersten WHEAs kommen)
Da hab ich garnicht die Zeit für so ausgedehnte Testreihen, wobei auch nicht klar ist, ob das überhaupt was bringt.
Ich war bei vorheriger AGSA 120B (Asus 4702) bei nem Setting soweit, dass ich nach 2 min TM5 (Extreme1@anta777) bei genau 2 WHEAs war. Die 120Ca wirft mir etwas mehr WHEAs. IF2000 vorausgesetzt. Ich sag bei nie ne Verbesserung wenn ich auf 1966 oder 1933 runterging.
Silberfan
Experte
Oc hat sich in den Anfängen mal gelohnt.
Heute bringt es echt nichts mehr auch wenn viele träumen das es was signifikantes bringen wird.
Grundvorrausetzung ,eine gute Kühlung ,und die haben sowieso die wenigsten.
Heute bringt es echt nichts mehr auch wenn viele träumen das es was signifikantes bringen wird.
Grundvorrausetzung ,eine gute Kühlung ,und die haben sowieso die wenigsten.
@Silberfan Mal mit Verlaub: schreib das in nem andren Forum. Was glaubst, was n Luxxer hat? Der Trend geht zum Dritt-MoRa.
Bread
Experte
Same here - "fast fehlerfrei" meine ich mit "ab 1900 / 3800 gibts WHEA"
Ja eh nur 1-2 am Tag. Aber die eben schon. Kommt nicht in Frage für mich.Unterschreib ich.
5-10% sinds schon. Bzw 5% mehr Leistung bei ~20% weniger Stromverbrauch.
Unterschreib ich nicht - hier gehts eben um die 5-10% / 20-40W, und Optimierung aus Prinzip.
Ja, und hier nein, weil eben:
unifyx
Profi
@Bread
Beim Dual CCD ist es auch glaube nochmal schwerer. Mein 5900X kann FCLK 1900 / RAM 3800 komplett fehlerfrei und das schon mit nur 1v SOC und läd auch mit DDR 4533 asynchron ins Windows. Mehr FCLK hat immer whea und am wenigsten mit SOC 1.065v.
Es bringt aber nix, da Fehler immernoch Fehler sind. Also bleibe ich bei 1900/3800 und geniesse ein stabiles System.
Beim Dual CCD ist es auch glaube nochmal schwerer. Mein 5900X kann FCLK 1900 / RAM 3800 komplett fehlerfrei und das schon mit nur 1v SOC und läd auch mit DDR 4533 asynchron ins Windows. Mehr FCLK hat immer whea und am wenigsten mit SOC 1.065v.
Es bringt aber nix, da Fehler immernoch Fehler sind. Also bleibe ich bei 1900/3800 und geniesse ein stabiles System.
Agreed, just get rid of BCLK as @Veii suggested, found no go for IF2000 wheas free, no matter what I tried, at least straight 3933IF1967 you can try, work for me CL15 tRCD16 👍
Working in progress right now, CL14 tRCD15 more tighten timmings, so far so good, wish me luck🙏
Anhänge
Zuletzt bearbeitet:
Haha
Wife (and children) have much higher priority. Take your time
Sehr sehr vieles ist dynamisch, nahezu alles ist load balanced und hat seine alters/temperatur kurve.
Die Kühlung hat Einfluss auf das Trainings Verhalten, was du dann als "brauchbare VID Kurve" mitbekommst
Jedoch siehst du von dieser nichts. Alles geschieht im Hintergrund.
Das naheliegendste Beispiel wäre RDNA2.
Kaum zu Unterscheiden von Zen. Andere (soft)IP Blöcke, weniger eigene Clocks (Arten) aber eigentlich, kaum zu Unterscheiden.
Overclocking wie man es leider heute noch macht (2015, fixed frequency, fixed voltage)
Ja, damit kommt man nicht weit.
Wenn der Nutzerbase dann auch die Tools Fehlen um mit den öffentlichen und nicht so öffentlichen APIs zu interargieren,
Um irgendwas auslesen zu können was man eigentlich nun macht;
Ich kann verstehen weswegen es "Sinnlos" erscheint
3 things you should do:
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
2nd,
Check your SKUs internal FW state.
How many loggers and sensors are actually active.
Sometimes new AGESAs push through their patches, sometimes it doesnt
Sometimes it needs a full cold-discharge and plug in, for the patches to inject into the CPU
Sometimes it needs a flashback flash and then Bios tool reflash for the patches to apply to Chipset and CPU.
Its a mess, but its what it is;
3rd,
Please give me some data to look at
This sectionMemory subsystem on AMD is decently understandable.
But you still are at the mercy of internal communication, before ever bothering with mem.
Run RopBench first
I want a clean , no programms , barely services no mousemovement
~ test
// sequential cores , memory latency and core 2 core
Then focus on WTRS stability without introducing new variables & no voltage change !
We target value 4, later target value 2 - but thats too much torture at first
Then i want to see an SiSoftware Sandra (Inter thread) benchmark + log
And only then we go to RCD targeting value 15.
Idcare if "its hard"
Your BCLK and Clock shenanigans we'll verify with those two programms if they do anything helpful whatsoever
Or its just virtual clock that has no internal weight & may perform "faster" due to L$ & SOCCLK being higher which is relative to coreCLK
Ignore the memory side for a bit (after you're done)
And start to track whats going on internally.
WHEA #19 is "report created but lost in Void"
Kind off.
Its condition corrected but GMI lost package of data, error condition unknown , report lost in Void
Pretty much this.
We've been since 2021 on this and the information is out. Just read it; (not you as target)
But its a "side effect", readout.
Because everything is loadbalanced.
If you ever get WHEA, it needs to be known from what they came.
Early it was Realtek NIC. That should be resolved by now from Drivers and AGESA (DXE) Blobs.
Later Intel's i225-V (revision 1 especially and 2) had trouble which needed a FW upgrade. (This was supplied too); Some Boards same Revision, had Rev3 of the NIC.
Further down the Road Chipset itself (supply) and USB/SATA dropouts from GMI link ~ caused an issue (LCLK topic)
Then came PCI 4 cards requiring different PCI redriver settings and some boards being build badly on that regard. Soo LCLK got another tuning and people had chipset issues
With chipset issues came then sound dropouts, because thats also PCI (and sometimes current AGESA still has those flukes at 2100 FCLK, if voltage is not perfect and procODT is nicely set)
All those, just one error on them, will cause a WHEA.
I hope you understand.
I hope you guys even read this and stop putting everything to "IMC cant handle it"
Because picture is clear, but only if you dare to try and figure it out
Zuletzt bearbeitet:
Bread
Experte
OK, to be more precise: usually it´s IO-Die = IOD that can´t handle it. If WHEA up to IOD 1,050V @ IF 1900, no WHEA beyond 1,055V @ IF 1900, while always WHEA at IF 1933+: I think you can very well simplify that to "IOD can´t handle it". IOD includes IMC, and because of 1:1:1 for FCLK / UCLK / MCLK the IO-Die is clocked to it´s limits. And sure, especially on the edge of stability, AGESA & drivers can make the difference between some WHEA or none. We seem to have different styles, I am all about Pareto and simplification for easier initial understanding, with iterative 80/20 results for most folks, while you tend to bring all the 100% to the table I find this very interesting, tho I hope you stop trying to stop us from still giving pragmatic, step-by-step advice and sharing experiences IOD mostly relates to GMI (and xGMI)
That mostly relates towards the chipset and the board peripheral.
// may or may not relate to CCD to CCD communication, but i'm not confident enough on that.
// VDDG CCD should branch on that part rather and take over part of L$. CPU1P8 likely does too, but not sure here;
But IOD issues for VDDG, mostly relate to (here especially different on AM5), to SOC and procODT issues.
VDDG itself is dynamic and loadbalanced. Supply between CCD & IOD herby is dynamic based on the input you give.
The input you give has a delta it requires based on if single-CCD or dual CCD. How much SOC that substrate requires.
// this is familiar to Matisse, Vermeer is the same just the substrate is more tolerable and can work with weaker procODT + lower voltages, X3D especially.
Pushing VDDG higher while might increase "relation of need", like the priority of voltage taking vs CCD section
But its only a VID.
Supply comes from SOC and supply strength to sample leakage (unique per sample, same SKU) is the outcome of thermal, socket vendor (should be standardized now) and SOC voltage itself
Those influence "requirement of voltage to reach X"
Stronger procODT (which they can take) , stronger effect of voltage and 1.8v CPU1P8 supply rail.
Soo herby lower VDDG and lower SOC.
Dynamic variables, nothing goes alone
For the IMC, you neither need SOC nor VDDG.
Sorry, i dont think this is correct.
IMC supply and upkeep voltage on AM4 is solely cLDO_VDDP
There is a VDDP_CPU supply that crosssections APUs too - soo it might! unclear, have an effect for GMIs
But no, UCLK itself which is main IMC clock (multi stage) ~ has no connection to SOC or to VDDG.
// GMI, LCLK & FCLK usually are dynamic on our samples ~ even if sillyheads AMD engineer stopped using dynamic FCLK+dynamic SOC (V) on frontend and hate to talk about this
// Its a difficult topic i get it, but wasting 25A vs 5A on idle ~ times SOC voltage soo about 35W vs 8-12W , i dont know. Such a silly waste of resources and efficiency
procODT and CPU1P8 does influence it
But those are side product influences. A "side-issue".
Once you set FCLK, only your sample strain towards general impedance (procODT) and your IMC tollerances to cLDO_VDDP
Are what define your maximum MCLK
VDDG & SOC need zero touch.
ProcODT for MemOC generally needs no touch, but its an old community habbit;
EDIT:
Soo based on this mess, you later define your ODTs that send the signal to mem
And your RTTs that amplify and do gate for their target need (chipselect, rankselect and so on)
EDIT2:
Technically speaking, LDO's are not an"input supply" either but an upkeep gated dropout regulator
Ah its fine, should be understandable nevertheless. 🤭
But all VIDs are priority loadbalanced. They are very far away from constant supply.
I dont have anything negative , bad or forceive in my mind or actions. Zerotho I hope you stop trying to stop us from still giving pragmatic, step-by-step advice and sharing experiences
All emotes are neither passive nor active aggressive. Absolutely zero.
If i write them i mean it ~ very happy right now to be honest
I just wish that , how do i phrase it
I just wish that LUXX delivers better.
You guys have much more accurate research and germans generally are known for perfectionism
I want to hold you to that ~ but will never force this onto somebody
Selective (random) people i try to help, i want them "to not give up" even if its difficult and confusing due to lack of documentations;
Thats about all. It doesnt need to be first place or anything. If person learns and shares that knowledge further, pulling other people up ~ im happy
I hope thats understandable
Zuletzt bearbeitet:
