Stehe auch vor dem Thema..
Ich find die hier gut, jetzt mal rein von der Optik her:
Hab aber noch nicht weiter geschaut, wo man die bekommt, aber die werden es wahrscheinlich werden..
[Sammelthread] Intel DDR5 RAM OC Thread
- Ersteller even.de
- Erstellt am
Ich find die hier gut, jetzt mal rein von der Optik her:
Hab aber noch nicht weiter geschaut, wo man die bekommt, aber die werden es wahrscheinlich werden..
Felix the Cat
Der mit SeLecT tanzt
Die 7000er von Corsair sehen ganz interessant aus. Aber nach dem Luxx Test würde ich aktuell auch nicht so viel erwarten.
Edit:
@TomCom205
Du kommst doch eh nicht zum Testen.
Edit:
@TomCom205
Du kommst doch eh nicht zum Testen.
Deathrow2004
Urgestein
Sind bei mir bei 50000 exakt 7ns.
Mich würde aber anstatt der Latenz eher ein stabiler Betrieb bei 7200MT reizen, sollte doch eigentlich machbar sein. Werde da wohl die Tage viel ausprobieren müssen wenn ich die Zeit finde.
xST4R
Enthusiast
- Mitglied seit
- 22.10.2017
- Beiträge
- 3.641
ja fand ich auch aber bekommste in eu nirgendsStehe auch vor dem Thema..
Ich find die hier gut, jetzt mal rein von der Optik her:
Hab aber noch nicht weiter geschaut, wo man die bekommt, aber die werden es wahrscheinlich werden..
Beim Refreshintervall muss man natürlich was machen, da die JEDEC Werte so unheimlich defensiv sind. Man muss aber auch bedenken, dass Fehler wg. zu langen Intervallen echt unschön das OS zerlegen können auf Dauer. Und leider sind sie schwer zu ertesten. Ich lasse daher viel Luft, 65536 setze ich nur, wenn auch bei >90000 in Karhu keine Fehler kommen. Das schöne ist, vom Default-Wert hoch auf 32K bringt schon 90% benefit. Dann noch mal verdoppeln oder verdreifen bringt kaum noch was, da man das refresh-Penalty zusammen mit scharfen tRFC schon nahezu eliminiert hat.
Jop, ihr lasst mir leider keine Wahl
. 
gibt auch ein 20 Minuten Buildzoid Video welches sich diesem Thema widmet.
Einzig positiver Aspekt ist das die Refreshcycles wahrscheinlich nur den DIMMs selber "schaden" und der IMC davon eher weniger betroffen ist, ließt man aber schockierend oft das die Leute den auf Maximum haben und sich dann wundern warum nichts stabil läuft.
Würde die Riegel auch eher ausschließen bei dir da müsste deutlich mehr gehen eigentlich, hab mit meinen 6400 gebinnten auch einen soliden 7200MT in der Pipeline mit straffen Timings und Spannungen die ich als unbedenklich erachte, nur noch nicht die Zeit gehabt den 3 Stunden durch Testmem5 zu drücken sonst wird man hier gesteinigt.
Ich will auch keine Werbung machen und bin heterosexuell, aber auch zu in etwa deiner Kombo hat der Buildzoid ebenfalls ein Video gemacht, das müsste dich schon deutlich weiter bringen auch wenn ich die T1 Command Rate erstmal lassen würde ->
.
gibt auch ein 20 Minuten Buildzoid Video welches sich diesem Thema widmet.Einzig positiver Aspekt ist das die Refreshcycles wahrscheinlich nur den DIMMs selber "schaden" und der IMC davon eher weniger betroffen ist, ließt man aber schockierend oft das die Leute den auf Maximum haben und sich dann wundern warum nichts stabil läuft.
Würde die Riegel auch eher ausschließen bei dir da müsste deutlich mehr gehen eigentlich, hab mit meinen 6400 gebinnten auch einen soliden 7200MT in der Pipeline mit straffen Timings und Spannungen die ich als unbedenklich erachte, nur noch nicht die Zeit gehabt den 3 Stunden durch Testmem5 zu drücken sonst wird man hier gesteinigt
.Ich will auch keine Werbung machen und bin heterosexuell, aber auch zu in etwa deiner Kombo hat der Buildzoid ebenfalls ein Video gemacht, das müsste dich schon deutlich weiter bringen auch wenn ich die T1 Command Rate erstmal lassen würde ->
Um 7200 auf dem Board richtig stable zu bekommen (y-cruncher vst) ist meiner Erfahrung nach schon einiges an Fummellei nötig.
Hab das besagte Board und ein 6400 Gskill A-Die Kit. Wenn du Hilfe brauchst, ich kanns versuchen
Hynix M-Die vs A-Die.
Hab bei dem Board mit M-Die 6800 nicht stabil bekommen, allerdings auch nur sehr kurz getestet.
boesew1cht
Profi
Mit dem F4d BIOS bekomm ich 7200 nicht mehr stable, auf F3 gingen 7400.Nö, bin zu lazy dafür.
Teste auch grad, ob CL 32 stabil laufen.
Finde es trotzdem komisch, dass mehr als 6600 bei dir nicht gehen.
Wir haben ja das gleiche Board, da müssten wir doch was machen können.
Anhang anzeigen 863592
Gut, dann haben wir keine Schuld
Hattest du nach dem Update Probleme oder machts bei dir keinen Unterschied?
Mehr Spannung hat mich auch nicht weitergebracht, werde später wieder auf F3 zurück gehen müssen.
Ich hab zu dem Zeitpunkt eh soviel am System geändert...
Definiere stabil, also richtig Y-Cruncher VST stable?
Mit F4d sind 7200 kein Problem, mehr hab ich noch nicht getestet und hab ich auch mit anderen Bios Versionen eher nicht stabil bekommen.
Karhu, TM5 etc. sind kein Problem, aber VST...
Welche Spannungen hast du denn aktuell?
Kann dir da aber denke ich helfen, weil ich auch ein paar Spannungen ändern musste.
Hab es aber erst nicht aufs Bios geschoben und muss auch nicht daran liegen.
xST4R
Enthusiast
- Mitglied seit
- 22.10.2017
- Beiträge
- 3.641
jop verstehe ich auch nicht wieso die leute trefi immer auf das absolute maximum machen - hab das video auch gesehen und mach nun nurnoch soviel wie der ram auch wirklich will - in meinem fall sind es 87040
boesew1cht
Profi
Mit stable meine ich Games table und 5000% karhu.
Mit F4D kann ich nicht mal booten bei gleichen Spannungen. Nur bis 7000.
Spannungen: SA 1.25V, vdd 1.42 vddq 1.41, Mc 1.42v vddqtx 1.4 v
Probiere mal weniger vddqtx... Bei 7200 bin ich mit ca. 1,2 Volt am stabilsten.
boesew1cht
Profi
Werde ich nach Feierabend probieren und berichten, danke dir.
mattxx88
Enthusiast
anyone here planning to test new 24gb modules?
porter111
Enthusiast
Habe mich mal an meinem daily Ram setting versucht, fand DDR4 bdie nicht so zickig wie DDR5 adie aber durch die vielen Ergebnisse hier im Forum und auf YT habe ich mir was zusammengebastelt, irgendwelche Verbesserungsvorschlaege?
xST4R
Enthusiast
- Mitglied seit
- 22.10.2017
- Beiträge
- 3.641
geht trfc2 nicht niedriger ? - und mach mal 10k karhu , der spuckt ab ~5700-6400 oft noch mal nen error das ist wie dieses 400% error ding xD
Kleiner Erfahrungsbericht von mir, da ich in den letzten Tagen Gelegenheit zum Test einiger A-Die Kits hatte. Mein ursprüngliches 6600er Trident-Z RGB Kit ging ganz gut, 7800 aufm Z790-F Strix benchbar, 7600 im Alltag nutzbar, 7466 wirklich fehlerfrei zu bekommen. Das Kit erreichte in Karhu und ohne spezielle Kühlungsmaßnahmen ca. 60 Grad, RGB aus brachte auch kaum was. Für mich kein Problem aber tREFI über 32k ging so nicht.
Kit Nr. 2 ist ein Kingston Fury Renegade 6400, auch mit A-Die. Hab die vorherigen Profile damit nicht fehlerfrei bekommen. Selbst 7466 haut in Karhu innerhalb der ersten 10 Min Erros raus. Temperatur exakt wie die G.Skills - also so elend sind die Heatspreader der G.Skill im Vergleich nicht.
Kit Nr. 3 und 4 sind jeweils 6400er G.Skill Trindent Z RGB, sogar etwas frühere Seriennummern als die 6600er. Es handelt sich nicht um Frischware. Sie gehen gut! Das schlechtere (jüngere!) von Beiden auf Niveau der 6600er und das älteste Kit sogar noch etwas besser. Konnte meine VDD(Q) um 20mV senken und tREFI 100k oder knapp drüber lief bei 60 Grad tatsächliche ne Stunde ohne Fehler, d.h. 65k sind möglich.
Wg. der erheblichen Streuung bei tREFI wollte ich das mit euch teilen. Was zählt ist der "undichteste" Kondensator in einem der 16 Chips auf den 2 Modulen. Pure Glückssache ein Kit zu erwischen, dass nicht eine schwache Zelle hat. Also fein testen bevor man stumpf Werte aus dem Forum übernimmt und sich dann über sporadische Testfehler oder CRC-Errors im Betriebssystem ärgert.
Kit Nr. 2 ist ein Kingston Fury Renegade 6400, auch mit A-Die. Hab die vorherigen Profile damit nicht fehlerfrei bekommen. Selbst 7466 haut in Karhu innerhalb der ersten 10 Min Erros raus. Temperatur exakt wie die G.Skills - also so elend sind die Heatspreader der G.Skill im Vergleich nicht.
Kit Nr. 3 und 4 sind jeweils 6400er G.Skill Trindent Z RGB, sogar etwas frühere Seriennummern als die 6600er. Es handelt sich nicht um Frischware. Sie gehen gut! Das schlechtere (jüngere!) von Beiden auf Niveau der 6600er und das älteste Kit sogar noch etwas besser. Konnte meine VDD(Q) um 20mV senken und tREFI 100k oder knapp drüber lief bei 60 Grad tatsächliche ne Stunde ohne Fehler, d.h. 65k sind möglich.
Wg. der erheblichen Streuung bei tREFI wollte ich das mit euch teilen. Was zählt ist der "undichteste" Kondensator in einem der 16 Chips auf den 2 Modulen. Pure Glückssache ein Kit zu erwischen, dass nicht eine schwache Zelle hat. Also fein testen bevor man stumpf Werte aus dem Forum übernimmt und sich dann über sporadische Testfehler oder CRC-Errors im Betriebssystem ärgert.
Deathrow2004
Urgestein
Was sind denn eurer Erfahrung nach sichere Settings für tREFI? Die Herstellervorgaben sind ja wirklich sehr konservativ gesetzt.
Ja, nach meiner Erfahrung kann man ohne Bedenken Richtung 32k gehen, hab jedenfalls noch keinen IC erlebt der das nicht konnte. B-Dies waren so extrem tolerant, da konnte man sogar 65k bei Taktraten ab 3200 Mhz empfehlen.
Man muss einfach beachten, dass tREFI ganz anders reagiert als alle anderen Timings. Die anderen Timings definieren ja Restriktionen beim Adressieren (Haupttimings) bzw. Verschachteln (Subtimings) von Zugriffen. Genau auf diese Zugriffe prügeln Stabilitätstests ein und fördern Fehler schnell zu Tage. Dazu kommt, dass ein Timing wie tCL bei jedem Read (also extrem oft) zum Tragen kommt und immer auf einen kleinen Bereich des Speicherchips (die ROW-Buffer/Sense Amps) wirkt. Daher werden diese Timings in kurzer Zeit sehr intensiv getestet. tRFC beschreibt die Dauer eines Refresh-Intervalls und ist auch recht einfach zu testen, da - wenn zu kurz - der refresh vorzeitig abgebrochen wird und Fehler schnell auftreten.
tREFI beschreibt die Zeit zwischen mehreren Refreshs, ist überhaupt nicht lastabhängig und kaum gezielt testbar. Grob gesagt hängt die maximalmögliche Zeit zwischen den Refreshs davon ab, wie schnell die Speicherzellen - von denen es verdammt viele gibt - ihren Inhalt verlieren. Wie schnell das geschieht hängt vom Fertigungsprozess ab (IC-Typ), von der individuellen Qualität des ICs (bzw. dessen schwächster Zelle!) und vor allem von der Temperatur. Der Gedächtnisverlust ist absolut nicht Lastabhängig sondern eine statistische Funktion aus Temperatur und Zeit. Deshalb braucht auch der Test Zeit und vorallem Temperatur. Zu DDR4 Zeiten konnte ich bei Micron 8 Gbit ICs mit tREFI 65536 über Nacht 1-2 Fehler erzeugen, während 45.000 fehlerfrei lief. Interessehalber merhfach getestet mit konsistentem Ergebnis. Kurzfristig schien 65k fehlerfrei... war es aber nicht. Das fiese ist jetzt, dass so ein Fehler nicht zu einem Lockup führt wie tCL sondern nach und nach das Dateisystem korrumpieren kann, wenn falsche Daten auf die SSD zurück geschrieben werden und CRC nicht greift. Daher geht man mit tREFI nicht unnötigerweise an die Grenze und auch genau deshalb setzen die SPDs und XMPs dieser Welt so konservative Werte.
Man muss einfach beachten, dass tREFI ganz anders reagiert als alle anderen Timings. Die anderen Timings definieren ja Restriktionen beim Adressieren (Haupttimings) bzw. Verschachteln (Subtimings) von Zugriffen. Genau auf diese Zugriffe prügeln Stabilitätstests ein und fördern Fehler schnell zu Tage. Dazu kommt, dass ein Timing wie tCL bei jedem Read (also extrem oft) zum Tragen kommt und immer auf einen kleinen Bereich des Speicherchips (die ROW-Buffer/Sense Amps) wirkt. Daher werden diese Timings in kurzer Zeit sehr intensiv getestet. tRFC beschreibt die Dauer eines Refresh-Intervalls und ist auch recht einfach zu testen, da - wenn zu kurz - der refresh vorzeitig abgebrochen wird und Fehler schnell auftreten.
tREFI beschreibt die Zeit zwischen mehreren Refreshs, ist überhaupt nicht lastabhängig und kaum gezielt testbar. Grob gesagt hängt die maximalmögliche Zeit zwischen den Refreshs davon ab, wie schnell die Speicherzellen - von denen es verdammt viele gibt - ihren Inhalt verlieren. Wie schnell das geschieht hängt vom Fertigungsprozess ab (IC-Typ), von der individuellen Qualität des ICs (bzw. dessen schwächster Zelle!) und vor allem von der Temperatur. Der Gedächtnisverlust ist absolut nicht Lastabhängig sondern eine statistische Funktion aus Temperatur und Zeit. Deshalb braucht auch der Test Zeit und vorallem Temperatur. Zu DDR4 Zeiten konnte ich bei Micron 8 Gbit ICs mit tREFI 65536 über Nacht 1-2 Fehler erzeugen, während 45.000 fehlerfrei lief. Interessehalber merhfach getestet mit konsistentem Ergebnis. Kurzfristig schien 65k fehlerfrei... war es aber nicht. Das fiese ist jetzt, dass so ein Fehler nicht zu einem Lockup führt wie tCL sondern nach und nach das Dateisystem korrumpieren kann, wenn falsche Daten auf die SSD zurück geschrieben werden und CRC nicht greift. Daher geht man mit tREFI nicht unnötigerweise an die Grenze und auch genau deshalb setzen die SPDs und XMPs dieser Welt so konservative Werte.
Ich würde einfach ne Schnappszahl reinmachen, die bringen Glück.
Ich hab die 7200 nochmal durch den Memtest gedonnert. Das bleibt jetzt auch so erstmal im Alltag und gehe aus Jucks dann direkt auf 7600 Kurs mit leicht erhöhten Spannungen. Zimmertemperatur etwa 24°C, Gehäuse zu etc.pp..
Leider macht mir das ASRock BIOS noch ein paar Probleme bzw. hat noch Eigenarten bei bestimmten Werten und Sensorik wo mir das Verständnis fehlt. Der twR Wert welcher ja eigentlich nicht existiert sollte tatsächlich eingetragen werden weil keine tRWPRE vorhanden ist im BIOS. Ich geh stark davon aus dieser ähnlich wie die tRC dann per Formel weitergegeben wird.
PS: Frage noch an die Window 11 Nutzer, macht es wirklich Sinn zu wechseln von 10 ? Ich hab zwar 240hz im IDLE und Windows 10 stark debloatet, dennoch deutlich bessere Latenzen im savemode, das stört mich etwas.
Ich hab die 7200 nochmal durch den Memtest gedonnert. Das bleibt jetzt auch so erstmal im Alltag und gehe aus Jucks dann direkt auf 7600 Kurs mit leicht erhöhten Spannungen. Zimmertemperatur etwa 24°C, Gehäuse zu etc.pp..
Leider macht mir das ASRock BIOS noch ein paar Probleme bzw. hat noch Eigenarten bei bestimmten Werten und Sensorik wo mir das Verständnis fehlt. Der twR Wert welcher ja eigentlich nicht existiert sollte tatsächlich eingetragen werden weil keine tRWPRE vorhanden ist im BIOS. Ich geh stark davon aus dieser ähnlich wie die tRC dann per Formel weitergegeben wird.
PS: Frage noch an die Window 11 Nutzer, macht es wirklich Sinn zu wechseln von 10 ? Ich hab zwar 240hz im IDLE und Windows 10 stark debloatet, dennoch deutlich bessere Latenzen im savemode, das stört mich etwas.
G
Gelöschtes Mitglied 337316
Guest
Ich hab mal etwas Rumgespielt :
Ist doch für nen kleine I3 und samsung IC garnicht mal so unübel oder ?
Ist doch für nen kleine I3 und samsung IC garnicht mal so unübel oder ?
Double Impact
Experte
tRTP kriegst ned runter auf 12 oder so?
the_patchelor
Legende
Aida Werte sind bei BLCK nix Wert, leider.
Das schon echt saftig ne..
