Mit welchem Takt den jetzt?
[Sammelthread] Intel DDR5 RAM OC Thread
- Ersteller even.de
- Erstellt am
Mit welchem Takt den jetzt?
Eine Lüge nach der anderen
Beitrag automatisch zusammengeführt:
😁
Brainscan1979
Urgestein
Jo wer sich ne 3500€ Graka kaufen kann, kann sich nen Adobe jobber einstellen.
Stimmt schon du hattes mir mal ein 8000er CMO gesandt damit hatte ich aber nicht viel probiert bisher ...
Brainscan1979
Urgestein
Oder die Politiker 😁😁😁Besser wie die Lügen Werbung im TV hier
Der Scholz könnte Holzi sein 😂
Brainscan1979
Urgestein
Da wir ja nicht wissen wer holzi ist, ist es vielleicht der Scholz? Und das würde auch erklären wieso er so Hardware Geld hat. Wird alles von Papa Staat bezahlt 😂😂😂
Beitrag automatisch zusammengeführt:
Ja den 8600 bitte
Mir war seit 02.05.2017 bereits klar das wir es mit einem Psychopathen zu tun haben. Ich hatte mehrmals auf sein AMD Trolltum etc., semi-passive Agressivität usw. seinerzeit hingewiesen, es erkannte aber niemand so wie ich und ich erhielt teils sogar noch Gegenwind.
Ich wäre dafür "The Saint" auszutauschen mit "Cheater". Wäre ich Mod hier, wäre er spätestens seit Ende 2017 permabanned.
Ich wäre dafür "The Saint" auszutauschen mit "Cheater". Wäre ich Mod hier, wäre er spätestens seit Ende 2017 permabanned.
Brainscan1979
Urgestein
Ich sagte ja eben schon ab heute sind die 40k+ posts auch nicht mehr wert.
Wer sagt uns das er die Hardware überhaupt besitzt?
Brainscan1979
Urgestein
Jo, wo du es jetzt sagst. Bääääm alles ist gefälscht bei ihm. Jetzt macht das alles einen SinnWer sagt uns das er die Hardware überhaupt besitzt?
Ohne Witz jetzt, dass hat er schon oft bei seinem Benchmarksthreads gemacht, also von anderen seiten usw. geklaut.
Bei Holzi würde mich wie gesagt nichts mehr Schocken.
Felix the Cat
Der mit SeLecT tanzt
Nun lasst doch einfach mal gut sein.
Soll er einfach den 8600Mhz Screen nachliefern und wenn nicht, dann ist es auch so. Ist ja keiner abhängig hier von seinen Ergebnissen.
Setzt ihn sonst doch einfach auf die Ignore-Liste, wenn ihr die Screens nicht sehen wollt. Denke die Botschaft ist jetzt bei ihm in diesem Thread angekommen.
Ohne zu bewerten was echt ist oder nicht - wenn es jemand für sein Ego braucht...
Soll er einfach den 8600Mhz Screen nachliefern und wenn nicht, dann ist es auch so. Ist ja keiner abhängig hier von seinen Ergebnissen.
Setzt ihn sonst doch einfach auf die Ignore-Liste, wenn ihr die Screens nicht sehen wollt. Denke die Botschaft ist jetzt bei ihm in diesem Thread angekommen.
Ohne zu bewerten was echt ist oder nicht - wenn es jemand für sein Ego braucht...
danke dir, die werd ich versuchen wenns mit CL38 nix wird. Würde aber erst mal bei CL38 bleiben und das versuchen zu optimieren. Aktuell läuft 38 60 60 134. Rot markiert ist auf ,,Board auto,,. Welche werte könnte ich da nehmen zum verbessern?
CKE 4 ist kein validez Timing. Zu niedrig. >5ns
tWR 6 ist kein valides timing. Zu niedrig
12 minimum für single side, 24 minimum für dual-side. In schritten von 6.
tRTP 11 ist kein valides Timing für den Controller. Zu niedrig.12minimum.
(12,13,15,16,18 ~ es gibt binary steps)
@bmq34 gehe 5 seiten zurück
5-6.
Beantwortet alle Fragen. tRFC(pb) in steps auf 32.
RAS unter RCD+X ist sinnlos. RTP+RCD (+tBurst) = mininum
RP unter RCD ist sinnlos. Bettelt nach problemen.
Beitrag automatisch zusammengeführt:
RAS zu RAS zu RAS
In jeweils andere Bankgroups, wird nicht von RTP oder RP geregelt.
Ebenso verändert niedriegen RAS nicht die Grudlegenden maximalen Read commands.
In beiden fällen macht ein RAS drop keinen Sinn.
// RAS ist ein dynamisches Timing. Der OCer setzt nur ein minimum start-wert.
Dies regelt RRD_X (maximale read anzahl bis X)
Mit seinen minimum Limitierungen. Controller und PCB limitierungen.
Ein langer RRD_ delay ebenso kontroliert nicht den Delay von dem gesammten Read.
Er ist dafür da die jeweils andere Bankgroup in Roundrobin Order, berreit zu bekommen damit der Jump auf dieser geschehen kann.
Sprich minimum delays spielen eine Rolle.
Die minimum delays sind pro command-strobe-(up)
Dieser command strobe (tBURST) ist 8 tCK (clock).
In manchen Fällen dank Intels design wären das auch 4+4. Dennoch Gesammtwert 8 oder roundtrip (RBL & WBL = 16) keine 8 wie bei DDR4.
Nochmals für beide Fälle,
Es gibt minimum delays und überlappungsmöglichkeiten
Es gibt on-die ECC auf der CPU und memory controller seite.
Das ist kein DDR3 um read pro read zu denken.
Sehr viele Aktionen geschehen gleichzeitig.
Was der OCer ändert sind transition-delays.
Kein Timing gehe alleine und minimums sind minimums aus gutem Grund. Meistens HW seitig.
Zuletzt bearbeitet:
Und warum bringen die Timings in eigentlich allen benchmarks bessere Zeiten wenn sie doch eh nicht gehen und aufgrund dessen nach oben korrigiert werden.
Es mag alles stimmen was du sagst, aber wer sagt denn das nicht einige Controller die Werte verarbeiten können und wo sind Ergebnisse? Mich würde echt mal interessieren wie ein von dir stabiles setting läuft. Also in Summe müsste da locker mehr an takt gehen wenn man all diese Regeln befolgt und es müsste sogar schneller sein. No offense, reines Interesse.
Cke habe ich überdies nicht erwähnt 😅.
Multiquote.
Hat holzi falsch, hauptgrund warscheinlich Buildzoid's cheatsheet.
Ich nehme mir die Zeit damit es richtig ist und die Industrie weiterbringt.
Nicht um Leuten einzeln gratis zu helfen.
@misterh bitte schreibe hier, nicht in PMs.
Ich sehe bei dir:
Weil benchmarks single usecase szenarien sind
Sie sind dafür optimiert ein kleinen Teil der BufferQueue (CPU) zu belasten bzw zu füllen.
Davon gibt es sehr viele leider.
Aida ist ein READ-NOP-READ * cores , test
// NOP = no operation
Dann ein single Write-nop-write-nop
Und ein Kern zu Kern latenz test auf niedriger datasize. Eine welche in den L1D cache passt. Bzw kleiner.
Karhu ist ein kombinierter L3$ test, aber ich bin kein Programmierer um dir zu sagen wo seine fehler sind.
Außer dass es aufgrund der CPU kerne und Ring ebenfalls errorn kann und 5-9* länger als Tm5 braucht um die selben von mir erstellten fehler zu finden.
Sprich für ddr5 setzte ich da 20 000% stabilität bzw 1000% auf HCI. 10 000% für DDR4 klangen gut aber aufgrund der Erkenntniss durch meinen Tests, muss es zumindest 20 000% sein.
PyPrime ist ein read-nop-read test wie aida's read test. Jedoch fokusierter. Unrealistisch als perf test, aber brauchbar als richtwert für überlappende timings.
7zip ist ein write test. Realistischer zu einer random last wie spiele. Aber hängt wiederum auch von der CPU ab. (Bit)Buswidth, und bufferqueue size.
SuperPi ist nur ein single core , single bank test
Seine datengröße passt auf einem halben IC bzw 4 banks davon.
Unlogisch damit RRD_ zu testen. Im schlimmsten Fall sind es 3 bis 4 reads max. Weitaus weniger als pro roundtrip möglich sind, dank IC und besonders Bankgroups pro IC ~ anzahl.
Es greift garnicht die anderen ICs an.
Und so weiter
Der Post wird schon zu lange.
Im grundegenommen, fokusiert man sich zu sehr auf single small-datasize tests
Und merkt nicht mal dass diese im besten fall korrigiert, im schlimmsten fall verlangsamt(halting)+korrigiert werden.
ICs sind dumm. Sie versuchen das was du ihnen sagst.
Der controller aber nicht.
Beitrag automatisch zusammengeführt:
Das soll kein Angriff an OC/XOCer sein.
Aber im Grundgenommen verstehen wenige was die verwendeten Tools überhaupt testen oder derren schwächen.
Nur ob sie schneller oder langsamer sind.
Bitte lass uns darüber nicht reden.
Es ist schwierig nicht angreifend verstanden zu werden.
Das ist nicht meine Intention. So bin ich nicht
Zuletzt bearbeitet:
Ne alles gut, kommt null angreifend rüber.
Erklärt aber einiges. Also es hat mich nun definitiv ein wenig mehr aufgeklärt.
Die Frage ist welchen test oder was könnte denn mal laufen lassen um die volle Breite des dimms zu nutzen, denn dann sollte das ja auffallen das die Werte falsch sind und deine definitiv besser performen. Das würde ich echt mal gerne testen und Vergleichen.
Wie sieht es mit ycruncher 2.5b aus? Der müsste doch eigentlich alle ics voll fordern oder nicht?
Erklärt aber einiges. Also es hat mich nun definitiv ein wenig mehr aufgeklärt.
Die Frage ist welchen test oder was könnte denn mal laufen lassen um die volle Breite des dimms zu nutzen, denn dann sollte das ja auffallen das die Werte falsch sind und deine definitiv besser performen. Das würde ich echt mal gerne testen und Vergleichen.
Beitrag automatisch zusammengeführt:
Wie sieht es mit ycruncher 2.5b aus? Der müsste doch eigentlich alle ics voll fordern oder nicht?
Soweit fanden wir Riftbreaker "demo" , welches die Auslastung von memory, bzw die effizienz der Timings anzeigte und somit die GPU utilization erhöhte, da die CPU immer weniger zum "bottleneck" wurde.
Es ist schwer.
Chamclowder (chips'n'cheese server) hat einen recht guten "microbenchmark" geschrieben.
Aber leider gab es auch aufgrund dessen streiterein auf OCN
Wo man mir versucht hatte zu erklären dass Gear1 schneller sei auf Ryzen mit komplett unterschiedlichen timings (nicht hochskalliert) und ebenso probleme hatte den Artikel zu folgen was die Werte von diesem überhaupt bedeuten.
Leider immer ein Streitthema.
Ram ist schwer zu testen, den in Grundegenommen optimieren wir DRAM auf die Verwendung für das Zielsystem.
Wobei es anders rum gehört.
Man kann einige häbel anheben und andere senken um es für spezielle Datengrößen zu optimieren.
Ein anderer solcher "multi-dataset size" test, wäre SiSoftware Sandra. Den Inter-Thread Bandwidth test.
An diesem sieht man ob deine Änderung, im gesammten etwas für den Cache bzw kern zu kern beinflusst habe,
Oder nur die Potentielle effizienz stieg, welche allerdings aufgrund langsamer Architektur niemals komplett verwendet werden kann.
Um RAM wirklich ausführlich zu testen, brauchen wir größere dataset größen.
Etwas dass diesen auch füllt und dann zwingt timings wie RFC oder REFI zu erreichen.
Einen langen worin clock-halting (powerdown) aich einsetzt und keine konstannte last wäre.
Momentan können wir nur an der potentiellen Effizienz arbeiten, aber haben dennoch keinerlei garantie dass unsere Änderungen überhaupt etwas auswirken. Nur dass sie potetential haben effizienter zu sein, worin weniger Zeit darin verschwendet wird auf refreshes oder "zuu langen" timings zu warten.
Das meiste gehört aber zu DDR3/4
DDR5 hat doppelt so viele bankgroups und größere ICs
Der Grund zwischen ICs zu springen, geschweige den zu der selben Bankgroup wieder zu gelangen
// _L bzw SG timings. Ist soo niedrig. Die chance ist klein.
Solch etwas sieht man wenn man den Ram bzw mehrere tests gleichzeitig startet. Aber kann nur sehr schwer mit unseren perfekt-designten benchmarks erkannt werden.
Natürlich skalliert es, aber im normalfall triffst du nicht auf diese timings
Im normalfall ist RP zb komplett versteckt wärend es einen read im anderen IC ausführt.
RAS als solches passt sich selber an.
RRDS spielt nur eine rolle, wenn man selbstständig Werte wie FAW limitiert und RAM nicht erlaubt die anderen ICs zu verwenden.
Usw
Man sieht meistens eine drastische skallierung, wenn man absichtlich ein fehler begehe und timings überlappen.
Sorry für den langen post.
Beitrag automatisch zusammengeführt:
Pi benchmarks sind fast alle die selben
Die skallierung auf dem kommt meistens durch höherem UCLK von der CPU seite
Und ab und an zugriff zu dem RAM
Der RAM kann Pi nicht errechnen
Er weiß aber wo er was zu lagern hat, damit commands nie überlappen
Und auch wann er kurz eine pause einlegen muss.
Wir sehen eine skallierung, weil wir entweder timings verkürzen (meistens writes)
Oder weil wir die langsamtr Zeit von allem durch Spannung verkürzen.
RFC und REFI
Es ist schwierig.
Aber ich denke, wir sollten Tools wie microbenchmark und SiSandra Inter-Thread test ~ verwenden
Wenn wir nach roher Leistung gehen
Und weiterhin im Kopf behalten dass unsere einzel-tests nur ein Isoliertes Szenario testen
Ich mag aida für anytischr zwecke, aber pyprime ist auch recht gut
Bloß muss ich eine skallierung überall bemerken, ansonnsten mache ich etwas falsch, oder vegaas? hatte ein timing vergessen anzurühren, welches nun zum "bottleneck" wurde
So versuche ich zu arbeiten
Powerdown timings halte ich immer auf specs.
Specs geben ein minimum Wert an (meistens 8+)
Und einen ns Wert (eher wichtiger den clock ist irrelevant. Ändert sich pro MT/s)
Diese regeln versuche ich nicht zu brechen , den es sind einfach vieel zu viele sachen die gleichzeitig geschehen.
Pause-Timings sollten so lange brauchen wie sie nun mal brauchen müssen, sonnst passieren überlappungen und halting (nichts geschieht bis das problem selber vom controller behoben wurde.)
Eines solcher oft gefundenen probleme ist der Row-Miss
Welcher durch zuu tiefem RAS geschehe.
RCD+RTP ist der reine minimum. Die echte formel kommt auf die datengröße an ob dann +4,+8,+,12 obendrauf noch komme für RAS
Ob es mit autorefresh am schluss endet und länger braucht, oder kein chargeback braucht und somit kürzer endet.
tRAS ist ein dynamisches timing wie tRC :')
Zuletzt bearbeitet:
Lieber zu lang als zu kurz.
Ok das ist natürlich ernüchternd wenn es gerade mal eine demo gibt mit der man mal vergleichen könnte. Aber es ist ein Anfang.
Ansich sind und waren deine Erklärungen ja auch immer schlüssig.
Für mich war bisher immer das Problem das es erstmal nur auf dem Papier war und ich ingame oder in benchmarks keine Verbesserung festellen konnte.
Leider eher im Gegenteil.
Wäre echt geil wenn man da mal ein paar mehr Tools hätte, die dann wirklich den ram mal so nutzen dass alle timings relevant werden und man dort ein zu strammes erkennt.
Ok das ist natürlich ernüchternd wenn es gerade mal eine demo gibt mit der man mal vergleichen könnte. Aber es ist ein Anfang.
Ansich sind und waren deine Erklärungen ja auch immer schlüssig.
Für mich war bisher immer das Problem das es erstmal nur auf dem Papier war und ich ingame oder in benchmarks keine Verbesserung festellen konnte.
Leider eher im Gegenteil.
Wäre echt geil wenn man da mal ein paar mehr Tools hätte, die dann wirklich den ram mal so nutzen dass alle timings relevant werden und man dort ein zu strammes erkennt.
3gb dimms zb sind ebenfalls schneller, da bankgroup jumpn timings umso seltener getriggert? werden müssen.
Einfach da die ICs soo dense sind, und mehr daten halten können.
Und so weiter
Ein riesen thema über das man tage lang sich unterhalten könnte
Einfach da die ICs soo dense sind, und mehr daten halten können.
Und so weiter
Ein riesen thema über das man tage lang sich unterhalten könnte
Macht Sinn und erklärt auch echt gut warum manche Dinge die unsinnig sein sollten trotzdem besser performen. Danke schon mal für den input.
Und ycruncher 2.5b nutzt auch nur 12,7gb... da werden auch nicht alle ics voll genutzt. Das ist ja nen murks....
Bei der latenz Messung in Aida würde das auch nicht auffallen oder?
Beitrag automatisch zusammengeführt:
Und ycruncher 2.5b nutzt auch nur 12,7gb... da werden auch nicht alle ics voll genutzt. Das ist ja nen murks....
Beitrag automatisch zusammengeführt:
Bei der latenz Messung in Aida würde das auch nicht auffallen oder?
Aida ist ähnlich zu SiSandra.
Es testet erst mal die last pro kern
Und dann am schluss alle kerne, bevor es sein "optimales" ergebniss ermittelt.
Optimalle potentielle, durch random zugriff
Natürlich gegenregelt hier der controller und verteilt diese zugriffe zu den freien ICs
// somit auch hier spielt es eine Rolle wie du Aida rennst. Auf dem start button, wo alles nacheinander getest wird oder pro test fokusiert wo du höhere ergebnisse bekommst
Leider aber ist die größte Schwäche von AIDA auch seine stärke.
Ein potential max test, also quasy:
"Throw as many micro datapackages as possible and spam the cpu plus memory, to traceback buswidth and hit utilization limits of both. Then tell the system like a rops test, how much of those ping like packages responded back and calculate bandwidth"
Seine stärke und auch schwäche
Macht sein system gerade irgendetwas anderes, werden natürlich die ergebnisse niedriger.
Den mehr ram ist belegt und 1-2% der CPU reserviert
Ich mag den test sehr, aber kenne seine schwächen
In solch einem Szenario, zeigt es mir deutlich ob meine Timingsänderung im gesammten schneller "sein kann" oder ich wieder irgendwas irgendwo verlangsammt habe, durch eine apprupte frühe endung.
Natürlich hat das keinerlei einfluss dass es auch mehr FPS bringt, nur dass es potentiell effizienter und korrekter angesprochen wird.
Im grundgenommen ist jedes tiefere timing für irgend ein Szenario schneller
Aber es ist das gesammtbild welches wir beobachten sollen.
Erst später kommen dann schwer-zu-lesende tests wie microbenchmarks bzw SiSoftwareSandra's test suite.
Letzteres sehr gemocht von AMDs Lab
Aber leider auch zuu sensibel.Mousemovement ist verboten bei solchen langstrecke tests.
Beitrag automatisch zusammengeführt:
EDIT:
Bei AIDA möchtest du folgendes folgen:
~ immer nur den StartButton drücken und abwarten
~ eine latenzvariation zwischen den tests über 0.3ns = autocorrection. 0.2 delta für 5 tests ist ok
~ der erste test nach dem boot ist immer schneller, 1-2min nach Systemstart abwarten bzw immer den ersten test verwerfen
~ eine delta von 70-100MB/s können test to test variances sein. Es kommt darauf an wie sauber dein system ist
~ nur wenn alle read, write und copy oder copy+eines der beiden skaliert, fortfahren
Die selbe art zu testen geht ebenso auf ycruncher
6 tests und maximal erlaubte delta 0.050sec variance
Je wenigwr desto besser. Mein bestergebniss soweit ist auf <10ms delta für 6 nacheinander gereihten tests
Beitrag automatisch zusammengeführt:
Ahh, rip message ~ noch nicht zuHause
Ich schreibe dir dazu mehr ein anderes mal
Hatte beschrieben wie ich jetzt nun genau teste und vorgehe, aber für ein anderes mal
Zuletzt bearbeitet:
Das ist krass wenn es 2.5b ist. Da bin ich meist im 0.100 sec Bereich.
Hmmm, ich finde gerade ja absolut garnichts.
Hab alle 4 Kategorien auf OCN durchsucht, aber anscheinend hatte ich es nicht hochladen müssen
Leider auch kein backup auf der Platte, aber ich fand mal das hier für dich~
PyPrime
Aida64 Shenanigans
SiSoftwareSandra InterThread , testing
"Baad"
"OK" , delta ~9ms
So so, RAS drop test
Etwas langsamer, höherer RAS
Schnell aber für mich sinnlos ~ throttles
"OK" , delta ~9ms
So so, RAS drop test
Etwas langsamer, höherer RAS
Schnell aber für mich sinnlos ~ throttles
RAS & AutoPrecharge + ROW-Miss testing
7900X tests ~ "so so" , hatte alle SKU's als client und ich zum ersten mal gebinnt hatten
Ich erwarte unter 10ms consistency bei dem test
7900X tests ~ "so so" , hatte alle SKU's als client und ich zum ersten mal gebinnt hatten
Ich erwarte unter 10ms consistency bei dem test
Leider das einzige was ich fand.
Timings sind ... amateur-like So wie ich~
WTRS = 8 , WTRL war 38 , 3*RRDL test.
Timings sind ... amateur-like
So wie ich~WTRS = 8 , WTRL war 38 , 3*RRDL test.
RAS testing~
Joa und so weiter
Ich hoffe es ist vorerst genug Information bzw Bestätigung meiner Worte~
Weiterhin ein Amateur, und ich denke ich bin weitaus zu großzügig mit "sub 50ms" aber naja
Testen testen testen~
Aida & PyPrime/Y-cruncher zuerst
Und erst wenn ich zufrieden damit bin, überall eine positive Skallierung bemerke bzw eine exotische Idee habe (WTRS = half, z.B 🤭)
Erst dann komplexe Tools wie SiSandra & MicrobenchmarkGUI.
Sie mögen nicht die besten Ergebnisse sein & ich finde "teaching" angenehmer als ein Rivale zu sein
Mag es nicht mit Leuten zu kämpfen, und ebenso positioniert mich das in einer "nervigen" position.
Zu den Nutzern und Boardpartnern.
Aber im grundegenommen, versteht man mich falsch~
Somit hab ich mich entschieden mir eine Auszeit zu nehmen.
Einer netteren spähre zu folgen welche positive drauf ist
Und kein Rivale zu sein. Mehr geht natürlich mit besserer Kühlung, aber es ist eine teuere Arbeit.
Ich mag perfektion aber es ist nicht realistisch. Naja~
Soll nur ein Beispiel eines Amateurs darstellen.
Die letzten 2 Monate war eher der Fokus das Bios zu richten und leider lästig zu den Boardpartnern zu sein.
// EDIT: Biosmod für Z790 APEX ~ aber eher für forscher, AUTO mem-training ist besser auf 0066 LastBianBao Bios.
Ich wünschte ich könnte dir bessere Screenshots liefern, aber das ist gerade was ich so zusammenkratzen kann.
Hoffe du verstehst~~
Zuletzt bearbeitet:
