[Sammelthread] Ryzen DDR5 RAM OC Thread

[RedF]

@RedF

Trrds = 8 ist nicht das minimum ABER😅
wenn die Formel gelten sollen die uns Veii genannt hat dann muss es 8 bleiben. Wenn trdrs unter 8 geht dann kann DDR5 nicht mehr im Burst lenght 32Mode senden. Und laut Veii gibt es dann andere Regeln. Wo er auch keine Formel hat.
Twtrs ist dann somit minimum 7 da trdrs-1 außer man verwendet den Trick von Veii. Muss man aber Ahnung haben um den punkt zu treffen
Ccdl minimum 10
müsste man schauen ob folglich scl 3 dann noch bootbar bzw. Stable sind. 11müsste aber gehen da scl dann 4 wäre

Wenn du magst schick mir die excel prüfe es gerne gegen und ergänze noch andere Timings und Tipps.

Frage wo stellst du die TCKE von 16ein laut Zentimings ist tcke 0 bei mir

Sage ja, da fehlt noch. Bin jetzt aber erstmal im Urlaub.
Schicke sie dir.

tCKE kann ich auch nicht einstellen. Kann eigentlich wieder aus dem Sheet.

 

[LuxSkywalker]

Version 1.30 spuckt bei mir immer den Fehler aus, dass nicht auf die Power Tables zugegriffen werden kann.

Bei mir auch

...
Frage wo stellst du die TCKE von 16ein laut Zentimings ist tcke 0 bei mir

ist bei mir auch 0 und finde keine Option im Strix-F UEFI

@RedF

Schönen Urlaub

 

[drival0605]

Moin!

Ich klinke mich hier einfach mal ein, weil es hier ja derzeit ans Eingemachte geht. Ich habe kürzlich auf 2x32 GiB aufgerüstet. Ich verwende folgendes Kit:

https://www.corsair.com/eu/de/p/memory/cmk64gx5m2x6800c32/vengeance-64gb-2x32gb-ddr5-dram-6800mt-s-cl32-memory-kit-black-cmk64gx5m2x6800c32

Das sind A-Dies und ich betreibe sie bei DDR5-6400. Ich kann auch mit DDR5-6600 booten, aber das ist mit einer VSoC von 1.3 V nicht stabil zu bekommen. Dementsprechend bleibe ich bei DDR5-6400.

Ich möchte ein konsistentes und stabiles System. Ich brauche nicht unbedingt messerscharfe Timings. Ich glaube, dass das Kit für DR ganz gut ist. Es kann zum Beispiel tCL 28 bei 1,47 V. Ich möchte aber derzeit erst einmal bei moderater Spannung (VDD = VDDIO = VDDQ = 1,35 V) bleiben. VVDGs und VDDP sind auf 1,15V und VDD MISC ist auf 1,1V.

Kurzum: Ich habe mitbekommen, dass man die Konsistenz am besten mit PYPrime prüft. Egal was ich mache, ich bekomme einfach kein annnehmbares delta hin. Die Werte weichen einfach zu stark von einander ab:

Testet ihr das auch im abgesicherten Modus, wie AIDA64 auch? Selbst mit absoluten stock-Settings und BIOS komplett auf default bekomme ich kein konsistentes Ergebnis hin. Woran kann das liegen? Kann es eventuell Sinn ergeben erst einmal alle Widerstände (ProcOdt,... & Rtts) und Spannungen korrekt einzustellen, bevor man die Timings weiter anzieht?

ZenTimings ist derzeit übrigens nur Work in Progress.

 

[Wolf87]

Wenn Windows im idle viel zu tun hat Steam offen voller Autostart. Dann kanns schon sein das pyprime schwankt. Guck mal auf github gibt pyprime 2.2 da läuft das 5 mal automatisch durch. Guck dir mal die Formeln von Veii an ich seh da z.b die scl, trdwr, die bissel niedrig sind TRas die safe variante von Veii nehmen dann sollte das nich mehr als 30ms schwanken.RedF ist auch dran ne excel zu bauen die Veiis Info zusammenfasst.

 

[drival0605]

Danke Dir üfr die Antwort.

Autostart hatte ich tatsächlich bereits geleert. Selbst sowas wie MSI AB habe ich rausgeschmissen. Es lief im Prinzip nur HWInfo. Habe hochgefahren, 5 Minuten idlen lassen, BenchMate gestartet, alle 6 Fenster geöffnet, auf dem Desktop verteilt, wieder kurz gewartet und dann erst gestartet. Ich probiere es aber noch einmal mit der Github-Variante.

Okay, ich ziehe die Timings erstmal ein wenig hoch! Was würdest Du denn für Werte empfehlen für die beiden SCLs und tRDWR? Das sind übrigens noch die stock-Timings, die mein BIOS nach dem BIOS-Update mit DDR4-4800 gesetzt hat.

Mit der safe-Variante meinst Du "tRCD + tCWL + tWR = tRAS = tRC"? Also in meinem Falle jetzt "40 + 30 + 48 = 118 = 118"?

Das Excel-File sieht mega aus!

 

[Wolf87]

Ja das ist die safe variante das glättet dir die Zahlen. Trc ist dann gleich TRas .

Mach hwinfo aus das kann es schon sein was stört

 

[Gelöschtes Mitglied 102156]

Nachricht gelöscht

 

[drival0605]

Okay, nachdem ich tRAS & tRC angepasst sowie tRDWR eins hochgesetzt habe, ist es etwas konsistenter geworden:

delta bei 0,54 (HWInfo aus!)

Ich probiere das noch einmal im abgesicherten Modus, falls das geht.

edit:
Im abgesicherten Modus passt das delta:

 

[Wolf87]

twrwrscl=25 da twtrl-8+1 =25 TRP=12 mal versuchen ob bootbar

 

[drival0605]

Ja, das bootet ohne Probleme.

 

[Gelöschtes Mitglied 102156]

Nachricht gelöscht

 

[drival0605]

Vddq =Vdd *0,94 grob

Ich habe hierzu noch einmal eine Frage:

Wenn man das grob so macht, wie passt man dann die VDDIO an, eher der VDD oder eher der VDDQ?

 

[Wolf87]

VDDIO = sollte gleich VDDQ sein etwas vielleicht 0,05V höher damit es sich synchronisieren kann wo bei das laut Veii Aufgabe vom Controller ist. Man kann ihn aber dabei ja unterstützen.

Ich weiß jedoch nicht wo die VDDIO safe Obergrenze ist bin bisher nie über 1,35 Volt gegangen. Also bei krassem Overvolting müsst ihr mal im Netz schauen wo da die Grenzen liegen.

Ich fahre VDDIO zurzeit bei 1,27 Volt

 

[LuxSkywalker]

Korrekt, ich fahre auch VDDQ = VDDIO - aktuell 1,15V bei 6000MT/s CL28

 

[Darki24]

Vielleicht könnt ihr ja damit was anfangen.
kA ob das jemanden von euch hilft, aber es ist nicht im Abgesicherten Modus entstanden.


VSoC = 1.26v
VDD = 1.47v
VDDQ = 1.42v
VDD IO = Auto
MISC = Auto

Brett Overvolted und wenn ich mir mit HWinfo die Sensoren ansehe teilweise deutlich.


Bin gerade dabei und drücke die Timings. Also vermutlich noch Potential vorhanden, aber das mache ich alles nach und nach.

 

[drival0605]

Guten Abend,

ich habe noch einmal ein bisschen rumgespielt und bin mit den Tipps von Veii zunächst einmal bei diesem Setup gelandet, auf das ich gerne aufbauen möchte:

TM5 1usmus_v3 lief bis Cycle 23/25 stabil durch (circa 3 Stunden und 20 Minuten, dann hat es sich aufgehangen!).

Spannungen:
VSoC = 1,23 V
VDDP = 1,15 V

VDD = 1,35 V
VDDIO = VDDQ = 1,27 V
VDD MISC = 1,1 V

beide VDDG = 1,15 V

Ich bin mir gerade echt unsicher, ob es sich überhaupt lohnt auf tCL 30 oder tCL 28 zu gehen. Für tCL 30 brauche ich 1,41 V und für tCL 28 benötige ich 1,48 V VDD. Ich glaube ich bleibe einfach bei 1,35 V und tCL 32 und hole mit den restlichen Timings raus, was geht. Ich würde schon gerne 6400 MT/s fahren. Die VsoC geht bestimmt auch noch einen Ticken tiefer. Was meint ihr?

Die durschnittliche Temperatur lag beim Testen übrigens bei 53 °C. Die 63,8 °C sind ein Auslesefehler. Ich habe derzeit keinen Lüfter vor dem RAM, habe das aber in der Vergangenheit so gehandhabt. Wenn ich mit der Spannung höher gehen würde, würde ich natürlich einen drüber positionieren.

Ansonsten habe ich ja 2x32 GiB Dual Rank Module (Das was bei ZenTimings unten steht mit "SR" muss ein Fehler sein): Wie stellt man da "tRDRDSD", "tRDRDDD", "tWRWRSD" und "tWRWRDD" am besten ein? Kann sonst noch was gestrafft werden ohne Spannungserhöhung?

tRFC auf 384 für 120 ns hat übrigens Fehler geworfen, obwohl ich A-Dies habe. 130 ns scheint bei 1,35 V der Sweetspot zu sein. tRAS = tRC ist bei mir die Summe aus tRCD, tCWL und tWR für Stabilität.

Zudem muss ich "ProcOdt", "ProcCaDs", "ProcDqDs" und "DramDqDs" sowie die Rtts noch ausloten. Gibt es da Anhaltspunkte für Dual Rank Module bei den von mir verwendeten Spannungen?

Ich würde mich freuen, wenn noch jemand was zu dem Setup beitragen kann oder was zu beanstanden hat.
Ich habe nämlich echt nicht so den Plan, bin neu bei AMD. ^^

 

[LuxSkywalker]

...
Ich bin mir gerade echt unsicher, ob es sich überhaupt lohnt auf tCL 30 oder tCL 28 zu gehen. Für tCL 30 brauche ich 1,41 V und für tCL 28 benötige ich 1,48 V VDD. Ich glaube ich bleibe einfach bei 1,35 V und tCL 32 und hole mit den restlichen Timings raus, was geht. Ich würde schon gerne 6400 MT/s fahren. Die VsoC geht bestimmt auch noch einen Ticken tiefer. Was meint ihr?

m.e. ist der Sprung von 1,35V CL32 zu 1,41V CL30 bzw. 1,48V CL28 zwar recht linear aber doch schon relativ hoch je Schritt

...
tRFC auf 384 für 120 ns hat übrigens Fehler geworfen, obwohl ich A-Dies habe. 130 ns scheint bei 1,35 V der Sweetspot zu sein. tRAS = tRC ist bei mir die Summe aus tRCD, tCWL und tWR für Stabilität.
...

ich habe 2x16GB A-Die - die gehen bis 120ns problemlos bei 1,35 VDD, drunter geht allerdings gar nix (bis 1,375V getestet) - bin jetzt Aufgrund der Liste von @RedF (und @Veii ) und der Empfehlungen darin bei tREFI 65528 und damit verbundenen tRFC bei 372 gelandet welches 124ns entspricht

 

[Damned92]

Guten Morgen,
ich bin gerade auf dieses Forum gestoßen und habe mich schon etwas durch die Beiträge gekämpft ohne direkt fündig zu werden.
Daher hier einmal eine kurze Frage:

Ich habe seit gestern folgende Komponenten verbauten:
AMD Ryzen 7800X3D
Gigabyte B650E AORUS MASTER (rev. 1.0) mit BIOS Update F8
CORSAIR VENGEANCE 32 GB (CMH32GX5M2X7200C34 ver.5.43.01) 7200 (34-44-44-96)

Laut der Herstellerwebsite von Gigabyte soll dieser RAM mit XMP unterstützt werden, jedoch bekomme ich ihn nur Manuell auf 6000 MHz.
Unter XMP bekomme ich beim Start die Meldung, dass das System nicht läuft.

B650E AORUS MASTER (rev. 1.0) Unterstützung | Mainboards - GIGABYTE Germany

Dauerhafte Qualität von GIGABYTE. GIGABYTE Ultra Durable™ Mainboards bringt eine einzigartige Mischung von Funktionen und Technologien, die absolute ultimat...

www.gigabyte.com

Muss hier manuell nachgeregelt werden oder ist es aussichtlos?


Vielen Dank im Voraus!

 

[LuxSkywalker]

@Damned92

7200 wird per XMP geladenem Profil nicht laufen

Stell auf 6000 und hole manuell alles an Timings und Spannungen raus

Alternativ wieder verkaufen und 6000er EXPO Ram kaufen

6000MT/s läuft idR immer plug&play
6400MT/s läuft bei einigen
6600MT/s läuft bei sehr wenigen
darüber (wenn überhaupt) immer nur mit manuell angepassten Timings/Spannungen

dann gibt es auch noch diese ominösen 8000MT/s Kits für AMD - welche aber nur läuffähig sind wenn der IMC mit halbiertem Takt läuft, dies kostet massiv Leistung/Latenz und ist m.e. total sinnfrei

 

[Damned92]

@LuxSkywalker

Vielen Dank für die Rückmeldung!
Sehr ärgerlich, ich hatte gehofft, dass auf die Angaben bei Gigabyte verlass sei....

 

[LuxSkywalker]

du musst da differenzieren: das Board macht diese Geschwindigkeit mit und ist damit auch geprüft worden.

Allerdings sind die IMC (Memory Controller) der aktuellen Ryzen 7xxx Generation da limitiert - default ist halt nur 5200MT/s von AMD vorgesehen (garantiert)

der Sweet Spot liegt bei 6000 - das läuft idR ohne große Aktionen, allerdings bedeutet dies auch schon OC!

...und es gibt durchaus auch viele User welchen sich bewusst schnelleren RAM kaufen um diesen dann mit weniger Spannung und wesentlich besseren Timings laufen zu lassen

bei miz z.B. G.Skill 6800CL34 läuft bei mir mit 6000CL28

 

[Damned92]

Gerade habe ich noch etwas folgendes gefunden:
Könnte es mit solchen bzw ähnlichen Einstellungen laufen?

 

[LuxSkywalker]

probier es aus...

allerdings wie du oben rechts siehst läuft da UCLK nicht synchron mit MCLK - der IMC läuft mit halber Geschwindigkeit

das bringt in der realen Welt abseits von ZenTimings Screenshots nur nachteile wie ich schon geschrieben habe

und btw. MEM VDD nur 1,2V bei dem Speed ist sehr unrealistisch - der RAM wird wesentlich mehr Spannung per overvoltage Switch im BIOS bekommen

 

[Veii]

das bringt in der realen Welt abseits von ZenTimings Screenshots nur nachteile wie ich schon geschrieben habe

So so , eher im gegenteil.
Wobei 6000 Gear 1 schwer zu schlagen ist. Einfach aufgrund des sauberen Dividers.

Wenn man keine 6400 Gear 1 hinbekommt, ist 7800 eine gute option.
CCLK, SOCClk, DCLK, PHYCLK sind alle loadbalanced.
UCLK, FCLK, MCLK sind leider fixed. Sie waren mal dynamisch und AVFS unterstützt es.
// AMD hasst es allerdings über dieses Thema zu reden, da es nun die 3. Generation ist worin sie weiterhin versagt haben :') .
// Bei den APU/GPUs klappts, bei den CPUs wird es jede generation versperrt 🤭. Schade, wo DDR5 doch so schön dynamisch laufen kann.

CoreCLK sowie Internal clock bleiben dynamisch, auch bei dem X3D
Ab 2100 FCLK ist die schwäche von dem X3D eher CoreClk & L3$ anstelle MCLK/UCLK
UCLK intern läuft auf 120-500GB/s. X3D ist weitaus schneller als der normale Ryzen.
Es stört ihn wenig wenn UCLK auf halfspeed läuft.

Nur eines wäre Text, das andere wäre daten.
Daten habe ich hier schon gepostet.
SiSoftSandra.
Umfasst fast all dataset größen, welche von XYZ Programm genutzt werden können.

Die Zugriffszeit von <20ns roundtrip, bzw <~9ns core to core,
Wird nicht zum "bottleneck" werden, da abseits renderpipeline design (clamchowder & chips'n'cheese post)
Es weit unter den limitationen liegt und als nahezu-monolithic keinerlei Probleme bereiten wird.

Beitrag automatisch zusammengeführt: 25.11.2023

Bei einem 7900X/7950X wäre der Jump zwischen CCDs zwar leicht langsamer, als der Jump zu mem
(~45ns vs ~50-55ns MEM)
Jedoch sprechen wir hier von einem Buffer von 32MB + 32MB L3$
Vs 96MB L3$

32MB füllen sich schnell, wenn die 96MB schon rausleaken.
// 64MB gibt es zwar als Shared-L3$, jedoch verteilt. Sprich selbstverständlich wird es Zugriff zum RAM bevorzugen. Obwohl dieser auf 1/4tel der BW läuft. Naja in dem non-3D Fall, half.
Bei dual CCDs macht es sinn sich auf FCLK sowie MCLK zu fokussieren um die Leakchance zu verringern. (weniger UCLK, da die Bandwidth/L3-MB, intern schon ausreicht)

Bei einem single CCD X3D, ist UCLK nicht das Problem.
Durch das Interleaving kommst du auf nahezu einem halben TB/s peak bandwidth intern.
// Mehrere gründe weswegen CCLK niedrig ist. SOCCLK ist doppelt so schnell bei X3D, schon seit AM4.
~3* so schnelle Inter-core/thread bandwidth, verglichen mit den non X3D Lösungen.
Da macht es kaum einen Unterschied ob es nun 500GB/s oder 300GB/s wären. Oder sogar 200GB/s
Es ist schnell genug und habe einen großen L3$-Pool.

Das Hauptproblem wäre eher CCLK, da L3 etwas zu langsam ist und doch rüberleakt zu mem.
Obwohl es das garnicht erst müsste.
Jedenfalls wäre UCLK nicht das Problemkind von dem X3D. V$ Bandwidth ist mehr als genug da. 🤭

Beitrag automatisch zusammengeführt: 25.11.2023

Ansonsten habe ich ja 2x32 GiB Dual Rank Module (Das was bei ZenTimings unten steht mit "SR" muss ein Fehler sein):

UDIMM können nie Dual Rank sein.
Sie sind dual sided.

Solange du Pro Seite nicht 2 reihen von ICs hast, welches erlaubt dass diese gleichzeit Arbeiten,
Wird es nie dual RANK sein, da es nur single rank pro side, pro subchannel wäre. Single row im roundtrip zugriff.
Ebenso nicht im symmetrischen Zugriff. Sowas kann nur RDIMM.
Da UDIMM keine "two commands per strobe" kann - wäre es somit kein echtes Dual Rank. Es ist komplett anders zu DDR4
UDIMM wäre dual channel pro slot. Aber weiterhin kein Dual Rank.

Beitrag automatisch zusammengeführt: 25.11.2023

und btw. MEM VDD nur 1,2V bei dem Speed ist sehr unrealistisch - der RAM wird wesentlich mehr Spannung per overvoltage Switch im BIOS bekommen

OC Mode.
Richtek 1200mV (0100 0110, 46h) im 5mV stepping - wären 1600mV im OC mode.
Sollte ich diesmal das Grundschule 1+1 beherrschen können .
Zentimings hat keinen PMIC Zugriff bzw keinen EC Zugriff um OC mode auslesen zu können.

 

[drival0605]

Ich habe auch noch einmal eine Frage:

Woher weiß ich, ob ich 1 KB oder 2 KB pagesize DIMMs habe (für tFAW 32 oder 48)?

 

[Veii]

Ich habe auch noch einmal eine Frage:

Woher weiß ich, ob ich 1 KB oder 2 KB pagesize DIMMs habe (für tFAW 32 oder 48)?

DIMM-Stick Specs.
Ich weiß es nicht.

Soweit alle auf dem Markt müssten 1KB sein.

Beitrag automatisch zusammengeführt: 25.11.2023

@RedF wenn dir langweilig wird:

Es macht wenig Sinn timing parameter auszurechnen, wenn das Rounding fehlerhaft ist.

Du kannst dich weiterhin bei meinem tRFC mini sheet bedienen
Ich muss die Formel noch richten, aber im grundegenommen hab ich das Rounding halbwegs korrekt.

 

[LuxSkywalker]

So so , eher im gegenteil.
...

ICH habe noch keine Screenshots oder Benchmarks gesehen die das bei AM5 entsprechend belegen

selbst die ganzen 8000MT/s kommen mit 1:2 nur schwer bis gar nicht an die Latenz dran welche mit 6000 1:1:1 möglich sind

Bandbreite bringt das ganze, das stelle ich gar nicht in Abrede

 

[Veii]

ICH habe noch keine Screenshots oder Benchmarks gesehen die das bei AM5 entsprechend belegen

Ich merke dass man auf LUXX die ehemaligen Beiträge nicht ließt.
Den die Fragen wiederholen sich

[Sammelthread] - Ryzen DDR5 RAM OC Thread

Brauchst du nicht. VDDIO/MC = VDD_CPU Je niedriger desto besser. (meistens) VDDQ_CPU auf AMD wird automatisch durch VDDQ Training reintrainiert. Als verstecktes offset. VDDIO & procDQ - haben eine direkte Verbindung VDDCR_SOC & procODT haben eine direkte Verbindung VDDG & procODT haben eine...

www.hardwareluxx.de

[Sammelthread] - Ryzen DDR5 RAM OC Thread

Brauchst du nicht. VDDIO/MC = VDD_CPU Je niedriger desto besser. (meistens) VDDQ_CPU auf AMD wird automatisch durch VDDQ Training reintrainiert. Als verstecktes offset. VDDIO & procDQ - haben eine direkte Verbindung VDDCR_SOC & procODT haben eine direkte Verbindung VDDG & procODT haben eine...

www.hardwareluxx.de

Das gilt für mehrere Leute , nicht nur dich.
Soweit 5 Vorfälle hier, und mehrere Vorfälle in dem Intel Thread.

Aber leider existiert in dem Forum diese Option nicht
Somit nichts für ungut

Für mich wird es nur manchmal anstrengend sich zu wiederholen, wo keine Eigeninitiative besteht.
Wie gesagt nichts für ungut, bloß wäre es einer der Gründe wieso man manchmal schneller oder langsamer eine Antwort bekommt.
Oder garnicht und der Person Zeit gibt selbst nach der Information zu suchen.

Ich ignoriere keinem absichtlich
Nun ja, wie man's nimmt.

Beitrag automatisch zusammengeführt: 25.11.2023

Damit hätten wir direkt aufgelöst, ob es wirklich hilft oder Zeitverschwendung ist.

Was bedeuten unsere Benchmarks und wie sollten wir wirklich testen:

[Sammelthread] - Intel DDR5 RAM OC Thread

Oki ganz einfach holzi die Sache aus dem Weg zu räumen. Wir hätten gerne einen 4036% karhu Run von dir mit allen Infos auf dem Screen Oki? Mit welchem Takt den jetzt?

www.hardwareluxx.de

Sowie die nächsten 2-3 Beiträge.

Womöglich erklärt es diese "Zeitverschwendung"

 

[LuxSkywalker]

Ich merke dass man auf LUXX die ehemaligen Beiträge nicht ließt.
Den die Fragen wiederholen sich

[Sammelthread] - Ryzen DDR5 RAM OC Thread

Brauchst du nicht. VDDIO/MC = VDD_CPU Je niedriger desto besser. (meistens) VDDQ_CPU auf AMD wird automatisch durch VDDQ Training reintrainiert. Als verstecktes offset. VDDIO & procDQ - haben eine direkte Verbindung VDDCR_SOC & procODT haben eine direkte Verbindung VDDG & procODT haben eine...

www.hardwareluxx.de

[Sammelthread] - Ryzen DDR5 RAM OC Thread

Brauchst du nicht. VDDIO/MC = VDD_CPU Je niedriger desto besser. (meistens) VDDQ_CPU auf AMD wird automatisch durch VDDQ Training reintrainiert. Als verstecktes offset. VDDIO & procDQ - haben eine direkte Verbindung VDDCR_SOC & procODT haben eine direkte Verbindung VDDG & procODT haben eine...

www.hardwareluxx.de

Das gilt für mehrere Leute , nicht nur dich.
Soweit 5 Vorfälle hier, und mehrere Vorfälle in dem Intel Thread.

Aber leider existiert in dem Forum diese Option nicht
Somit nichts für ungut
Anhang anzeigen 942699
Für mich wird es nur manchmal anstrengend sich zu wiederholen, wo keine Eigeninitiative besteht.
Wie gesagt nichts für ungut, bloß wäre es einer der Gründe wieso man manchmal schneller oder langsamer eine Antwort bekommt.
Oder garnicht und der Person Zeit gibt selbst nach der Information zu suchen.

Ich ignoriere keinem absichtlich
Nun ja, wie man's nimmt.

Beitrag automatisch zusammengeführt: 25.11.2023

Was bedeuten unsere Benchmarks und wie sollten wir wirklich testen:

[Sammelthread] - Intel DDR5 RAM OC Thread

Oki ganz einfach holzi die Sache aus dem Weg zu räumen. Wir hätten gerne einen 4036% karhu Run von dir mit allen Infos auf dem Screen Oki? Mit welchem Takt den jetzt?

www.hardwareluxx.de

Sowie die nächsten 2-3 Beiträge.

Womöglich erklärt es diese "Zeitverschwendung"

ich habe keinen Plan was du mir hier andichten willst...

wenn du selber mal im Forum liest würdest du merken das ICH sehr wohl eigene Recherche betreibe ^^ ich stelle eher keine Fragen sondern suche idR eher selber im WWW und probiere aus

wenn du allerdings ein Problem mit anderen Sichtweisen/Standpunkten hast ist das nicht zu ändern

 

[Veii]

Der Sandra Bench "Inter Thread Latency test" spuckt sowohl mit meinen vorherigen Timingeintragungen, als auch mit deinen Tips die nahezu gleiche Kurve/Durchsatz aus.
Wo da wann was "leakt" kann ich leider nicht sagen.

Bei dem ersten Start, testet das Programm deine CPU und berreitet sie für die Rangliste vor
Danach musst du auf dem

Butten drücken, und abwarten.
Damit bekommst du ein kompletten test mit sehr vielen daten (kann man als TXT exportieren)

Danach machst du das selbe mit anderen Timings, und wählst beide Ergebnisse aus
Letztendlich vergleicht man beide Kurven und ebenso die Zugriffszeit bzw die Median delta.
Effektiv zeigt es dir ob deine Arbeit irgendwas für die CPU auswirkt, oder du nur synthetische Ergebnisse rausbekommst, worin die Arch zu langsam wäre diesen Overclock auszunützen.

Würde cache nicht rausleaken, würdest du keinerlei Unterschied sehen.

Beitrag automatisch zusammengeführt: 25.11.2023

ich habe keinen Plan was du mir hier andichten willst...

wenn du selber mal im Forum liest würdest du merken das ICH sehr wohl eigene Recherche betreibe ^^ ich stelle eher keine Fragen sondern suche idR eher selber im WWW und probiere aus

wenn du allerdings ein Problem mit anderen Sichtweisen/Standpunkten hast ist das nicht zu ändern

?

EDIT:
Rip Beitrag, refresh killed it
Naja gut

Bitte schaue dir den post welchen du geliked hast, nochmal an
Und das beste was ich machen kann, wäre dich um deine Recherche-daten zu bitten.