[Sammelthread] Intel DDR5 RAM OC Thread

"Hyper-Threading (HT) / Simultanes Multithreading (SMT) :
Diese Funktion ermöglicht es dem Betriebssystem, einen physischen Kern als zwei virtuelle Kerne zu betrachten. Diese Funktion ist zwar gut für High-Threaded-Lasten wie Rendering oder Kompilierung, erhöht aber die Latenz des Systems massiv. Dies liegt daran, dass die Kerne nur eine Ausführungseinheit haben, was dadurch verschlimmert wird, dass das Betriebssystem versucht, die Last auf beide virtuellen Prozessoren desselben Kerns zu verteilen, was zu einem Stillstand führt, während die Ausführungseinheit des Kerns mit dem zweiten logischen Prozessor beschäftigt ist."
Woher kommt das Zitat
Es fehlt soo viel an Daten.

Ich mein falsch ist es nicht
Aber wirklich Richtig ebenso nicht.

"Ausführungseinheit"
Die Bufferqueue ist riesig.
Und coreclock heißt im Grundegenommen garnichts.
Load balanced.
und diese am besten mit soviel mhz wie möglich ...
Das ist leider nicht der Fall
Der CoreCLK ist quasy unwichtig

Es ist ein summierter Wert (placeholder)
Wie oft der angegebene (virtuelle) Wert , im weiteren Placeholder Wert (mhz/sec) gesendet werden darf.

Zu dieser Rechnung nun gehören, dass die BufferQueue nur so voll werden kann, wie der opcache die jeweiligen Instructionsets (größe und art) , in kleinen Chunks/Happen unterteilt werden können.

Somit bei kleinen FFT "Päckchen" füllt es die Bufferqueue schneller, und somit wird mehr hitze erstellt, da die gesammtlast höher ist.
// sehr simplifiziert

Manche SKUs können zb AVX2 nativ innerhalb eines Cycles bearbeiten
Andere ehmalige zersetzen den AVX256 blob in doppelte AVX128 päckchen und brauchen 2 clockcycles.

Usw und so fort
Im Grundegenommen, bedeutet die Kernfrequenz garnichts.
Was reale Leistung ausmacht, ist die größe der Bufferqueue (backend)
Die effektivität des Branchpredictors & OPCache (wie gut es "loadtypes" erkennen und in kleine Happen zersetzen kann)
Und dann zu welcher Leistung der gesammte Transfer stattfinden kann

QCLK, RINGCLK, FCLK, CoreCLK
Auf diesem dann die effektivität des IVR (MHz) & DVFS design
Sprich innerhalb wie vielen cycles darf es die Spannung regulieren, bis die Kerne nicht mehr die Frequenz halten können und nochmal ein chunk spannung sich nehmen müssen.

Diese effektivität des designs, gibt im Grundegenommen den maximalen Takt des Samples an.
Manche sind leaky manche weniger.

Alles so simplifiziert wie möglich.
Doch eigentlich bei "roher leistung" spielt nur die Cache geschwindigkeit eine Rolle und die interne latenz wie sehr kerne nach derren L1Data, L1Instruction
Zu L2 und dann runter zu dem globalen L3 cache, daten ablagern

Da jeder Kern Zugriff, wie bei der GPU vom VRAM
Muss runter zu dem cache, bevor entschieden wird ob man Daten vom Ram hin-und-her laden muss
Oder es Intern schneller ist mit niedriger Latenz, um Daten hin und her zu tauschen.
Beitrag automatisch zusammengeführt:

Oft braucht es weder eine schnelle abtastrate (niedriger coreclk ist ok), noch spannung oder leistung um das Datenpäckchen zu bearbeiten.

Oft haakt es auch an der Application selbst, welche Art von Daten sie versendet und ob ihr überhaupt bekannt ist wie viele Threads im system sind.

Der application interessiert es nicht wie viele Threads existieren.
Sie muss nur wissen wohin sie es laden soll.
Je nachdem was die CPU dem Betriebssystem mitteilt

Welcher kern weitere commands erwarten kann, und was "noch in stau ist" und gerade bearbeitet wird.

Alles eine kurzfassung.
Am handy schreibt es sich schwer :-)
Beitrag automatisch zusammengeführt:

Mit anderen Worten, stört es nicht ob 2 oder 4 threads pro Kern existieren
Die Bufferqueue ist global
Welche Kerne reinladen, ist unwichtig.

Und nein jeder Kern kann mehr als einen Command bearbeiten : ')
Im Grundegenommen ist es weitaus schneller Daten innerhalb des Virtuellen Kerns zu bearbeiten , damit die Bufferqueue effizienter von "schwachen" Lasten gefült wird.

Als zwischen weit entfernten Kernen zu springen, durch den Cache zu müssen und dann dadurch weitaus mehr Spannung reinladen muss, um mehr als einen Kern zu versorgen.
Da kern lasten nicht linear skallieren und alle derren eigenen Chunk an Spannung brauchen.

1kern 700mV
2 kerne 1400mV
Funktioniert zb nicht als Rechnung

Auch nicht,
1 kern 800mV
2 kerne 900mV
3 kerne 1000mV

Ebenso ein Märchen
So funktionieren CPU designs nicht :-)
Threads stören nicht. Es gibt nur leicht "suboptimal-designte" Programme, welche hier und da etwas Druck brauchen, daten Inteligent zu verteilen. :d

Im aktuellen Intel Design,
Ist die Backend groß genug um effizient zu arbeiten und diese zu füllen.
Im zukünftigem Design, wird der HT entfernt und neu-designed.
Das hat mir der aktuellen SKU jedoch nichts zu tun.

Alle CPUs funktionieren perfekt, so wie sie aus Intel-HQ kommen.
Die CPU zu kastrieren, nur weil eine Application abenteuerlich resourcen verteilt ~ ist etwas unlogisch und eine umgehung des eigentlichen Problems.
Ebenso eine verschwendung des Designs und einschränkung potentieller Leistung.
Den zwischen Kernen zu springen ist abseits langsamer, auch stromfressend.
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
die meisten infos sind zusammengesammelt , habe auch viel von freunden oder selbst getestet. habe auch geräte zum testen wie nvidia reflex analyzer , habe aber auch syslat und osrtt ... (ldat kann ich mir bei einem mate leihen ab und zu)

habe zb beim csgo bench leute "nass gemacht" die deutlich stärkere hardware haben und das locker mit meinem 24/7 setup ohne großes oc ... (ht macht da fast 100fps unterschied)

csgo bench:

wQbTwNK.png


ich habe auch andere spiele getestet bei denen das thema HT an oder aus existiert ... und gewaltig einen unterschied macht.

gute infos findet man zb bei "Calypto's Latency Guide" oder von Amit (der hat den csgo autobench programiert)

generell teste ich viel selbst (veröffentliche halt nur nicht viel)

ein beispiel...

reBAR_fps.png


oder cs2 mit ecores an/aus (13900k alles stock) -> sowas testet halt normalerweise keiner

APS1HEQ.png


achja und core2core hab ich auch schon paar mal getestet aber ich find die ergebnisse nicht mehr - das war damals zum release vom 13900k ca.

getestet hatte ich mit MicroBenchX das ist von der capframex jungs.


Die CPU zu kastrieren, nur weil eine Application abenteuerlich resourcen verteilt ~ ist etwas unlogisch und eine umgehung des eigentlichen Problems.
Ebenso eine verschwendung des Designs und einschränkung potentieller Leistung.

man kastriert sie im grunde ja nicht wirklich,

du nimmst multicore leistung weg (die du im gaming eh nicht benötigst) und wärme nimmst du auch weg
und gibst die leistung deinen pcores die höher takten können weil die cpu overall kühler bleibt

im fall von csgo waren 100mhz 15-25fps ...

das man die cpu dann nichtmehr inerhalb der spezifikationen betreibt sollte aber klar sein.


- im übrigen rede ich hier von allen spielen die im cpu limit sind , sei es valorant , csgo , cs2 , fortnite , rb6 , apex und und und -
aber egal lass nun gut sein
 
Zuletzt bearbeitet:
und gibst die leistung deinen pcores die höher takten können weil die cpu overall kühler bleibt
Ich bin mir nicht sicher ob du Leistung auf MHz beziehst
Und Leistung als fixierten Clock ausmachst.

Ich sehe viel Testing, aber kein Nachgehen des Problems
Der APP und das Betriebssystem

Die CPU arbeitet perfekt, so wie sie aus Intel's lager kommt.
Von Tweakern halte ich nicht viel, tut mir leid.
Die Logik der meisten ist auf positiven Beobachtungen basiert ohne die Tradeoffs zu beachten.

Die Calypso Person wäre mir bekannt.
Sehr viele Leute mit OS Problemen kaamen ehmalig zu mir (momentan den Kumpel welcher als SI tätig ist)
Da diese Leute Registry Sachen empfehlen, welche sich schon im Berreich Snakeoil befinden.

Auf gut deutsch heißt es "verschlimmbessern"
Ein Beispiel davon wäre die Empfehlung die kerne auf konstanter max-last zu halten und C/P states zu deaktivieren
Welches konstant 1.43-1.45v im Idle durchlässt, da man einen Exploit im Powerplan nutzt.
Das Problem hier wäre, dass diese Architektur kaum Clock-gated ~ zumindest nicht im Frontend.

Usw und so fort.
Das Thema mit "BAR off" ist schneller
Ist ein ähnliches. Placeboo, ohne erklärung weswegen Frametime desync zwischen GPU & CPU in X tests bessere peak framerate erzeugt ... und weiteren schmarn. 🤭

Tut mir leid,
Mir alles bekannt.
Ich war in dieser Szene und glücklich einen klaren Kopf gefunden zu haben.
Alles beruht auf vertrauen und "testen".
Nahezu niemand von diesen Tweakern macht sich die mühe derren Änderungen nachzufolgen , geschweige den zu verstehen.
Es wird nur "Daten" auf Abwurfebene gesammelt. "Throw stuff at the wall and see what sticks, not why it does or doesnt".

Ah , muss mich nicht kümmern
Aber ich möchte dir erklären dass du etwas durch viel Tweaking übersiehst.
Und zwar das "Wieso & Warum"

Die CPU beginnt nicht plötzlich intern anders zu arbeiten , nur weil man den Oberflächlichen Teil der Dynamik ruiniert bzw die CPU kastriert.

Ohne diese Fragen,
kann man kaum von Main vs Side-Issue unterscheiden und reitet sich nur weiter rein in diesem Tweakers feld. :-)
Ich hoffe es kommt die Zeit worin auch du diese Empfehlungen hinterfragst. Auf hardware ebene :geek:

Die beiden Seiten wären sehr empfehlenswert :giggle:
Beitrag automatisch zusammengeführt:

die im cpu limit sind
aber egal lass nun gut sein
Was bedeutet das "CPU limit" ? :)
Was limitiert den innerhalb der CPU & wie kann es Intel/AMD besser machen ?
Beitrag automatisch zusammengeführt:

man kastriert sie im grunde ja nicht wirklich,

du nimmst multicore leistung weg (die du im gaming eh nicht benötigst) und wärme nimmst du auch weg
und gibst die leistung deinen pcores die höher takten können weil die cpu overall kühler bleibt
Ob man nun den Zugriff zu den "Cache und E-Cores" abschaltet
Oder intern "die Chance auf effizientem befüllen der BufferQueue" verhindert bzw limitiert. Nun "downgraded"

Ist die reine Definition von "kastrieren", mit der Ausnahme dass man es Rückgängig machen kann.
Eine andere Definition dafür abseits "Verschlimmbessern" wäre, "Downgrading mit situationsbasierten Einzelziffer % Austausch von potentiellem Zugewinn"

Ah beides kommt auf das selbe hinaus.
Sobald man seine Sicht außerhalb des Betriebssystem setzt und erkennt was man der Hardware antut,
Sollte sich zeigen dass man sich in einem Teufelskreis voller selbst-erstellten Problemen befindet.
Ich bin mir nicht sicher ob du Leistung auf MHz beziehst
Und Leistung als fixierten Clock ausmachst.
Beides wäre mit "nein" zu beantworten.
Weder das eine, noch das andere definieren Rohleistung.
CoreClock ist nur einer von mehreren Frontend Clocks.
Er ist sehr unwichtig~

Er war wichtig im Jahre 2015 worin man noch auf Allcore-Clock setzte.
Wobei Intel's DVFS & IVR auch schon damals existierte :coffee3:
Weswegen man auch damals auf fixiertem Clock ging, ist unverständlich.
Womöglich einfach fehlendes Belehren der Community(s) wie deren Hardware funktioniert.
Beitrag automatisch zusammengeführt:

steamwebhelper_DdlKmrBIeQ.png
brave_u9AsdMaDTg.png

65GB ~ do i really want to bother
Ugh, rather not. You can stay #1.
Better for ego 🤭 maybe suboptimal for future, but oh well~
habe zb beim csgo bench leute "nass gemacht" die deutlich stärkere hardware haben und das locker mit meinem 24/7 setup ohne großes oc ...
(ht macht da fast 100fps unterschied)
1711381949444.png
 
Zuletzt bearbeitet:
SA 1,25
VDD 1,49
VDDQ 1,44
IMC 1,4
VDDQTX 1,35
Screenshot 2024-03-25 164759.png
mehr folgt...
 
Zuletzt bearbeitet:
@AndreasP1981
Ja alle DD, DR auf 0 ~ ABER auch nur wenn "alle unbenützten RTLs" auf 0 sind.
ich hatte die tWRRD_SG/DG übersehen.
Korrigiert aber du warst schneller. Mein Fehler :-)

EDIT:
R0 & R2 auf AUTO
R1, R3-R7 auf 0
So gehörts , whops ~ müde.

Vorherigen Post korrigiert.
 
@AndreasP1981
Ja alle DD, DR auf 0 ~ ABER auch nur wenn "alle unbenützten RTLs" auf 0 sind.
ich hatte die tWRRD_SG/DG übersehen.
Korrigiert aber du warst schneller. Mein Fehler :-)

EDIT:
R0 & R2 auf AUTO
R1, R3-R7 auf 0
So gehörts , whops ~ müde.

Vorherigen Post korrigiert.
alles eingestellt wie geschrieben, das kam raus:
1711384291236.png

Beitrag automatisch zusammengeführt:

tWTR L +4
WRRD dg/sg gingen hoch
Beitrag automatisch zusammengeführt:

Voltage auch 10mV zu hoch
Beitrag automatisch zusammengeführt:

WRRD dg/sg gingen hoch - hab deine korrektur übersehen, mein fehler
 
Zuletzt bearbeitet:
tWTR L +4
WRRD dg/sg gingen hoch
Auslese Fehler
WTR um 4 zu hoch :)
Ein ATC Problem.

WRRD kann auf auto.
Die RTLs hast du vergessen.
Voltage auch 10mV zu hoch
Das Passt so.
PMIC autokorrigiert & es ist load-balanced.

>1430mV ist der erste OC mode step. 1425 der letzte 5mV nicht-OC mode.
PMIC steps von 15mV, aber da OC mode in steps auf 10mV geht (anstelle 5)
Sind es steps of -15, 0, +15mV ~ aka 30mV jumps.
 
mal zum vergleich
1711385499979.png
1711385524085.png
 
hat er mit 21 jetzt eh nicht gepostet

die hatte ich auf:
R0/R2 auto
R1/R3-R7 0

Jetzt auf:
R0/R1 auto
R2-R7 0
Anhang anzeigen 984497
Yap, Zeit fürs Bett
Ich mache amateur Fehler.
Encore hat ein minimal anderes channel layout, als das APEX
A1 & B1 vs A0 & A4

alle "25er" RTLs , auf 0.
tRDWR_SG/DG auf 21
tWRRD = auto.

Soo , gut "Nacht" und viel Glück
TM5 muss seine 25 cycles durchrennen (mit Adminrechte), Karhu auf 20 000%
Y-cruncher VST+VT3, oder N63+VT3 auf 90+ minuten (component stress test)
// aka 23 cycles

ICCMAX auf 400A oder 346A bei einer AIO Kühlung
VR Regulator Max , VRMAX auf 1.55v
^ Sicherung gegen degredation.
PL1/2 sind vorerst unwichtig. Können auf 4096W

🌌🛌💤
 

Anhänge

  • TM5_0.12.3_1usmus25-CoolCMD.zip
    25 KB · Aufrufe: 32
1711390011281.png

Also 8400 will er bei mir bis jetzt nicht. SA 1.2, MC 1.45, CVDDQ 1.31, MVDD 1.56, MVDDQ 1.5

T-Force Xtreem 8200 24x2 M-Die
 
Zuletzt bearbeitet:
TM5 muss seine 25 cycles durchrennen (mit Adminrechte), Karhu auf 20 000%
Y-cruncher VST+VT3, oder N63+VT3 auf 90+ minuten (component stress test)
TM5 lief durch.
y-cruncher nicht wirklich lange...
 

Anhänge

  • TM5 usmus.jpg
    TM5 usmus.jpg
    538,1 KB · Aufrufe: 53
  • y-cruncher VST VT3.jpg
    y-cruncher VST VT3.jpg
    611,8 KB · Aufrufe: 49
....coefficient error kann aber auch ein avx fehler sein. Vorschlag: Setze mal einen negativen AVX Faktor im Bios und lass mal das RAM Settings unberührt. Möglicherweise kommt Y-Cruncher durch oder zumindest sehr viel weiter. @AndreasP1981
Beitrag automatisch zusammengeführt:

Anhang anzeigen 984534
Also 8400 will er bei mir bis jetzt nicht. SA 1.2, MC 1.45, CVDDQ 1.31, MVDD 1.56, MVDDQ 1.5

T-Force Xtreem 8200 24x2 M-Die
spiele bitte nicht an den Spannungen unter Windows mit turbo v-core rum. Habe mir mal ne CPU damit geschrottet.
 
Zuletzt bearbeitet:
....coefficient error kann aber auch ein avx fehler sein. Vorschlag: Setze mal einen negativen AVX Faktor im Bios und lass mal das RAM Settings unberührt. Möglicherweise kommt Y-Cruncher durch oder zumindest sehr viel weiter. @AndreasP1981
Beitrag automatisch zusammengeführt:


spiele bitte nicht an den Spannungen unter Windows mit turbo v-core rum. Habe mir mal ne CPU damit geschrottet.
Habs nur offen um die Spannungen zu zeigen.
 
..habe auch mal die 25 er RTL auf 0, kapiere aber ganz und gar nicht warum :LOL:
 
....coefficient error kann aber auch ein avx fehler sein. Vorschlag: Setze mal einen negativen AVX Faktor im Bios und lass mal das RAM Settings unberührt. Möglicherweise kommt Y-Cruncher durch oder zumindest sehr viel weiter. @AndreasP1981
er hatte eh nur noch 5,5 auf den P-Core und 4,4 af den E-Core bei dann ~250W, aber morgen Vormittag gehts weiter :giggle:
 
..habe auch mal die 25 er RTL auf 0, kapiere aber ganz und gar nicht warum :LOL:
So wie ich das verstanden habe, erleichtert man dem Board das Mem Training, da es die Werte, die für Single Rank Speicher (oder SS?) irrelevant sind, nicht trainieren will.
 
So wie ich das verstanden habe, erleichtert man dem Board das Mem Training, da es die Werte, die für Single Rank Speicher (oder SS?) irrelevant sind, nicht trainieren will.
_dr _dd ja das hatte ich verstanden , glaube ich, da weder t-topology noch daisy chain 4 dimm. Aber man soll ja RTL 0 und dr dd nullen.
 
Bei mir macht ein OC generell wohl erstmal weniger Sinn da bei Volllast aller Komponenten die Ram Temp stark mit steigt. Hab das Gefühl dass der Riegel aber nicht ganz abgeneigt ist etwas straffer zu laufen. Muss mal abwägen wie sehr ich Bock drauf hab, denn für mich kommt dann nur eine Custom Wakü in meinem SFF in Frage. Zerstört ein wenig die kompakte Optik, erhalte dafür aber volle CPU und RAM Leistung + Option auf eine viel stärkere GPU. Hm.
 
_dr _dd ja das hatte ich verstanden , glaube ich, da weder t-topology noch daisy chain 4 dimm. Aber man soll ja RTL 0 und dr dd nullen.
1DPC
Und dass du standartmäßig delays von DR & DD benützt, obwohl es nur single sided ist
Dementsprechend sind die MC links aktiv und ihr Zielort verlängert

Das ausschalten (0 anstelle 1) der bestimmten Timings, sollte dementsprechend auch die RTLs ausschalten
Dafür gibt es jedoch kein algorithm, weswegen man es per Hand machen muss
 
Zuletzt bearbeitet:
TM5 lief durch.
y-cruncher nicht wirklich lange...

du machst halt zuviel gleichzeitig , das bist doch auch du oder ?

mzxz8DV.png


m7K6l2f.png

bei solchen settings die du (falls du das bist) da einstellst brauchst du dich nicht wundern das der vst nicht durchrennt ...

ich würde dir raten mach entweder erst das cpu oc stable (also richtig richtig stable und nicht nur cb23 sondern das volle programm) oder resette und fang mit ram oc an ...
beides auf einmal funktioniert einfach nicht ... man zieh die fehler vom einen oc ins andere oc

du wirst so niemals rausfinden was genau das problem macht , geschweige denn ein wirklich stabiles system haben ...
Beitrag automatisch zusammengeführt:

ps: ich mag dein cooler score !
 
Zuletzt bearbeitet:
du machst halt zuviel gleichzeitig , das bist doch auch du oder ?

mzxz8DV.png


m7K6l2f.png

bei solchen settings die du (falls du das bist) da einstellst brauchst du dich nicht wundern das der vst nicht durchrennt ...

ich würde dir raten mach entweder erst das cpu oc stable (also richtig richtig stable und nicht nur cb23 sondern das volle programm) oder resette und fang mit ram oc an ...
beides auf einmal funktioniert einfach nicht ... man zieh die fehler vom einen oc ins andere oc

du wirst so niemals rausfinden was genau das problem macht , geschweige denn ein wirklich stabiles system haben ...
Beitrag automatisch zusammengeführt:

ps: ich mag dein cooler score !
Ich weis nicht wie dein BIOS aussieht, aber meins hat mehrere Speichermöglichkeiten ;) bedeutet auch das ich nicht alles was vorher stabil lief nicht einfach überschreibe/lösche...

ich würde dir raten mach entweder erst das cpu oc stable (also richtig richtig stable und nicht nur cb23 sondern das volle programm) oder resette und fang mit ram oc an ...
beides auf einmal funktioniert einfach nicht ... man zieh die fehler vom einen oc ins andere oc
und hier, das es nicht komplett aus dem Kontext ist die Fragestellung dazu:
1711488556282.png

also Antwort, ja ist möglich, aber all Day würd ich das niemals so laufen lassen...
Und schon war ich wieder zurück auf den Einstellungen mit denen TM5-anta preset/usmus preset, karhu und y-cruncher durch lief
du wirst so niemals rausfinden was genau das problem macht , geschweige denn ein wirklich stabiles system haben ...
seh da jetzt nicht was dich zu dieser Ableitung führt?
Darf ich User fragen in andere Foren nicht beantworten?

ps: ich mag dein cooler score !
kommt nur wenn du gottlos viel Leistung über die CPU prügelst...
aber ja, ganz nice das ding :giggle:
 
Ich weis nicht wie dein BIOS aussieht, aber meins hat mehrere Speichermöglichkeiten ;) bedeutet auch das ich nicht alles was vorher stabil lief nicht einfach überschreibe/lösche...
also Antwort, ja ist möglich, aber all Day würd ich das niemals so laufen lassen...
Und schon war ich wieder zurück auf den Einstellungen mit denen TM5-anta preset/usmus preset, karhu und y-cruncher durch lief

seh da jetzt nicht was dich zu dieser Ableitung führt?

sry aber du erzählst gerade echt quatsch, du selbst hast doch ein screen gepostet von tm5/vst ...

H4CQe6H.jpeg


dort sehen wir 400 watt auf p1 450 watt auf p2 dazu sehen wir die pcores mit 6.3ghz und die ecores mit 4.7ghz und wir sehen ein tm5 ...

im 2ten bild sehen wir gleiches mit vst

pIxWGrM.jpeg


von dir gepostet xD vielleicht bin ich auch lost - aber ... naja

quelle
Beitrag automatisch zusammengeführt:

am ende ist mir aber auch egal was du tust , ich wollte nur nett sein und dich darauf aufmerksam machen das es besser wär wenn du erst ein oc beendest und dann ein anderes oc anfängst

und wenn du es nicht machst , dich nicht wunder brauchst das du problem bekommen wirst :)
 
Zuletzt bearbeitet:
sry aber du erzählst gerade echt misst , du selbst hast doch ein screen gepostet von tm5 ...
was stimmt mit dir nicht?
von dir gepostet xD vielleicht bin ich auch lost - aber ... naja
ja leider, weil eigentlich habe ich deine tips bisher ernst genommen...

hier auf der gleichen Seite (473) hat mir @Veii andere Einstellungen vorgeschlagen die ich ausprobiert habe https://www.hardwareluxx.de/community/threads/intel-ddr5-ram-oc-thread.1306827/post-30332098
hier siehe Profil 8:
Bios.jpg
Profil 2 wegen der Unreal5 engine und dem pProblem mit dieser, Profil 5 das gleiche mit 8200
Stock erklärt sich von selbst denke ich, alle limits aktiv, stock halt...
usw etc pp
Beitrag automatisch zusammengeführt:

jetzt war ich auch schon lost xD
der post wars:
 
ich beziehe mich doch gerade auf das was du gepostet hast "y-cruncher nicht wirklich lange"

DaoyYAa.png


da wo vst nicht lief - das war definitiv kein stock profil ...

das war komplettes cpu oc ... daher ja auch den tipp mit nur einem oc :)

aber egal will nicht rumstreiten

..habe auch mal die 25 er RTL auf 0, kapiere aber ganz und gar nicht warum :LOL:

ja das ist auch mega quatsch sowas hab ich noch wirklich NIRGENDS gesehen ... aber naja ... (hab das auch gegooglt aber nix gefunden dazu)
 
Zuletzt bearbeitet:
da wo vst nicht lief - das war definitiv kein stock profil ...

das war komplettes cpu oc ... daher ja auch den tipp mit nur einem oc :)

aber egal will nicht rumstreiten
stimmt core ratio auf auto hat gefehlt, hat aber dank des hier empfohlenen ICCMAX
eh nur mit 5,4-5,3 auf den P-Core getaktet...
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh