Jaffech
Community-Legende
Ich grüße euch liebe Hardware Enthusiasten,
es wird mal wieder Zeit für einen Leserartikel. Dieses mal geht es um wissenschaftliches RAM OC auf Basis von AM4 und DDR4, worüber ein Teil meiner Bachelorarbeit (04/2025) handelte. Daneben war noch AM5 und DDR5 ein Thema, dies wird aber in einem gesonderten Leserartikel behandelt, da dies den Rahmen sprengen würde.
Es geht allerdings nicht nur um das allseits bekannte „JEDEC/XMP vs manuell“, auch wenn das ein Teil ist, sondern viel mehr um den Performance Einfluss von einzelnen Timings wie tCL, tRCD, tRRD_, etc. Dahingehend erwarten euch eine Menge Analysen und Erkenntnisse.
Eine Sache sollte aber noch benannt werden: Ich wechsle hier im Artikel zwischen typischer „Forum-Schreibweise“ und „wissenschaftlicher Schreibweise“, da ich einige Dinge per DeepL aus meiner englischen Arbeit übersetzt habe, einiges aber auch ans Forum angepasst oder gar nur fürs Forum geschrieben habe. Nur dass ihr euch nicht wundert, wieso der Schreibstil wechselt.
Falls Interesse an meiner Bachelorarbeit (Englisch) in Gänze besteht, kann man mir gerne eine PN schicken.
Inhaltsverzeichnis:
I. Einleitung
Grundlegende Infos
II. Was bedeuten die Timings eigentlich?
Übersicht über viele Timings und DRAM Operationen
III. Testmethodik
Verwendetes Testsystem und Programme
IV. RAM Settings
Übersicht aller verwendeten Timings und Taktstufen
V. Ergebnisse mit Timing-Analyse
Analyse des Einflusses der Timing-Sets auf jedes Programm
VI. Was ist DRAMSys4.0?
Erklärung zu dem Programm
VII. DRAMSys4.0 vs reale Hardware
Bandbreiten-/Latenz-Analyse der Timings zwischen DRAMSys und AM4
VIII. Fazit
Abschließende Worte
I. Einleitung
II. Was bedeuten die Timings eigentlich?
III . Testmethodik
IV. RAM Settings
V. Ergebnisse mit Timing-Analyse
VI. Was ist DRAMSys ?
VII. DRAMSys4.0 vs reale Hardware
VIII. Fazit
Zum Abschluss möchte ich mich an dieser Stelle fürs lesen bedanken.
Ich hoffe ich konnte euch einige interessante Einblicke geben!
Wir lesen uns dann bei der DDR5 Analyse
es wird mal wieder Zeit für einen Leserartikel. Dieses mal geht es um wissenschaftliches RAM OC auf Basis von AM4 und DDR4, worüber ein Teil meiner Bachelorarbeit (04/2025) handelte. Daneben war noch AM5 und DDR5 ein Thema, dies wird aber in einem gesonderten Leserartikel behandelt, da dies den Rahmen sprengen würde.
Es geht allerdings nicht nur um das allseits bekannte „JEDEC/XMP vs manuell“, auch wenn das ein Teil ist, sondern viel mehr um den Performance Einfluss von einzelnen Timings wie tCL, tRCD, tRRD_, etc. Dahingehend erwarten euch eine Menge Analysen und Erkenntnisse.
Eine Sache sollte aber noch benannt werden: Ich wechsle hier im Artikel zwischen typischer „Forum-Schreibweise“ und „wissenschaftlicher Schreibweise“, da ich einige Dinge per DeepL aus meiner englischen Arbeit übersetzt habe, einiges aber auch ans Forum angepasst oder gar nur fürs Forum geschrieben habe. Nur dass ihr euch nicht wundert, wieso der Schreibstil wechselt.
Falls Interesse an meiner Bachelorarbeit (Englisch) in Gänze besteht, kann man mir gerne eine PN schicken.
Inhaltsverzeichnis:
I. Einleitung
Grundlegende Infos
II. Was bedeuten die Timings eigentlich?
Übersicht über viele Timings und DRAM Operationen
III. Testmethodik
Verwendetes Testsystem und Programme
IV. RAM Settings
Übersicht aller verwendeten Timings und Taktstufen
V. Ergebnisse mit Timing-Analyse
Analyse des Einflusses der Timing-Sets auf jedes Programm
VI. Was ist DRAMSys4.0?
Erklärung zu dem Programm
VII. DRAMSys4.0 vs reale Hardware
Bandbreiten-/Latenz-Analyse der Timings zwischen DRAMSys und AM4
VIII. Fazit
Abschließende Worte
I. Einleitung
Wer mich kennt weiß, dass ich beim Thema Tuning sehr gewissenhaft vor gehe. Dies gilt für meine Bachelorarbeit und daraus folgend diesem Leserartikel umso mehr. Da hier wissenschaftlich gearbeitet wird, sind die Toleranzen für Messschwankungen deutlich niedriger als üblicherweise bei PCGH und anderen Redaktionen. Darauf gehe ich in Kapitel II genauer ein.
Außerdem vergleiche ich die reale Umgebung auf Basis von AM4 mit dem DRAM-Simulator DRAMSys4.0, um Unterschiede und Gleichheit zwischen diesen aufzuzeigen.
Wem DRAMSys4.0 nichts sagt: Das ist ein DRAM Simulator, den unter anderem auch Mercedes Benz verwendet und in der wissenschaftlichen DRAM Welt ein hohes Ansehen genießt. In Kapitel VI schreibe ich mehr dazu.
Ein kleiner Spoiler vorneweg: Die maximale Leistungssteigerung die erzielt werden konnte beträgt 46% im Vergleich zu 3200 MT/s JEDEC (also 5800X3D Spezifikation).
Der Kern ist hier aber wie geschrieben der Fokus auf die Skalierung der Timings selbst, nicht „alles auf einmal“. Das ist nur ein Bonus und ein Leser-Köder
In meiner Arbeit befindet sich auch ein Kapitel dazu wie DRAM überhaupt funktioniert, das kann ich mir an dieser Stelle aber sparen und verweise stattdessen auf den extrem guten Deep Dive Artikel von @PCGH_Torsten, der das in ähnlicher Weise behandelt:
www.pcgameshardware.de
Noch ein kleiner Hinweis: Aufgrund der Tatsache, dass es sich hier um meine BA von letztem Jahr handelt und ich das System auch nicht mehr besitze, sind nachträgliche Messungen nicht möglich
Außerdem vergleiche ich die reale Umgebung auf Basis von AM4 mit dem DRAM-Simulator DRAMSys4.0, um Unterschiede und Gleichheit zwischen diesen aufzuzeigen.
Wem DRAMSys4.0 nichts sagt: Das ist ein DRAM Simulator, den unter anderem auch Mercedes Benz verwendet und in der wissenschaftlichen DRAM Welt ein hohes Ansehen genießt. In Kapitel VI schreibe ich mehr dazu.
Ein kleiner Spoiler vorneweg: Die maximale Leistungssteigerung die erzielt werden konnte beträgt 46% im Vergleich zu 3200 MT/s JEDEC (also 5800X3D Spezifikation).
Der Kern ist hier aber wie geschrieben der Fokus auf die Skalierung der Timings selbst, nicht „alles auf einmal“. Das ist nur ein Bonus und ein Leser-Köder
In meiner Arbeit befindet sich auch ein Kapitel dazu wie DRAM überhaupt funktioniert, das kann ich mir an dieser Stelle aber sparen und verweise stattdessen auf den extrem guten Deep Dive Artikel von @PCGH_Torsten, der das in ähnlicher Weise behandelt:
(+) Sündhaft teuer in der Speicherkrise: Wie funktioniert RAM? Arbeitsspeicher im Detail erklärt
Die Diskussionen über „HUDIMM“-Billig-DDR5 haben gezeigt: Obwohl viel über RAM geredet wird, kennen die Wenigsten alle Details. Unser Deep-Dive ändert das.
II. Was bedeuten die Timings eigentlich?
Für den ein oder anderen Interessant könnte auch eine Erklärung der verschiedenen Timings sein. Insbesondere mit dem Hintergrundwissen wie DRAM funktioniert (siehe Torstens Deep Dive).
Das sind natürlich erstmal eine ganze Menge Timings die es gibt (und noch viel mehr, die man aber oft nicht setzen und/oder auslesen kann wie tRTRS,tRPRE, tRDAACT, etc).
Je nach genauer DRAM Operation kommen auch verschiedene Timings zum Einsatz, was auch der Grund ist, wieso ich solche „Latenz Tests“ wie z.B. von AIDA nicht mag – es ist schlicht nicht klar, was und wie exakt getestet wird. Es gibt nicht „die Latenz“. Es hängt immer davon ab, um welche Operation es sich handelt.
Beispielsweise der Row Access:
(Deutsche Übersetzung meiner BA mit DeepL)
Der Zeilenzugriffsbefehl (Row Access) dient dazu, Daten aus den Zellen der DRAM-Arrays in die Leseverstärker (Sense Amplifiers) zu übertragen und sie anschließend im Rahmen desselben Vorgangs wieder in die Zellen zurückzuschreiben. Mit diesem Befehl sind zwei wichtige Timing-Parameter verknüpft: tRCD und tRAS. Die Zeit, die benötigt wird, um Daten von den DRAM-Zellen in die Leseverstärker zu übertragen, wird als Row-Column-Delay bezeichnet, kurz tRCD. Nachdem dieses tRCD-Intervall ab dem Zeitpunkt der Ausgabe des Zeilenzugriffsbefehls verstrichen ist, liegt die gesamte Datenzeile in den Leseverstärkern vor, sodass nachfolgende Spalten-Lese- oder Schreibbefehle Daten zwischen den Verstärkern und dem Speichercontroller über den Datenbus übertragen können. Obwohl die Daten nach Ablauf von tRCD in den Leseverstärkern verfügbar sind, wurden sie noch nicht vollständig in die DRAM-Zellen zurückgeschrieben. Die Zeit, die der Zeilenzugriffsbefehl benötigt, um das Entladen und Zurückschreiben der Daten in die DRAM-Zellen abzuschließen, wird als Row Access Strobe Latenz bezeichnet, kurz tRAS. Sobald das tRAS-Intervall abgelaufen ist, gilt die Datenwiederherstellung als abgeschlossen, und die Leseverstärker können vorgeladen (precharge) werden, um den Zugriff auf eine andere Zeile innerhalb derselben Bank der DRAM-Arrays vorzubereiten.
Daher: „Die Latenz“ hängt davon ab, welche Operation durchgeführt wird. Da nicht bekannt ist, welche Operation(en) AIDA durchführt, ist es auch kein valider Latenztest, da nicht alle Timings eine gleiche Gewichtung bekommen, sondern eben die maßgeblich genutzten Timings für diesen Test entsprechend eine hohe Gewichtung haben. Das sehen wir bei der Analyse der Ergebnisse ebenfalls, vor allem bei dem kommenden DDR5 Leserartikel.
Um das mal zu verdeutlichen, hier ein kleiner Auszug an möglichen Operationen:
(Ohne Übersetzung)
Natürlich gibt es noch viel mehr Operationen, aber es reicht um den Punkt klar zu machen 
| Name | Erklärung |
|---|---|
| tBURST | Datenburst-Dauer: Der Zeitraum, den ein Datenburst auf dem Datenbus belegt. |
| tCLK | DRAM-Takt: Der Takt des DRAM-Interfaces. |
| tCL | CAS-Latenz: Die Verzögerung von einem Lesebefehl bis die Daten am Interface gelesen werden können. |
| tCWL | CAS-Schreiblatenz: Wie tCL, aber für Schreibvorgänge (Write). |
| tCCD | Column-to-Column-Delay: Das minimale Spaltenbefehl-Timing, bestimmt durch die interne Burst-Länge (Prefetch). |
| tCCDS | Column-to-Column-Delay Short: Bankzugriffe auf unterschiedliche Bankgruppen. |
| tCCDL | Column-to-Column-Delay Long: Bankzugriffe innerhalb derselben Bankgruppe. |
| tRCD | Row-to-Column-Delay: Das Zeitintervall zwischen ACT und RD an derselben Bank. |
| tRP | Row Precharge: Die Bänke müssen vorladen (PRE) und für tRP inaktiv sein, bevor ein Refresh-Befehl ausgeführt werden kann. |
| tRAS | Row Access Strobe: Die minimale Aktivzeit einer Zeile – also das Zeitintervall zwischen dem Zeilenzugriffsbefehl und der Datenwiederherstellung im DRAM-Array. |
| tRC | Row Cycle: Die kürzestmögliche Zeit, um dieselbe Zeile zu aktivieren und vorzuladen (tRC = tRAS + tRP) – also das Zeitintervall zwischen Zugriffen auf unterschiedliche Zeilen einer Bank. |
| tRRDS | Row-to-Row-Delay Short: Werden aufeinanderfolgende Aktivierungsbefehle an Bänke unterschiedlicher Bankgruppen gesendet, müssen diese Befehle durch tRRDS getrennt werden. |
| tRRDL | Row-to-Row-Delay Long: Gehören die Bänke zur selben Bankgruppe, müssen ihre Aktivierungen durch tRRDL getrennt werden. |
| tFAW | Four Activate Window: In diesem Zeitfenster dürfen nur vier ACT-Befehle ausgegeben werden. ACT-Befehle können nacheinander mit tRRDS/L Abstand ausgegeben werden. (Daher die Regel: tFAW = 4 x tRRD) |
| tREF | Refresh-Periode: Der Zeitraum, in dem eine DRAM-Zelle aufgefrischt werden muss |
| tREFI | Refresh-Intervall: Das Zeitintervall zwischen zwei Refresh-Befehlen |
| tRFC | Refresh-Zyklus: Das Zeitintervall zwischen REF- und ACT-Befehlen. |
| tWTRS | Write-to-Read Short: Verzögerung vom Start einer internen Schreibtransaktion bis zum internen Lesebefehl an eine andere Bankgruppe. |
| tWTRL | Write-to-Read Long: Verzögerung vom Start einer internen Schreibtransaktion bis zum internen Lesebefehl an dieselbe Bankgruppe. |
| tWR | Write Recovery: Das minimale Zeitintervall zwischen dem Ende eines Schreibbursts und einem PRE-Befehl. |
| tRTP | Read to Precharge: Das Zeitintervall zwischen einem RD- und einem PRE-Befehl. Vielfaches von tWR (2 x bei DDR4, 4 x bei DDR5) |
| tRDWR | Read-Write-Command-Spacing: Die Anzahl der Umschalttakte zwischen einem Lesebefehl und einem Schreibbefehl am selben Rank. |
| tWRRD | Write-Read-Command-Spacing: Die Anzahl der Umschalttakte zwischen einem Schreibbefehl und einem Lesebefehl am selben Rank. |
| tRDRDSC | Read-to-Read-Delay, unterschiedliche Bankgruppe: Die Verzögerung zwischen zwei Lesebefehlen. |
| tRDRDSCL | RDRD, gleiche Bankgruppe. |
| tRDRDSD | RDRD, gleiches DIMM, aber unterschiedlicher Rank. |
| tRDRDDD | RDRD, unterschiedliches DIMM und/oder unterschiedlicher Rank. |
| tWRWRSC | Write-to-Write-Delay, unterschiedliche Bankgruppe: Die Verzögerung zwischen zwei Schreibbefehlen. |
| tWRWRSCL | WRWR-Delay, gleiche Bankgruppe. |
| tWRWRSD | WRWR, gleiches DIMM, aber unterschiedlicher Rank. |
| tWRWRDD | WRWR-Delay, unterschiedliches DIMM und/oder unterschiedlicher Rank. |
Je nach genauer DRAM Operation kommen auch verschiedene Timings zum Einsatz, was auch der Grund ist, wieso ich solche „Latenz Tests“ wie z.B. von AIDA nicht mag – es ist schlicht nicht klar, was und wie exakt getestet wird. Es gibt nicht „die Latenz“. Es hängt immer davon ab, um welche Operation es sich handelt.
Beispielsweise der Row Access:
(Deutsche Übersetzung meiner BA mit DeepL)
Der Zeilenzugriffsbefehl (Row Access) dient dazu, Daten aus den Zellen der DRAM-Arrays in die Leseverstärker (Sense Amplifiers) zu übertragen und sie anschließend im Rahmen desselben Vorgangs wieder in die Zellen zurückzuschreiben. Mit diesem Befehl sind zwei wichtige Timing-Parameter verknüpft: tRCD und tRAS. Die Zeit, die benötigt wird, um Daten von den DRAM-Zellen in die Leseverstärker zu übertragen, wird als Row-Column-Delay bezeichnet, kurz tRCD. Nachdem dieses tRCD-Intervall ab dem Zeitpunkt der Ausgabe des Zeilenzugriffsbefehls verstrichen ist, liegt die gesamte Datenzeile in den Leseverstärkern vor, sodass nachfolgende Spalten-Lese- oder Schreibbefehle Daten zwischen den Verstärkern und dem Speichercontroller über den Datenbus übertragen können. Obwohl die Daten nach Ablauf von tRCD in den Leseverstärkern verfügbar sind, wurden sie noch nicht vollständig in die DRAM-Zellen zurückgeschrieben. Die Zeit, die der Zeilenzugriffsbefehl benötigt, um das Entladen und Zurückschreiben der Daten in die DRAM-Zellen abzuschließen, wird als Row Access Strobe Latenz bezeichnet, kurz tRAS. Sobald das tRAS-Intervall abgelaufen ist, gilt die Datenwiederherstellung als abgeschlossen, und die Leseverstärker können vorgeladen (precharge) werden, um den Zugriff auf eine andere Zeile innerhalb derselben Bank der DRAM-Arrays vorzubereiten.
Daher: „Die Latenz“ hängt davon ab, welche Operation durchgeführt wird. Da nicht bekannt ist, welche Operation(en) AIDA durchführt, ist es auch kein valider Latenztest, da nicht alle Timings eine gleiche Gewichtung bekommen, sondern eben die maßgeblich genutzten Timings für diesen Test entsprechend eine hohe Gewichtung haben. Das sehen wir bei der Analyse der Ergebnisse ebenfalls, vor allem bei dem kommenden DDR5 Leserartikel.
Um das mal zu verdeutlichen, hier ein kleiner Auszug an möglichen Operationen:
(Ohne Übersetzung
)| Prev | Next | Rank | Bank | Minimum Timings | Notes |
| Row Access | Row Access | same | same | tRC | |
| Row Access | Row Access | same | different | tRRD | + tFAW for >4 tRAS to same rank |
| Precharge | Row Access | same | different | tRP | |
| Refresh | Row Access | same | same | tRFC | |
| Row Access | Column Read | same | same | tRCD – tAL | tAL = 0 without posted CAS |
| Column Read | Column Read | same | any | Max (tBURST, tCCD) | Burst of prev. CR |
| Column Read | Column Read | different | any | tBURST + tRTRS | Burst of prev. CR |
| Column Write | Column Read | same | any | tCWL + tBURST + tWTR | Burst of prev. CW |
| Column Write | Column Read | different | any | tCWL + tBURST + tRTRS - tCL | Burst of prev. CW |
| Row Access | Column Write | same | same | tRCD – tAL | |
| Column Read | Column Write | any | any | tCL + tBURST + tRTRS – tCWL | Burst of prev. CR |
| Column Write | Column Write | same | any | Max (tBURST, tCCD) | Burst of prev. CW |
| Column Write | Column Write | different | any | tBURST + tOST | Burst of prev. CW |
| Row Access | Precharge | same | same | tRAS | |
| Column Read | Precharge | same | same | tAL + tBURST + tRTP - tCCD | Burst of prev. CR |
| Column Write | Precharge | same | same | tAL + tCWL + tBURST | Burst of prev. CW |
| Refresh | Refresh | same | any | tRFC | |
| Precharge | Refresh | same | any | tRP |
III . Testmethodik
Gerade bei wissenschaftlichem Arbeiten ist die Testmethodik extrem wichtig, daher bekommt dieser Teil auch eine größere Rolle und mehr Text.
Zu aller erst sollte geklärt werden, welche Hardware benutzt wurde.
Es kommt also eine starke Custom Wakü zum Einsatz. Außerdem betrug die Raumtemperatur bei jedem Test zwischen 20°C und 22 °C um die Temperatur als Einfluss möglichst gering zu halten.
Das BIOS wurde vor den Tests auf default zurück gesetzt und anschließend Secure Boot und Virtualisierung deaktiviert um mögliche Einflüsse auf das OS zu eliminieren. Außerdem wurde für alle Test der Curve Optimizer auf -30 gesetzt, damit die CPU durchweg ihre 4450 MHz hält. Das ist für einen 5800X3D nichts ungewöhnliches und wurde natürlich auch ausgiebig auf Stabilität getestet, u.a. mit CoreCycler (SSE, AVX, AVX2, all FFTs), y-cruncher, prime95 allcore, etc pp.
Die offizielle RAM Spec der CPU sind 3200 MT/s, die meisten Zen3 CPUs schaffen aber 3800 MT/s, was bei einer Bonusmessung zum Schluss auch genutzt wird. Wie bei AM4 Ryzen CPUs üblich, wird der FCLK 1:1 zum UCLK gesetzt, also bei 3200 MT/s sind das 1600 MHz UCLK und FCLK. Außerdem ist der PowerDown Mode deaktiviert um die Powerdown Timings nicht auch noch behandeln zu müssen, da gibts nämlich auch eine Menge, die Einfluss haben. Bei RAM Tuning schaltet man PDM in der Regel auch aus.
Kommen wir nun also zu den getesteten Programmen.
Die Spiele werden wie üblich mit CapFrameX gemessen. Aber wie in der Einleitung auch geschrieben, sind die Einstellungen deutlich nerviger* als bei PCGH und anderen Redaktionen üblich. Es wurden insgesamt 5 Messungen aggregiert, statt 3, und mit 3% P0.2 outliner als Aggregationsmetrik gegenüber 7% P1 auch deutlich strenger zusammenliegend als bei PCGH. Dies soll aber keineswegs Kritik gegenüber @PCGH_Dave sein: Bei der Menge an CPUs und Spielen die er testet, macht das schon zeitlich gar keinen Sinn so streng zu filtern. Da muss man einfach realistisch bleiben. Bei einer wissenschaftlichen Arbeit wird allerdings präzision erwartet, auf kosten der Zeiteffizienz. Neben den Avg Fps werden auch die P5 (5% low), P1 (1% low) und P0.2 (0,2% low) gemessen.
*nervig, weil man bei solch straffen Einstellungen auch gerne mal >20, vereinzelt auch >40, Messungen machen muss um die Kriterien für eine gültige Messung zu erreichen. Jeder der schonmal mit CFX gebencht hat, kennt diesen Pain.
Bei den Programmen werden auch jeweils einige Wiederholungen durchgeführt (mind. 5 Läufe) und manuell auf 3% Outliner korrigiert, sodass man wie bei CFX am Ende 5 Runs mit <3% Outliner erreicht.
Noch ein paar Worte zu den genutzten Spielen und Programmen:
Baldurs Gate 3 kennen die meisten ohnehin aus dem PCGH Testparcour und genau diese Szene wird auch von mir genutzt: Im dritten Akt gibt es eine riesige Stadt mit vielen NPCs, die eine leistungsstarke CPU und schnellen Arbeitsspeicher erfordern, um ein flüssiges Spielerlebnis zu gewährleisten. Aus diesem Grund ist die RAM-Skalierung dieses Spiels sehr gut. Die Einstellungen sind auf das Maximum eingestellt, mit DLSS-Leistungs-Upscaling bei einer Auflösung von 1920 × 1080 Pixeln, was einer effektiven Auflösung von 960 × 540 Pixeln entspricht.
Bei Cyberpunk 2077 wird natürlich ebenfalls die PCGH Szene mit dem Motorrad genutzt, damit die Streaming Engine der RED Engine (RIP) auch voll zur geltung kommt. Der Arbeitsspeicher hat einen starken Einfluss auf die Leistung, da es sich um eine dynamische offene Welt handelt, in der in jeder Szene zahlreiche Menschen und Autos zu sehen sind. Aus diesem Grund gehört dieses Spiel zu den Titeln mit der besten RAM-Skalierung, insbesondere wenn man wie in der Benchmark-Szene mit hoher Geschwindigkeit auf den Straßen Motorrad fährt. Die Einstellungen entsprechen der Voreinstellung „Raytracing Ultra“ des Spiels mit DLSS Ultra Performance bei einer Auflösung von 1920 × 1080 Pixeln und zusätzlich „hoher“ Massendichte. Also wie bei PCGH eben auch.
Starfield wurde u.a. wegen seiner nicht wettbewerbsfähigen „Creation Engine 2“ kritisiert, bei der es sich um eine leicht verbesserte Version der „Creation Engine“ handelt, die teilweise auf der „Gamebryo Engine“ aus dem Jahr 2002 basiert. Das Spiel verfügt jedoch über eine offene Welt ähnlich wie Cyberpunk 2077, was bedeutet, dass der Computer eine hohe Streaming-Last bewältigen muss und daher eine hohe Datenbandbreite für die Bildrate erforderlich ist. Die verwendeten Einstellungen sind die höchstmöglichen mit DLSS-Ultra-Performance-Upscaling bei einer Auflösung von 1920 x 1080 Pixeln.
Auch wenn ich weiter oben AIDA kritisiert habe, ist es bei vielen Menschen ein Standard Benchmark, daher nutze ich diesen der Vollständigkeithalber trotzdem. Es ist zumindest eine RAM Skalierung vorhanden.
AIDA Photoworxx ist einer der integrierten Benchmarks der Software AIDA64 Extreme. Dieser ist bekannt für seine beeindruckende RAM-Skalierung, insbesondere hinsichtlich Geschwindigkeit und Timings. Die Software wird von FinalWire entwickelt und ist kostenpflichtig. Die kostenlose Version enthält diesen Benchmark jedoch ebenfalls und eignet sich daher als Vergleichsgrundlage für verschiedene RAM-Einstellungen innerhalb eines Systems. Der Vergleichswert wird als „Megapixel pro Sekunde“ bezeichnet. Die beiden anderen getesteten AIDA-Benchmarks sind der Speicherkopiertest und der Speicherlatenztest, die ebenfalls mit einigen RAM-Timings sowie der Bandbreite skalieren, wobei die Messwerte „MB/s“ und „ns“ (Nanosekunden) lauten.
Microbenchmarks ist ein Programm zum Testen verschiedener CPU-bezogener Aspekte wie ROB-/Registerdateigrößen, Latenz bei Lock-/Cache-Kohärenz sowie Cache-/Speicherleistung. Im Gegensatz zu AIDA ist dieses Tool kostenlos und aussagekräftiger. Hier werden zahlreiche Testgrößen durchgetestet. Die Standardtestgrößen reichen von 2 KiB (Cache) bis 3.145.728 KiB (RAM) und können sowohl beim Lesen als auch beim Schreiben mit verschiedenen Befehlssätzen wie MMX, SSE oder AVX und sogar AVX-512 getestet werden. Für diesen Test konzentrieren wir uns auf Testgrößen von 384 MiB bis zu 3 GiB, da niedrigere Werte bereits von den CPU-Caches bestimmt werden. Die Einheit dieses Benchmarks ist „MB/s“.
PyPrime ist ein Open-Source-Benchmark auf Python-Basis, der gut mit der RAM-Taktfrequenz, den Timings und der Gesamtlatenz skaliert, weniger jedoch mit der CPU-Geschwindigkeit wie z.B. Y-Cruncher. PyPrime berechnet Pi mit einer unterschiedlichen Anzahl von Stellen, die in verschiedenen Schritten von 32 Millionen bis zu 32 Milliarden gewählt werden kann. Für unseren Benchmark verwenden wir die Version mit 8 Milliarden Stellen. Der Vergleichswert ist „Sekunde“ und die Ergebnisse werden mit dem Programm „BenchMate“ gemessen.
Das letzte Programm heißt pChase und ist mein persönlicher Favorit was RAM Benchmarks angeht. PChase ist über GitHub verfügbar. Hier kann man sich die Latenz und die Bandbreite verschiedener Zugriffsmuster (random/sequentiell) und mit extrem vielen Faktoren messen wie z.B. Byte Size, Stride, CacheLineSize, Testmenge, etc pp. Wir testen den zufälligen Zugriff mit den Argumenten „-c 1879048192 -t 16 -l 64 -i 5 -a random“, was bedeutet, dass 1,75 GiB mit 16 Threads getestet werden, was insgesamt 28 GiB ergibt. Darüber hinaus sind fünf Iterationen mit einer Cache-Zeilengröße von 64 Byte die weiteren Argumente. Der sequentielle Zugriff hat dieselben Argumente mit Ausnahme von „[…] -i 15 -a forward 20“. Dies bedeutet 15 Iterationen mit vorwärtsgerichteten sequentiellen Zugriff und einem Stride-Wert von 20.
Zu aller erst sollte geklärt werden, welche Hardware benutzt wurde.
Komponente | Spezifischer Typ |
OS | Windows 10 build 19045 |
CPU | AMD Ryzen 7 5800X3D |
CPU Kühler | Cuplex Cryos Next AM4 Wasserkühler |
RAM | 2 x 16 GiB DDR4-3200CL16-18-18 (S8B ICs) |
Grafikkarte und Treiber | RTX 4090, 556.03 |
Grafikkarten-Kühler | Alphacool Acryl Wasserkühler |
Mainboard / BIOS | MSI X570S Edge Max Wi-Fi / AGESA 1.2.0. A |
Festplatte | 2 TiB Corsair MP600 ProXT |
Netzteil | Corsair RM1000x (2019 version) |
Radiator | Watercool MoRa 420 |
Radiator-Lüfter | 4x Noctua NF-A20 |
Pumpe | Alphacool VPP Apex |
Steuerung | Aquacomputer Quadro |
Durchfluss Sensor | Aquacomputer Highflow 2 |
Temperatursensor | 2x Alphacool Eiszapfen G ¼ |
Das BIOS wurde vor den Tests auf default zurück gesetzt und anschließend Secure Boot und Virtualisierung deaktiviert um mögliche Einflüsse auf das OS zu eliminieren. Außerdem wurde für alle Test der Curve Optimizer auf -30 gesetzt, damit die CPU durchweg ihre 4450 MHz hält. Das ist für einen 5800X3D nichts ungewöhnliches und wurde natürlich auch ausgiebig auf Stabilität getestet, u.a. mit CoreCycler (SSE, AVX, AVX2, all FFTs), y-cruncher, prime95 allcore, etc pp.
Die offizielle RAM Spec der CPU sind 3200 MT/s, die meisten Zen3 CPUs schaffen aber 3800 MT/s, was bei einer Bonusmessung zum Schluss auch genutzt wird. Wie bei AM4 Ryzen CPUs üblich, wird der FCLK 1:1 zum UCLK gesetzt, also bei 3200 MT/s sind das 1600 MHz UCLK und FCLK. Außerdem ist der PowerDown Mode deaktiviert um die Powerdown Timings nicht auch noch behandeln zu müssen, da gibts nämlich auch eine Menge, die Einfluss haben. Bei RAM Tuning schaltet man PDM in der Regel auch aus.
Kommen wir nun also zu den getesteten Programmen.
Anwendungstyp | Anwendungsname |
Spiel | Baldurs Gate 3 |
Spiel | Cyberpunk 2077 |
Spiel | Starfield |
Anwendung | AIDA Photoworxx, Memory Copy und Memory Latency |
Anwendung | Microbenchmarks read/write mit MicrobenchmarksGUI |
Anwendung | PyPrime 8b via BenchMate 12.1.0 |
Anwendung | pChase random and sequential |
*nervig, weil man bei solch straffen Einstellungen auch gerne mal >20, vereinzelt auch >40, Messungen machen muss um die Kriterien für eine gültige Messung zu erreichen. Jeder der schonmal mit CFX gebencht hat, kennt diesen Pain.
Bei den Programmen werden auch jeweils einige Wiederholungen durchgeführt (mind. 5 Läufe) und manuell auf 3% Outliner korrigiert, sodass man wie bei CFX am Ende 5 Runs mit <3% Outliner erreicht.
Noch ein paar Worte zu den genutzten Spielen und Programmen:
Baldurs Gate 3 kennen die meisten ohnehin aus dem PCGH Testparcour und genau diese Szene wird auch von mir genutzt: Im dritten Akt gibt es eine riesige Stadt mit vielen NPCs, die eine leistungsstarke CPU und schnellen Arbeitsspeicher erfordern, um ein flüssiges Spielerlebnis zu gewährleisten. Aus diesem Grund ist die RAM-Skalierung dieses Spiels sehr gut. Die Einstellungen sind auf das Maximum eingestellt, mit DLSS-Leistungs-Upscaling bei einer Auflösung von 1920 × 1080 Pixeln, was einer effektiven Auflösung von 960 × 540 Pixeln entspricht.
Bei Cyberpunk 2077 wird natürlich ebenfalls die PCGH Szene mit dem Motorrad genutzt, damit die Streaming Engine der RED Engine (RIP) auch voll zur geltung kommt. Der Arbeitsspeicher hat einen starken Einfluss auf die Leistung, da es sich um eine dynamische offene Welt handelt, in der in jeder Szene zahlreiche Menschen und Autos zu sehen sind. Aus diesem Grund gehört dieses Spiel zu den Titeln mit der besten RAM-Skalierung, insbesondere wenn man wie in der Benchmark-Szene mit hoher Geschwindigkeit auf den Straßen Motorrad fährt. Die Einstellungen entsprechen der Voreinstellung „Raytracing Ultra“ des Spiels mit DLSS Ultra Performance bei einer Auflösung von 1920 × 1080 Pixeln und zusätzlich „hoher“ Massendichte. Also wie bei PCGH eben auch.
Starfield wurde u.a. wegen seiner nicht wettbewerbsfähigen „Creation Engine 2“ kritisiert, bei der es sich um eine leicht verbesserte Version der „Creation Engine“ handelt, die teilweise auf der „Gamebryo Engine“ aus dem Jahr 2002 basiert. Das Spiel verfügt jedoch über eine offene Welt ähnlich wie Cyberpunk 2077, was bedeutet, dass der Computer eine hohe Streaming-Last bewältigen muss und daher eine hohe Datenbandbreite für die Bildrate erforderlich ist. Die verwendeten Einstellungen sind die höchstmöglichen mit DLSS-Ultra-Performance-Upscaling bei einer Auflösung von 1920 x 1080 Pixeln.
Auch wenn ich weiter oben AIDA kritisiert habe, ist es bei vielen Menschen ein Standard Benchmark, daher nutze ich diesen der Vollständigkeithalber trotzdem. Es ist zumindest eine RAM Skalierung vorhanden.
AIDA Photoworxx ist einer der integrierten Benchmarks der Software AIDA64 Extreme. Dieser ist bekannt für seine beeindruckende RAM-Skalierung, insbesondere hinsichtlich Geschwindigkeit und Timings. Die Software wird von FinalWire entwickelt und ist kostenpflichtig. Die kostenlose Version enthält diesen Benchmark jedoch ebenfalls und eignet sich daher als Vergleichsgrundlage für verschiedene RAM-Einstellungen innerhalb eines Systems. Der Vergleichswert wird als „Megapixel pro Sekunde“ bezeichnet. Die beiden anderen getesteten AIDA-Benchmarks sind der Speicherkopiertest und der Speicherlatenztest, die ebenfalls mit einigen RAM-Timings sowie der Bandbreite skalieren, wobei die Messwerte „MB/s“ und „ns“ (Nanosekunden) lauten.
Microbenchmarks ist ein Programm zum Testen verschiedener CPU-bezogener Aspekte wie ROB-/Registerdateigrößen, Latenz bei Lock-/Cache-Kohärenz sowie Cache-/Speicherleistung. Im Gegensatz zu AIDA ist dieses Tool kostenlos und aussagekräftiger. Hier werden zahlreiche Testgrößen durchgetestet. Die Standardtestgrößen reichen von 2 KiB (Cache) bis 3.145.728 KiB (RAM) und können sowohl beim Lesen als auch beim Schreiben mit verschiedenen Befehlssätzen wie MMX, SSE oder AVX und sogar AVX-512 getestet werden. Für diesen Test konzentrieren wir uns auf Testgrößen von 384 MiB bis zu 3 GiB, da niedrigere Werte bereits von den CPU-Caches bestimmt werden. Die Einheit dieses Benchmarks ist „MB/s“.
PyPrime ist ein Open-Source-Benchmark auf Python-Basis, der gut mit der RAM-Taktfrequenz, den Timings und der Gesamtlatenz skaliert, weniger jedoch mit der CPU-Geschwindigkeit wie z.B. Y-Cruncher. PyPrime berechnet Pi mit einer unterschiedlichen Anzahl von Stellen, die in verschiedenen Schritten von 32 Millionen bis zu 32 Milliarden gewählt werden kann. Für unseren Benchmark verwenden wir die Version mit 8 Milliarden Stellen. Der Vergleichswert ist „Sekunde“ und die Ergebnisse werden mit dem Programm „BenchMate“ gemessen.
Das letzte Programm heißt pChase und ist mein persönlicher Favorit was RAM Benchmarks angeht. PChase ist über GitHub verfügbar. Hier kann man sich die Latenz und die Bandbreite verschiedener Zugriffsmuster (random/sequentiell) und mit extrem vielen Faktoren messen wie z.B. Byte Size, Stride, CacheLineSize, Testmenge, etc pp. Wir testen den zufälligen Zugriff mit den Argumenten „-c 1879048192 -t 16 -l 64 -i 5 -a random“, was bedeutet, dass 1,75 GiB mit 16 Threads getestet werden, was insgesamt 28 GiB ergibt. Darüber hinaus sind fünf Iterationen mit einer Cache-Zeilengröße von 64 Byte die weiteren Argumente. Der sequentielle Zugriff hat dieselben Argumente mit Ausnahme von „[…] -i 15 -a forward 20“. Dies bedeutet 15 Iterationen mit vorwärtsgerichteten sequentiellen Zugriff und einem Stride-Wert von 20.
IV. RAM Settings
Die RAM Settings wollte ich (wie in der BA) auch zur Testmethodik packen, aber da das schon so voll gepackt ist, bekommen die RAM Settings ihr eigenes Kapitel.
Wie angesprochen werde ich verschiedene Settings und einzelne Timing(-blöcke) miteinander vergleichen.
Kleine Randinformation: Es gibt pro Taktstufe übrigens mehrere JEDEC Settings, nur nur eins.gif "sm_B-) :-)")
Entschuldigt bitte die unhomogenen Tabellenstrukturen, ich bekomme das hier im Forum nicht schön formatiert.
Als erstes das JEDEC 3200AA Setting:
* Automatisch gesetzt
Als nächstes das 3200er XMP Setting:
Kommen wir zum interessanten Teil und den Kern der Bachelorarbeit.
Es geht darum, zu evaluieren wie einzelne Timings skalieren, daher habe ich "Timing-Sets" erstellt in denen einzelne Timings vorhanden sind oder Timings die funktional zusammen gehören.
Die Einteilung der Timings folgt dieser Tabelle:
- tCL und tCWL sind zusammengefasst, da es beides ColumnLine Timings sind, einmal für Write und einmal für read.
- tRCDWR/RD ist das Zeitintervall zwischen ACT und dem Lese- oder Schreibvorgang in derselben Zeile.
- tRC ist die schnellste Zeit bis zu ACT und PRE in derselben Zeile, also entspricht sie tRP + tRAS.
- tFAW bezeichneten das Zeitfenster in der vier ACT-Befehle ausgegeben werden, wobei die ACT-Befehle direkt aufeinander folgen und jeweils durch tRRD voneinander getrennt sind. Somit bilden tFAW und tRRD (S, L) eine Einheit.
- tWR und tRP gehören zu einer Gruppe, da sie die Zeit zwischen einem Schreib- oder Lesevorgang und PRE beschreiben.
- tRFC als Refresh Timing bleibt einzeln
- tWTR (S, L) und tWRRD sowie tRDWR sind hingegen die Umschaltzeiten zwischen Lese- und Schreibvorgang bzw. zwischen Schreib- und Lesevorgang und werden daher zusammen gefasst
- tRDRD_- und tWRWR_-Operationen, sind die die Verzögerungen von Lese- zu Lese- oder von Schreib- zu Schreib-Vorgängen in verschiedenen Bankgruppen (t_SC) oder derselben Bankgruppe (t_SCL) sowie auf demselben DIMM (t_SD) und unterschiedlichen DIMMs (t_DD). Da tRDRDSC und tWRWRSC immer auf eins gesetzt sind, besteht keine Notwendigkeit, diese Werte zu ändern.
Nachfolgend das 3200er Manuelle Setting. Da es sich hier um S8B ICs handelt, gehen sehr straffe Timings. Genutzt wurden 1.50v, dies ist für S8B auch kein unüblicher OC Wert. Die hier gesetzten manuellen Timings werden dann auch bei der Evaluierung der einzelnen Timings genutzt. Das gesamte Setting bekommt bei der Auswertung aber natürlich auch einen Platz.
Als Bonus gibts noch ein 3800er Setting, welches aber natürlich mit 1900 MHz FCLK läuft.
Wichtig hier zu erwähnen: Ich habe versucht eine ähnliche ns Zeit der Timings zu erreichen, sodass der Fokus auf der Taktrate liegt.
Soviel erstmal zu den genutzten RAM Settings und der Aufteilung der Timings in ihre Sets.
Wie angesprochen werde ich verschiedene Settings und einzelne Timing(-blöcke) miteinander vergleichen.
Kleine Randinformation: Es gibt pro Taktstufe übrigens mehrere JEDEC Settings, nur nur eins
Entschuldigt bitte die unhomogenen Tabellenstrukturen, ich bekomme das hier im Forum nicht schön formatiert.
Als erstes das JEDEC 3200AA Setting:
| Timing | Cycles | Time | Timing | Cycles | Time |
| tCL | 22 | 13.75 ns | tRDWR* | 12 | 7.50 ns |
| tRCD (RD/WR) | 22 | 13.75 ns | tWRRD* | 8 | 5.00 ns |
| tRP | 22 | 13.75 ns | tRDRDSCL* | 5 | 3.125 ns |
| tRAS | 52 | 32.50 ns | tRDRDSC* | 1 | 0.625 ns |
| tRC | 74 | 46.25 ns | tRDRDSD* | 5 | 3.125 ns |
| tRRDS | 4 | 2.50 ns | tRDRDDD* | 4 | 2.50 ns |
| tRRDL | 8 | 5.00 ns | tWRWRSCL* | 5 | 3.125 ns |
| tFAW | 34 | 21.25 ns | tWRWRSC* | 1 | 0.625 ns |
| tRFC | 560 | 350.00 ns | tWRWRSD* | 7 | 4.375 ns |
| tWTRS | 4 | 2.50 ns | tWRWRDD* | 6 | 3.75 ns |
| tWTRL | 12 | 7.50 ns | |||
| tWR | 24 | 15.0 ns | |||
| tCWL | 18 | 11.25 ns | |||
| tRTP | 12 | 7.50 ns | |
Als nächstes das 3200er XMP Setting:
| Timing | Cycles | Time | Timing | Cycles | Time |
| tCL | 16 | 10.00 ns | tCWL** | 16 | 12.50 ns |
| tRCD (RD/WR) | 18 | 11.25 ns | tRTP* | 12 | 7.50 ns |
| tRP | 18 | 11.25 ns | tRDWR** | 12 | 7.50 ns |
| tRAS | 38 | 23.75 ns | tWRRD** | 8 | 5.00 ns |
| tRC | 75 | 46.88 ns | tRDRDSCL** | 5 | 3.13 ns |
| tRRDS* | 4 | 2.50 ns | tRDRDSC** | 1 | 0.63 ns |
| tRRDL* | 8 | 5.00 ns | tRDRDSD** | 5 | 3.13 ns |
| tFAW* | 34 | 24.38 ns | tRDRDDD** | 4 | 2.50 ns |
| tRFC* | 560 | 350.00 ns | tWRWRSCL** | 5 | 3.13 ns |
| tWTRS* | 4 | 2.50 ns | tWRWRSC** | 1 | 0.63 ns |
| tWTRL* | 12 | 7.50 ns | tWRWRSD** | 7 | 4.38 ns |
| tWR* | 24 | 15.0 ns | tWRWRDD** | 6 | 3.75 ns |
* JEDEC Timings, ** Automatisch gesetzt
Kommen wir zum interessanten Teil und den Kern der Bachelorarbeit.
Es geht darum, zu evaluieren wie einzelne Timings skalieren, daher habe ich "Timing-Sets" erstellt in denen einzelne Timings vorhanden sind oder Timings die funktional zusammen gehören.
Die Einteilung der Timings folgt dieser Tabelle:
tCL | tRCDWR | tRP | tRRDS | tWR | tRFC | tWTRS | tRDRDSCL |
tCWL | tRCDRD | tRAS | tRRDL | tRTP | | tWTRL | tRDRDSD |
| | tRC | tFAW | | | tRDWR | tRDRDDD |
| | | | | | tWRRD | tWRWRSCL |
| | | | | | | tWRWRSD |
| | | | | | | tWRWRSD |
- tRCDWR/RD ist das Zeitintervall zwischen ACT und dem Lese- oder Schreibvorgang in derselben Zeile.
- tRC ist die schnellste Zeit bis zu ACT und PRE in derselben Zeile, also entspricht sie tRP + tRAS.
- tFAW bezeichneten das Zeitfenster in der vier ACT-Befehle ausgegeben werden, wobei die ACT-Befehle direkt aufeinander folgen und jeweils durch tRRD voneinander getrennt sind. Somit bilden tFAW und tRRD (S, L) eine Einheit.
- tWR und tRP gehören zu einer Gruppe, da sie die Zeit zwischen einem Schreib- oder Lesevorgang und PRE beschreiben.
- tRFC als Refresh Timing bleibt einzeln
- tWTR (S, L) und tWRRD sowie tRDWR sind hingegen die Umschaltzeiten zwischen Lese- und Schreibvorgang bzw. zwischen Schreib- und Lesevorgang und werden daher zusammen gefasst
- tRDRD_- und tWRWR_-Operationen, sind die die Verzögerungen von Lese- zu Lese- oder von Schreib- zu Schreib-Vorgängen in verschiedenen Bankgruppen (t_SC) oder derselben Bankgruppe (t_SCL) sowie auf demselben DIMM (t_SD) und unterschiedlichen DIMMs (t_DD). Da tRDRDSC und tWRWRSC immer auf eins gesetzt sind, besteht keine Notwendigkeit, diese Werte zu ändern.
Nachfolgend das 3200er Manuelle Setting. Da es sich hier um S8B ICs handelt, gehen sehr straffe Timings. Genutzt wurden 1.50v, dies ist für S8B auch kein unüblicher OC Wert. Die hier gesetzten manuellen Timings werden dann auch bei der Evaluierung der einzelnen Timings genutzt. Das gesamte Setting bekommt bei der Auswertung aber natürlich auch einen Platz.
Timing | Cycles | Time | Timing | Cycles | Time |
tCL | 13 | 8.13 ns | tCWL | 12 | 7.50 ns |
tRCD | 14 | 8.75 ns | tRTP | 6 | 3.75 ns |
tRP | 14 | 8.75 ns | tRDWR | 10 | 6.25 ns |
tRAS | 21 | 13.13 ns | tWRRD | 2 | 1.25 ns |
tRC | 34 | 21.25 ns | tRDRDSCL | 2 | 1.25 ns |
tRRDS | 4 | 2.50 ns | tRDRDSC | 1 | 0.63 ns |
tRRDL | 4 | 2.50 ns | tRDRDSD | 4 | 2.50 ns |
tFAW | 16 | 10.00 ns | tRDRDDD | 2 | 1.25 ns |
tRFC | 216 | 135.00 ns | tWRWRSCL | 2 | 1.25 ns |
tWTRS | 4 | 2.50 ns | tWRWRSC | 1 | 0.63 ns |
tWTRL | 8 | 5.00 ns | tWRWRSD | 6 | 3.75 ns |
tWR | 12 | 7.50 ns | tWRWRDD | 3 | 1.88 ns |
Als Bonus gibts noch ein 3800er Setting, welches aber natürlich mit 1900 MHz FCLK läuft.
Wichtig hier zu erwähnen: Ich habe versucht eine ähnliche ns Zeit der Timings zu erreichen, sodass der Fokus auf der Taktrate liegt.
| Timing | Cycles | Time | Timing | Cycles | Time |
| tCL | 15 | 7.89 ns | tCWL | 14 | 7.37 ns |
| tRCD | 16 | 8.42 ns | tRTP | 7 | 3.68 ns |
| tRP | 15 | 7.89 ns | tRDWR | 12 | 6.32 ns |
| tRAS | 25 | 13.16 ns | tWRRD | 3 | 1.58 ns |
| tRC | 40 | 21.05 ns | tRDRDSCL | 3 | 1.58 ns |
| tRRDS | 5 | 2.62 ns | tRDRDSC | 1 | 0.53 ns |
| tRRDL | 5 | 2.62 ns | tRDRDSD | 5 | 2.63 ns |
| tFAW | 20 | 10.53 ns | tRDRDDD | 3 | 1.58 ns |
| tRFC | 257 | 135.26 ns | tWRWRSCL | 3 | 1.58 ns |
| tWTRS | 5 | 2.62 ns | tWRWRSC | 1 | 0.53 ns |
| tWTRL | 10 | 5.26 ns | tWRWRSD | 7 | 3.68 ns |
| tWR | 14 | 7.36 ns | tWRWRDD | 4 | 2.11 ns |
V. Ergebnisse mit Timing-Analyse
Kommen wir nach all dem Gelaber nun endlich mal zu etwas handfestem mit dem man auch was anfangen kann
Und damit es nicht nur Balken sind, gibts zu jedem Benchmark auch eine Analyse
AIDA Photoworxx:
Das XMP-Profil ändert lediglich die Haupt-Timings auf 16-18-18-38-75 und zeigt damit, dass bereits diese Anpassungen allein einen messbaren Einfluss auf die Performance haben - insbesondere wenn wir uns ansehen wie tCL auf 13, tRCD auf 14, tRP auf 14, tRAS auf 21 und tRC auf 34 abschneiden mit manuellen Settings. Da tRP, tRAS und tRC einen größeren Einfluss haben als tCL und tRRD_, lässt sich schlussfolgern, dass dieser Benchmark besonders viele Precharge- und Activate-Befehle enthält und weniger von Row-to-Row-Delays abhängt. Dasselbe zeigt sich beim tRTP- und tWR-Timing, die von 12 auf 6 beziehungsweise von 24 auf 12 reduziert wurden. Ebenfalls deutlich ins Gewicht fallen die Read-to-Read- und Write-to-Write-Timings, was darauf hindeutet, dass der Benchmark intensiven Gebrauch von Read-to-Read- und Write-to-Write-Befehlen macht. Auch die Refresh-Zeit tRFC hat einen spürbaren Einfluss - was nicht überrascht, da der RAM seinen obligatorischen Refresh alle 7.800 ns durchführen muss (tREFI, nicht veränderbar), der dabei statt 350 ns nur noch 135 ns in Anspruch nimmt. In der gewonnenen Zeit kann der RAM stattdessen produktive Arbeit leisten.
Werden alle Timings gleichzeitig optimiert, ergibt sich bei diesem Workload ein Performancegewinn von 18,5 % - etwas weniger, als die Summe der Einzelgewinne erwarten ließe. Das lässt sich damit erklären, dass nicht alle Timings gleichermaßen von den reduzierten Latenzen der jeweils anderen profitieren. Die Erhöhung der Datenrate bringt bei nahezu gleichen Timings in Nanosekunden einen weiteren deutlichen Sprung. Dieser ist jedoch nicht allein auf die höhere Datenrate zurückzuführen: Bei 3.800 MT/s wird der FCLK auf 1.900 MHz angehoben - statt der 1.600 MHz, die bei 3.200 MT/s den Bandbreitenengpass darstellen. Ein höherer Wert ist daher keine Überraschung.
AIDA Copy:
Die AIDA-Copy-Werte verhalten sich ähnlich wie beim Photoworxx-Benchmark, was bedeutet, dass XMP und die Haupt-Timings - mit Ausnahme von tRP, tRAS und tRC - dasselbe Muster zeigen. Der Copy-Benchmark ist also weniger stark von den Precharge-Timings abhängig als Photoworxx. tRTP und tWR stützen diese These: Ihr Gewinn ist zwar messbar, fällt im Vergleich zu JEDEC aber deutlich geringer aus als beim vorherigen Benchmark.
Ein anderes Bild zeigen die Turnaround-Timings tWTR_, tRDWR und tWRRD, die hier einen deutlich größeren Einfluss haben. Das ist wenig überraschend, denn beim Kopieren von Daten werden zwangsläufig sowohl Lese- als auch Schreibzugriffe benötigt - diese Timings sind also entscheidend für hohe Performance. Dasselbe gilt für die Read-to-Read- und Write-to-Write-Timings tRDRD_ und tWRWR_, die den MB/s-Wert um rund 12,8 % steigern und damit den größten Einzeleinfluss auf die Performance haben. Daher fällt der Gesamtgewinn beim 3.200-MT/s-Setting mit allen Timings im Vergleich zu Photoworxx größer aus - eben weil diese Timings hier stärker ins Gewicht fallen.
Für das 3.800-MT/s-Setting gilt dieselbe Erklärung wie zuvor: Der Gewinn ergibt sich aus dem Zusammenspiel von höherer Datenrate einerseits und gesteigertem FCLK andererseits.
AIDA Latency:
Der AIDA-Latenz-Test unterscheidet sich deutlich von den beiden vorherigen Benchmarks. Precharge- und Activate-Timings spielen hier eine weitaus geringere Rolle, und auch die Turnaround-Timings wie tWTR_ sowie die Read-to-Read- und Write-to-Write-Timings haben nahezu keinen Einfluss auf die Latenz. Gleiches gilt für das Row-to-Row-Timing tRRD_, dessen Wirkung ebenfalls vernachlässigbar ist.
Den größten Einfluss zeigen stattdessen das Column-Timing tCL, das Row-to-Column-Timing tRCD sowie das Refresh-Timing tRFC. Das deutet darauf hin, dass der Algorithmus vorwiegend Row-to-Column-Zugriffe durchführt und kaum Row-to-Row-Zugriffe. Da die Turnaround-Timings kaum ins Gewicht fallen und kein Wechsel zwischen Lese- und Schreibzugriffen erkennbar ist, dürfte es sich ausschließlich um Lese- oder Schreibbefehle handeln. Darüber hinaus legt der Vergleich mit pChase Sequential, der zu nahezu identischen Ergebnissen führt, nahe, dass es sich um sequenzielle und nicht um zufällige Zugriffsmuster handelt.
Auffällig ist außerdem, dass das 3.800-MT/s-Setting im Vergleich zu Photoworxx und Copy keinen entsprechend großen Performancesprung liefert. Eine mögliche Erklärung: Der FCLK begrenzt bei den vorherigen Tests primär die Bandbreite, hat auf die Latenz jedoch einen deutlich geringeren Einfluss. Diese These wird auch durch die pChase-Ergebnisse gestützt.
Microbenchmarks Bandbreite (Read und Write):
Der erste Nicht-AIDA-Benchmark wird in Lese- und Schreibwerte aufgeteilt. Wie zuvor zeigt XMP eine leichte Performanceverbesserung - was, gemessen an den bisherigen Ergebnissen, darauf hindeutet, dass die einzelnen Haupt-Timings einen mittleren Einfluss haben sollten. Und genau das bestätigen die Messwerte. Das kombinierte XMP-Profil mit mehreren optimierten Haupt-Timings schneidet dabei etwas besser ab als die einzeln reduzierten Timings.
Interessant ist, dass der Schreibwert von tCL geringer ausfällt als der von tRCD oder tRRD_. Eine mögliche Erklärung: Der Schreibpfad ist stärker von Row-to-Column- und Row-to-Row-Zugriffen abhängig, während der Lesepfad in dieser Hinsicht weniger empfindlich reagiert. Passend dazu gehören auch die Precharge- und Activate-Timings tRP, tRAS und tRC zu den Timings mit dem größten Performancegewinn - was die Theorie stützt, dass viele kleine Transaktionen stattfinden und keine wenigen großen.
Wie schon mehrfach zuvor hat das Refresh-Timing tRFC den größten Einzeleinfluss auf die Performance: Kürzere Refresh-Zyklen bedeuten schlicht mehr Nutzzeit für den RAM. Nur eine Timing-Gruppe übertrifft diesen Effekt noch - wenig überraschend die Read-to-Read- und Write-to-Write-Timings, was angesichts der rein konsekutiven Lese- und Schreibzugriffe in diesem Benchmark zu erwarten war. Ebenfalls keine Überraschung: Das 3.800-MT/s-Setting mit allen Timings belegt den ersten Platz, knapp vor dem 3.200-MT/s-Setting mit allen Timings.
pChase Bandbreite (Random und Sequentiell):
Der pChase-Benchmark (Pointer Chase) unterteilt sich in zufällige und sequenzielle Zugriffe, jeweils mit Messung von Bandbreite und Latenz. Ein interessantes Ergebnis zeigt sich beim Vergleich des XMP-Gewinns mit den Einzelwerten von tCL/tCWL sowie tRP, tRAS und tRC. In allen bisherigen Benchmarks lieferte das XMP-Profil - das alle Haupt-Timings auf 16-18-18-36-75 setzt - einen größeren Performancegewinn als die einzeln optimierten Timings. Hier dreht sich dieses Bild: Die genannten Timing-Gruppen übertreffen XMP jeweils für sich genommen, und auch tRCD kommt dem XMP-Wert sehr nahe. Selbst tRRD und tFAW liegen nah an den XMP-Ergebnissen.
Das deutet darauf hin, dass der pChase-Benchmark besonders viele kurze Row-to-Row- und Column-to-Row-Zugriffe mit zahlreichen Precharge- und Activate-Befehlen durchführt - vor allem beim Random Read, wo Row-to-Row-Zugriffe dominieren. Außerdem dürften Lesezugriffe deutlich häufiger sein als Schreibzugriffe: Die geringen Gewinne bei tRTP und tWR sowie bei den Turnaround-Timings tWTR, tRDWR und tWRRD sprechen dafür, dass kaum Wechsel zwischen Lese- und Schreibzugriffen stattfinden. Die Read-to-Read- und Write-to-Write-Timings bringen ebenfalls noch einen leichten Zugewinn.
Anders als in den vorherigen Benchmarks fällt der Einfluss des Refresh-Befehls solide, aber weniger ausgeprägt aus. Eine mögliche Erklärung ist die kurze Testdauer dieses Benchmarks, bei der das Refresh-Intervall seine Stärken nicht vollständig ausspielen kann. Das bessere Abschneiden des 3.800-MT/s-Settings gegenüber 3.200 MT/s ist wenig überraschend: Hier addieren sich der FCLK-bedingte Bandbreitengewinn und die generell höhere Datenrate zu einem insgesamt deutlichen Vorsprung.
pChase Latenz (Random und Sequentiell):
Die Latenzmessungen zeigen, dass der prozentuale Performancegewinn die Bandbreitengewinne in den meisten Fällen sehr gut widerspiegelt. Es gibt jedoch zwei Timing-Gruppen, bei denen Bandbreite und Latenz merklich voneinander abweichen: die Turnaround-Timings tWTR, tRDWR und tWRRD beim Random Access mit 0,58 % Bandbreitengewinn, aber nur 0,11 % bei der Latenz - sowie die Read-to-Read- und Write-to-Write-Timings tRDRD und tWRWR mit 2,36 % bei der sequenziellen Bandbreite gegenüber lediglich 0,55 % bei der sequenziellen Latenz. Auffällig ist, dass beide Timing-Gruppen dasselbe Muster zeigen: Der Bandbreitengewinn fällt jeweils deutlich größer aus als der Latenzgewinn. Dieses Verhalten deckt sich mit dem Vergleich zwischen AIDA Copy und AIDA Latenz, wo sich dasselbe Bild gezeigt hat.
Ein weiteres Ergebnis, das sich mit den AIDA-Messungen deckt, liefert der Vergleich zwischen dem 3.200-MT/s- und dem 3.800-MT/s-Setting. Die Random-Bandbreite steigt bei 3.200 MT/s um 16,94 %, während 3.800 MT/s einen Zuwachs von 32,87 % erreicht - das entspricht einem um 90,03 % höheren Gewinn. Bei der Latenz sieht es anders aus: Hier verbessert sich der Wert bei 3.200 MT/s um 14,48 % und bei 3.800 MT/s um 24,73 %, was einem Unterschied von 70,78 % entspricht. Dieses Muster passt zu den bisherigen Ergebnissen und lässt sich wie zuvor erklären: Der FCLK begrenzt die Bandbreite stärker als die Latenz - und da er bei 3.800 MT/s höher getaktet ist, fällt der Bandbreitengewinn entsprechend überproportional aus.
PyPrime im Vergleich zu JEDEC (Reduzierung der Laufzeit in %):
PyPrime ist der erste nicht-synthetische Benchmark in dieser Auswertung und berechnet Pi auf 8 Milliarden Dezimalstellen. Die Ergebnisse werden daher als prozentualer Performancegewinn gegenüber JEDEC verglichen.
Auffällig sind die sehr geringen Gewinne bei den Activate- und Precharge-Timings sowie beim Row-to-Row-Timing tRRD_. Nach der bisherigen Analyse lässt sich daraus schlussfolgern, dass dieser Benchmark mit größeren Datenblöcken arbeitet und entsprechend weniger Precharge- und Activate-Befehle benötigt. Zudem überwiegen Row-to-Column-Zugriffe gegenüber Row-to-Row-Zugriffen. Überraschend ist, dass auch die Turnaround-Timings sowie die Read-to-Read- und Write-to-Write-Timings kaum einen Einfluss haben. Eine plausible Erklärung: Im Gegensatz zu den synthetischen Benchmarks zuvor, die primär den RAM belasten, liegt der Schwerpunkt hier stärker auf der CPU-Rechenleistung - der Speicher ist schlicht nicht der limitierende Faktor.
Diese These wird auch durch den Vergleich zwischen dem 3.200-MT/s- und dem 3.800-MT/s-Setting gestützt: Der Sprung auf 3.800 MT/s bringt hier einen deutlich geringeren Gewinn als in den vorigen Benchmarks. Höhere Datenrate und gesteigerter FCLK-Durchsatz wirken sich auf die reine CPU-Rechenzeit kaum aus.
Avg Fps Zuwachs gegenüber JEDEC (Durchschnitt der drei Spiele):
P0.2 Fps Zuwachs gegenüber JEDEC (Durchschnitt der drei Spiele):
Diese zwei Diagramme zeigen einen der Hauptgründe, warum RAM-Overclocking sowohl für Spiele als auch für Anwendungen relevant ist. Mit Ausnahme der Timing-Gruppe tRTP/tWR verbessern alle Timing-Sets - sowie das Setting mit allen Timings kombiniert - die 0,2%-Low-FPS stärker als die durchschnittliche Framerate. Genau das ist auch der Grund für die weit verbreitete Fehlannahme in zahlreichen Videos und Artikeln: Wer ausschließlich auf die durchschnittliche Framerate schaut, kommt leicht zu dem falschen Schluss, dass RAM-Overclocking den Aufwand nicht lohnt.
Interessant ist außerdem der vergleichsweise geringe Performancegewinn des 3.800-MT/s-Settings gegenüber 3.200 MT/s. Der Hauptgrund dürfte, wie bereits in den vorherigen Ergebnissen angedeutet, der geringere Latenzgewinn sein. Spiele reagieren empfindlicher auf Latenz als auf Bandbreite - das zeigt sich auch beim asynchronen FCLK-Betrieb: Auf der AM4-Plattform lässt sich beispielsweise ein FCLK von 1.633 MHz bei 3.200-MT/s-RAM nutzen, anstelle der synchronen 1.600 MHz. In der Praxis liefert der asynchrone 1.633-MHz-FCLK jedoch schlechtere Gaming-Performance als der synchrone 1.600-MHz-Betrieb, obwohl die Bandbreite höher ist - was verschiedene vergangene Tests auch belegen. Dieses Verhalten erklärt auch die Ergebnisse beider „All Timings"-Settings.
Und damit es nicht nur Balken sind, gibts zu jedem Benchmark auch eine Analyse
AIDA Photoworxx:
Das XMP-Profil ändert lediglich die Haupt-Timings auf 16-18-18-38-75 und zeigt damit, dass bereits diese Anpassungen allein einen messbaren Einfluss auf die Performance haben - insbesondere wenn wir uns ansehen wie tCL auf 13, tRCD auf 14, tRP auf 14, tRAS auf 21 und tRC auf 34 abschneiden mit manuellen Settings. Da tRP, tRAS und tRC einen größeren Einfluss haben als tCL und tRRD_, lässt sich schlussfolgern, dass dieser Benchmark besonders viele Precharge- und Activate-Befehle enthält und weniger von Row-to-Row-Delays abhängt. Dasselbe zeigt sich beim tRTP- und tWR-Timing, die von 12 auf 6 beziehungsweise von 24 auf 12 reduziert wurden. Ebenfalls deutlich ins Gewicht fallen die Read-to-Read- und Write-to-Write-Timings, was darauf hindeutet, dass der Benchmark intensiven Gebrauch von Read-to-Read- und Write-to-Write-Befehlen macht. Auch die Refresh-Zeit tRFC hat einen spürbaren Einfluss - was nicht überrascht, da der RAM seinen obligatorischen Refresh alle 7.800 ns durchführen muss (tREFI, nicht veränderbar), der dabei statt 350 ns nur noch 135 ns in Anspruch nimmt. In der gewonnenen Zeit kann der RAM stattdessen produktive Arbeit leisten.
Werden alle Timings gleichzeitig optimiert, ergibt sich bei diesem Workload ein Performancegewinn von 18,5 % - etwas weniger, als die Summe der Einzelgewinne erwarten ließe. Das lässt sich damit erklären, dass nicht alle Timings gleichermaßen von den reduzierten Latenzen der jeweils anderen profitieren. Die Erhöhung der Datenrate bringt bei nahezu gleichen Timings in Nanosekunden einen weiteren deutlichen Sprung. Dieser ist jedoch nicht allein auf die höhere Datenrate zurückzuführen: Bei 3.800 MT/s wird der FCLK auf 1.900 MHz angehoben - statt der 1.600 MHz, die bei 3.200 MT/s den Bandbreitenengpass darstellen. Ein höherer Wert ist daher keine Überraschung.
AIDA Copy:
Die AIDA-Copy-Werte verhalten sich ähnlich wie beim Photoworxx-Benchmark, was bedeutet, dass XMP und die Haupt-Timings - mit Ausnahme von tRP, tRAS und tRC - dasselbe Muster zeigen. Der Copy-Benchmark ist also weniger stark von den Precharge-Timings abhängig als Photoworxx. tRTP und tWR stützen diese These: Ihr Gewinn ist zwar messbar, fällt im Vergleich zu JEDEC aber deutlich geringer aus als beim vorherigen Benchmark.
Ein anderes Bild zeigen die Turnaround-Timings tWTR_, tRDWR und tWRRD, die hier einen deutlich größeren Einfluss haben. Das ist wenig überraschend, denn beim Kopieren von Daten werden zwangsläufig sowohl Lese- als auch Schreibzugriffe benötigt - diese Timings sind also entscheidend für hohe Performance. Dasselbe gilt für die Read-to-Read- und Write-to-Write-Timings tRDRD_ und tWRWR_, die den MB/s-Wert um rund 12,8 % steigern und damit den größten Einzeleinfluss auf die Performance haben. Daher fällt der Gesamtgewinn beim 3.200-MT/s-Setting mit allen Timings im Vergleich zu Photoworxx größer aus - eben weil diese Timings hier stärker ins Gewicht fallen.
Für das 3.800-MT/s-Setting gilt dieselbe Erklärung wie zuvor: Der Gewinn ergibt sich aus dem Zusammenspiel von höherer Datenrate einerseits und gesteigertem FCLK andererseits.
AIDA Latency:
Der AIDA-Latenz-Test unterscheidet sich deutlich von den beiden vorherigen Benchmarks. Precharge- und Activate-Timings spielen hier eine weitaus geringere Rolle, und auch die Turnaround-Timings wie tWTR_ sowie die Read-to-Read- und Write-to-Write-Timings haben nahezu keinen Einfluss auf die Latenz. Gleiches gilt für das Row-to-Row-Timing tRRD_, dessen Wirkung ebenfalls vernachlässigbar ist.
Den größten Einfluss zeigen stattdessen das Column-Timing tCL, das Row-to-Column-Timing tRCD sowie das Refresh-Timing tRFC. Das deutet darauf hin, dass der Algorithmus vorwiegend Row-to-Column-Zugriffe durchführt und kaum Row-to-Row-Zugriffe. Da die Turnaround-Timings kaum ins Gewicht fallen und kein Wechsel zwischen Lese- und Schreibzugriffen erkennbar ist, dürfte es sich ausschließlich um Lese- oder Schreibbefehle handeln. Darüber hinaus legt der Vergleich mit pChase Sequential, der zu nahezu identischen Ergebnissen führt, nahe, dass es sich um sequenzielle und nicht um zufällige Zugriffsmuster handelt.
Auffällig ist außerdem, dass das 3.800-MT/s-Setting im Vergleich zu Photoworxx und Copy keinen entsprechend großen Performancesprung liefert. Eine mögliche Erklärung: Der FCLK begrenzt bei den vorherigen Tests primär die Bandbreite, hat auf die Latenz jedoch einen deutlich geringeren Einfluss. Diese These wird auch durch die pChase-Ergebnisse gestützt.
Microbenchmarks Bandbreite (Read und Write):
Der erste Nicht-AIDA-Benchmark wird in Lese- und Schreibwerte aufgeteilt. Wie zuvor zeigt XMP eine leichte Performanceverbesserung - was, gemessen an den bisherigen Ergebnissen, darauf hindeutet, dass die einzelnen Haupt-Timings einen mittleren Einfluss haben sollten. Und genau das bestätigen die Messwerte. Das kombinierte XMP-Profil mit mehreren optimierten Haupt-Timings schneidet dabei etwas besser ab als die einzeln reduzierten Timings.
Interessant ist, dass der Schreibwert von tCL geringer ausfällt als der von tRCD oder tRRD_. Eine mögliche Erklärung: Der Schreibpfad ist stärker von Row-to-Column- und Row-to-Row-Zugriffen abhängig, während der Lesepfad in dieser Hinsicht weniger empfindlich reagiert. Passend dazu gehören auch die Precharge- und Activate-Timings tRP, tRAS und tRC zu den Timings mit dem größten Performancegewinn - was die Theorie stützt, dass viele kleine Transaktionen stattfinden und keine wenigen großen.
Wie schon mehrfach zuvor hat das Refresh-Timing tRFC den größten Einzeleinfluss auf die Performance: Kürzere Refresh-Zyklen bedeuten schlicht mehr Nutzzeit für den RAM. Nur eine Timing-Gruppe übertrifft diesen Effekt noch - wenig überraschend die Read-to-Read- und Write-to-Write-Timings, was angesichts der rein konsekutiven Lese- und Schreibzugriffe in diesem Benchmark zu erwarten war. Ebenfalls keine Überraschung: Das 3.800-MT/s-Setting mit allen Timings belegt den ersten Platz, knapp vor dem 3.200-MT/s-Setting mit allen Timings.
pChase Bandbreite (Random und Sequentiell):
Der pChase-Benchmark (Pointer Chase) unterteilt sich in zufällige und sequenzielle Zugriffe, jeweils mit Messung von Bandbreite und Latenz. Ein interessantes Ergebnis zeigt sich beim Vergleich des XMP-Gewinns mit den Einzelwerten von tCL/tCWL sowie tRP, tRAS und tRC. In allen bisherigen Benchmarks lieferte das XMP-Profil - das alle Haupt-Timings auf 16-18-18-36-75 setzt - einen größeren Performancegewinn als die einzeln optimierten Timings. Hier dreht sich dieses Bild: Die genannten Timing-Gruppen übertreffen XMP jeweils für sich genommen, und auch tRCD kommt dem XMP-Wert sehr nahe. Selbst tRRD und tFAW liegen nah an den XMP-Ergebnissen.
Das deutet darauf hin, dass der pChase-Benchmark besonders viele kurze Row-to-Row- und Column-to-Row-Zugriffe mit zahlreichen Precharge- und Activate-Befehlen durchführt - vor allem beim Random Read, wo Row-to-Row-Zugriffe dominieren. Außerdem dürften Lesezugriffe deutlich häufiger sein als Schreibzugriffe: Die geringen Gewinne bei tRTP und tWR sowie bei den Turnaround-Timings tWTR, tRDWR und tWRRD sprechen dafür, dass kaum Wechsel zwischen Lese- und Schreibzugriffen stattfinden. Die Read-to-Read- und Write-to-Write-Timings bringen ebenfalls noch einen leichten Zugewinn.
Anders als in den vorherigen Benchmarks fällt der Einfluss des Refresh-Befehls solide, aber weniger ausgeprägt aus. Eine mögliche Erklärung ist die kurze Testdauer dieses Benchmarks, bei der das Refresh-Intervall seine Stärken nicht vollständig ausspielen kann. Das bessere Abschneiden des 3.800-MT/s-Settings gegenüber 3.200 MT/s ist wenig überraschend: Hier addieren sich der FCLK-bedingte Bandbreitengewinn und die generell höhere Datenrate zu einem insgesamt deutlichen Vorsprung.
pChase Latenz (Random und Sequentiell):
Die Latenzmessungen zeigen, dass der prozentuale Performancegewinn die Bandbreitengewinne in den meisten Fällen sehr gut widerspiegelt. Es gibt jedoch zwei Timing-Gruppen, bei denen Bandbreite und Latenz merklich voneinander abweichen: die Turnaround-Timings tWTR, tRDWR und tWRRD beim Random Access mit 0,58 % Bandbreitengewinn, aber nur 0,11 % bei der Latenz - sowie die Read-to-Read- und Write-to-Write-Timings tRDRD und tWRWR mit 2,36 % bei der sequenziellen Bandbreite gegenüber lediglich 0,55 % bei der sequenziellen Latenz. Auffällig ist, dass beide Timing-Gruppen dasselbe Muster zeigen: Der Bandbreitengewinn fällt jeweils deutlich größer aus als der Latenzgewinn. Dieses Verhalten deckt sich mit dem Vergleich zwischen AIDA Copy und AIDA Latenz, wo sich dasselbe Bild gezeigt hat.
Ein weiteres Ergebnis, das sich mit den AIDA-Messungen deckt, liefert der Vergleich zwischen dem 3.200-MT/s- und dem 3.800-MT/s-Setting. Die Random-Bandbreite steigt bei 3.200 MT/s um 16,94 %, während 3.800 MT/s einen Zuwachs von 32,87 % erreicht - das entspricht einem um 90,03 % höheren Gewinn. Bei der Latenz sieht es anders aus: Hier verbessert sich der Wert bei 3.200 MT/s um 14,48 % und bei 3.800 MT/s um 24,73 %, was einem Unterschied von 70,78 % entspricht. Dieses Muster passt zu den bisherigen Ergebnissen und lässt sich wie zuvor erklären: Der FCLK begrenzt die Bandbreite stärker als die Latenz - und da er bei 3.800 MT/s höher getaktet ist, fällt der Bandbreitengewinn entsprechend überproportional aus.
PyPrime im Vergleich zu JEDEC (Reduzierung der Laufzeit in %):
PyPrime ist der erste nicht-synthetische Benchmark in dieser Auswertung und berechnet Pi auf 8 Milliarden Dezimalstellen. Die Ergebnisse werden daher als prozentualer Performancegewinn gegenüber JEDEC verglichen.
Auffällig sind die sehr geringen Gewinne bei den Activate- und Precharge-Timings sowie beim Row-to-Row-Timing tRRD_. Nach der bisherigen Analyse lässt sich daraus schlussfolgern, dass dieser Benchmark mit größeren Datenblöcken arbeitet und entsprechend weniger Precharge- und Activate-Befehle benötigt. Zudem überwiegen Row-to-Column-Zugriffe gegenüber Row-to-Row-Zugriffen. Überraschend ist, dass auch die Turnaround-Timings sowie die Read-to-Read- und Write-to-Write-Timings kaum einen Einfluss haben. Eine plausible Erklärung: Im Gegensatz zu den synthetischen Benchmarks zuvor, die primär den RAM belasten, liegt der Schwerpunkt hier stärker auf der CPU-Rechenleistung - der Speicher ist schlicht nicht der limitierende Faktor.
Diese These wird auch durch den Vergleich zwischen dem 3.200-MT/s- und dem 3.800-MT/s-Setting gestützt: Der Sprung auf 3.800 MT/s bringt hier einen deutlich geringeren Gewinn als in den vorigen Benchmarks. Höhere Datenrate und gesteigerter FCLK-Durchsatz wirken sich auf die reine CPU-Rechenzeit kaum aus.
Avg Fps Zuwachs gegenüber JEDEC (Durchschnitt der drei Spiele):
P0.2 Fps Zuwachs gegenüber JEDEC (Durchschnitt der drei Spiele):
Diese zwei Diagramme zeigen einen der Hauptgründe, warum RAM-Overclocking sowohl für Spiele als auch für Anwendungen relevant ist. Mit Ausnahme der Timing-Gruppe tRTP/tWR verbessern alle Timing-Sets - sowie das Setting mit allen Timings kombiniert - die 0,2%-Low-FPS stärker als die durchschnittliche Framerate. Genau das ist auch der Grund für die weit verbreitete Fehlannahme in zahlreichen Videos und Artikeln: Wer ausschließlich auf die durchschnittliche Framerate schaut, kommt leicht zu dem falschen Schluss, dass RAM-Overclocking den Aufwand nicht lohnt.
Interessant ist außerdem der vergleichsweise geringe Performancegewinn des 3.800-MT/s-Settings gegenüber 3.200 MT/s. Der Hauptgrund dürfte, wie bereits in den vorherigen Ergebnissen angedeutet, der geringere Latenzgewinn sein. Spiele reagieren empfindlicher auf Latenz als auf Bandbreite - das zeigt sich auch beim asynchronen FCLK-Betrieb: Auf der AM4-Plattform lässt sich beispielsweise ein FCLK von 1.633 MHz bei 3.200-MT/s-RAM nutzen, anstelle der synchronen 1.600 MHz. In der Praxis liefert der asynchrone 1.633-MHz-FCLK jedoch schlechtere Gaming-Performance als der synchrone 1.600-MHz-Betrieb, obwohl die Bandbreite höher ist - was verschiedene vergangene Tests auch belegen. Dieses Verhalten erklärt auch die Ergebnisse beider „All Timings"-Settings.
VI. Was ist DRAMSys ?
DRAMSys ist ein flexibles Framework zur Design-Space-Exploration von DRAM-Subsystemen, das auf SystemC TLM-2.0 (Transaction Level Modeling) basiert. Entwickelt wurde es von der Forschungsgruppe Mikroelektronische Systemgestaltung der RPTU Kaiserslautern-Landau, dem Fraunhofer IESE sowie der Computer Engineering Group der JMU Würzburg. Das Projekt ist auf GitHub verfügbar und bietet unter anderem zyklusgenaue Modellierung für DDR3/4, LPDDR4, Wide I/O 1/2, GDDR5/5X/6 und HBM1/2, einen Trace Analyzer zur visuellen und metrikbasierten Ergebnisauswertung sowie gem5-Unterstützung. Zyklusgenaue Modellierung für DDR5, LPDDR5 und HBM3 ist ebenfalls verfügbar - allerdings nur über eine kommerzielle Lizenz
In DRAMSys sind alle Komponenten als SystemC-Module (sc_module) realisiert und über TLM-Sockets miteinander verbunden. Darüber hinaus orientiert sich die Channel-Controller-Architektur von DRAMSys an modernen Hardware-DRAM-Controllern. Verschiedene Policies lassen sich zur Laufzeit konfigurieren, sodass unterschiedliche DRAM-Standards und Channel-Controller-Implementierungen ohne erneutes Kompilieren festgelegt werden können.
DRAMSys modelliert Timing, Stromverbrauch, Thermik und Fehlercharakteristik von DRAM-Bausteinen in hohem Detailgrad. Der Channel Controller muss daher regelmäßig Refresh-Befehle senden und in Leerlaufphasen Power-Down-Operationen einleiten. Da sich die Timing-Anforderungen je nach Standard unterscheiden, setzt DRAMSys für jeden Standard einen eigenen Checker ein.
Wie bereits erwähnt, bringt DRAMSys den Trace Analyzer mit, der die Analysemöglichkeiten für die Design-Space-Exploration von DRAM-Subsystemen deutlich über die üblichen Konsolenausgaben und Textdateien hinaus erweitert. Das Tool visualisiert ein Zeitfenster mit Requests, DRAM-Befehlen und den Aktivitätspegeln aller Banks und gibt System-Designern damit einen detaillierten Einblick in das interne Verhalten des Subsystems sowie in potenzielle Bottlenecks. Die intuitive Oberfläche erlaubt es, auch durch Traces mit Millionen von Requests und den zugehörigen DRAM-Befehlen komfortabel zu navigieren. Zu den gängig analysierten Kennzahlen gehören die Speicherauslastung (Bandbreite), die durchschnittliche Antwortlatenz sowie der prozentuale Anteil der Zeit, den das System im Power-Down-Modus verbringt.
Hier mal ein Beispiel vom Trace Analyzer, wenn ein Refresh ansteht:
Da das Programm in seinen Grundfunktionen kostenlos auf GitHub verfügbar ist, kann ich jedem Enthusiasten einfach mal ans Herz legen: Try it. Kann man schon coole Sachen mit machen.
In DRAMSys sind alle Komponenten als SystemC-Module (sc_module) realisiert und über TLM-Sockets miteinander verbunden. Darüber hinaus orientiert sich die Channel-Controller-Architektur von DRAMSys an modernen Hardware-DRAM-Controllern. Verschiedene Policies lassen sich zur Laufzeit konfigurieren, sodass unterschiedliche DRAM-Standards und Channel-Controller-Implementierungen ohne erneutes Kompilieren festgelegt werden können.
DRAMSys modelliert Timing, Stromverbrauch, Thermik und Fehlercharakteristik von DRAM-Bausteinen in hohem Detailgrad. Der Channel Controller muss daher regelmäßig Refresh-Befehle senden und in Leerlaufphasen Power-Down-Operationen einleiten. Da sich die Timing-Anforderungen je nach Standard unterscheiden, setzt DRAMSys für jeden Standard einen eigenen Checker ein.
Wie bereits erwähnt, bringt DRAMSys den Trace Analyzer mit, der die Analysemöglichkeiten für die Design-Space-Exploration von DRAM-Subsystemen deutlich über die üblichen Konsolenausgaben und Textdateien hinaus erweitert. Das Tool visualisiert ein Zeitfenster mit Requests, DRAM-Befehlen und den Aktivitätspegeln aller Banks und gibt System-Designern damit einen detaillierten Einblick in das interne Verhalten des Subsystems sowie in potenzielle Bottlenecks. Die intuitive Oberfläche erlaubt es, auch durch Traces mit Millionen von Requests und den zugehörigen DRAM-Befehlen komfortabel zu navigieren. Zu den gängig analysierten Kennzahlen gehören die Speicherauslastung (Bandbreite), die durchschnittliche Antwortlatenz sowie der prozentuale Anteil der Zeit, den das System im Power-Down-Modus verbringt.
Hier mal ein Beispiel vom Trace Analyzer, wenn ein Refresh ansteht:
Da das Programm in seinen Grundfunktionen kostenlos auf GitHub verfügbar ist, kann ich jedem Enthusiasten einfach mal ans Herz legen: Try it. Kann man schon coole Sachen mit machen.
VII. DRAMSys4.0 vs reale Hardware
DRAMSys4.0 muss vor der Nutzung konfiguriert werden. Das kann ziemlich kompliziert werden, da man neben diversen (auch AM5 OClern) unbekannten Timings auch noch den Memory Controller konfigurieren muss, also welches Bit welchem Speicherbereich zugewiesen wird (Adress Mapping) und welche Sheduling Policy verfolgt werden soll, sowie auch den DIMM richtig konfigurieren, also die Anzahl an Rows, Columns, Banks, etc. Gerade das Adressmapping hat einen enormen Einfluss. Natürlich muss man auch noch Last erzeugen die Simuliert werden soll, einmal random, einmal sequentiell, und deshalb muss der Load-Generator auch konfiguriert werden, in diesem Fall u.a. auf 95% Read. Das alles hier komplett aufzudröseln würde aber vermutlich zu weit führen, deshalb belassen wir es einfach dabei, dass ihr mir glaubt dass ich das schon richtig eingestellt habe 
(Der Prof hat natürlich auch drüber geschaut
)
Als Vergleich zu DRAMSys4.0 halten die pChase Benchmarks her, da dieser auch speziell sequentiell und random Werte liefert.
Random Bandbreite:
Grundsätzlich zeigen die meisten Timing-Sets bei der Random-Bandbreite dieselbe Tendenz im Performancegewinn - die absoluten Werte zwischen DRAMSys und pChase unterscheiden sich jedoch. Besonders interessant sind zunächst das XMP-Profil und die damit verbundenen Haupt-Timings. Während pChase eine gute und nahezu gleichmäßige Skalierung von XMP, tCL, tCWL, tRCD, tRP, tRAS und tRC zeigt, weicht DRAMSys davon ab: Das XMP-Scaling fällt deutlich schwächer aus, und das tRCD-Scaling ist noch geringer. Row-to-Column-Delays sind im Simulator insgesamt seltener vertreten als im realen System, was das schwache tRCD-Scaling praktisch den XMP-Gewinn neutralisieren lässt. Die übrigen Haupt-Timings skalieren in absoluten Werten ebenfalls schwächer als bei pChase, liegen in der Tendenz aber bei etwa der Hälfte des realen Wertes.
Die Row-to-Row-Timing-Gruppe mit tRRD_ und tFAW deutet auf ein kontinuierliches Öffnen und Schließen von Rows hin - was bei Random Access genau zu erwarten ist, da dort ständig zwischen Rows gewechselt wird. Beide Simulationsumgebungen bestätigen dieses Verhalten. tWR und tRTP liefern in beiden Umgebungen vergleichbare Ergebnisse, während die Turnaround-Timings nicht direkt verglichen werden können: Im realen System wurden tWTRL, tRDWR und tWRRD angepasst, in DRAMSys war nur tWTRL veränderbar. Hinzu kommt, dass DRAMSys mit einem Leseverhältnis von 95 % konfiguriert ist, weshalb diese Timing-Gruppe dort kaum Wirkung zeigt.
Wie schon in den realen Tests hat tRFC einen großen Einfluss auf die pChase-Ergebnisse - DRAMSys bestätigt dieses Verhalten sogar noch deutlicher. Der hohe Gewinn beim kombinierten All-Timings-Setting sowie bei 3.800 MT/s ist wenig überraschend. Der Unterschied zwischen pChase und DRAMSys beim 3.200-MT/s-Setting - wo pChase etwas weniger Gewinn liefert - sowie beim 3.800-MT/s-Setting - wo pChase höher liegt - ist auf den FCLK zurückzuführen: DRAMSys kennt diese Einschränkung nicht, während die AM4-Plattform beim Sprung auf 3.800 MT/s vom höheren FCLK-Takt zusätzlich profitiert.
Random Latenz:
Besonders ins Auge fällt zunächst die enge Korrelation zwischen Bandbreite und Latenz im pChase-Benchmark: Beide Ergebnisse zeigen nahezu denselben prozentualen Gewinn - und genau das ist ein zentraler Aspekt vieler realen Analysen. DRAMSys weicht davon ab, was sich damit erklären lässt, dass der Simulator stets mit einem streng theoretischen, idealen Zugriffsmuster arbeitet - ohne den Einfluss eines Betriebssystems, von Software oder alltäglichen Hintergrundprozessen wie Netzwerkprüfungen, USB-Handling, Antivirenprogrammen und Ähnlichem. DRAMSys liefert damit einen theoretischen Idealwert bei konstant 95 % Lesezugriffen.
Die interessanteste Timing-Gruppe ist hier tRRD_ und tFAW, die mit Abstand den größten Performancegewinn erzielen. Das entspricht der Erwartung: Bei idealem Random Access müssen Rows ständig geöffnet und geschlossen werden, weshalb diese Timings besonders stark ins Gewicht fallen. Wie schon bei den Bandbreiten-Benchmarks unterscheiden sich die Ergebnisse des 3.200-MT/s- und 3.800-MT/s-Settings zwischen pChase und DRAMSys - der Grund ist auch hier der FCLK.
Sequentielle Bandbreite:
Die sequenziellen Benchmarks unterscheiden sich erheblich zwischen DRAMSys und den pChase-Random-Benchmarks. Bei DRAMSys sind die Performancegewinne für nahezu alle Timing-Sets vernachlässigbar - einzige Ausnahme ist der Refresh. Eine mögliche Erklärung liegt im verwendeten Address Mapping, das zunächst alle Columns durchläuft und erst danach die Rows wechselt. Bei konsekutiven sequenziellen Zugriffen beeinflusst das die Timings erheblich. Interessant wäre in diesem Zusammenhang ein Blick auf tCCDL - den Column-to-Column-Delay - der jedoch auf AM4 nicht veränderbar ist und daher möglicherweise einen großen Gewinn verbergen könnte. Die DRAMSys-Abhängigkeitsanalyse zeigt beim JEDEC-Setting eine zeitliche Abhängigkeit von rund 75 % für tCCDS und rund 18 % für tCCDL, beim 3.200-MT/s-All-Timings-Setting verschiebt sich das leicht auf rund 78 % für tCCDS und rund 15 % für tCCDL.
Unabhängig davon hat der Refresh als einziges Timing hier einen messbaren Einfluss - was wenig überrascht, da Refreshes unabhängig vom Zugriffsmuster und vom Address Mapping immer durchgeführt werden müssen. Der Gesamtgewinn des 3.200-MT/s-All-Timings-Settings ergibt sich hauptsächlich aus tCL, tCWL und tRFC, während beim 3.800-MT/s-Setting primär die höhere Datenrate die Bandbreite steigert. Der deutlich abweichende pChase-Befund lässt sich damit erklären, dass pChase mit kleinen, vom Betriebssystem verwalteten Blöcken arbeitet, während DRAMSys größere Blöcke in einem theoretisch idealen Bereich verwendet.
Sequentielle Latenz:
Wie bereits bei den Random-Benchmarks stimmen Latenz und Bandbreite beim sequenziellen pChase-Benchmark auch hier gut überein. Die DRAMSys-Ergebnisse weichen davon etwas ab - die Erklärung ist dieselbe wie zuvor: DRAMSys arbeitet stets mit einem streng theoretischen, idealen Zugriffsmuster ohne OS-Einflüsse.
Eine besonders interessante Timing-Gruppe ist tCL und tCWL. Während die Leselatenz um 4,81 % sinkt, steigt die Schreiblatenz um 17,74 % an. Da ein Lese-Schreib-Verhältnis von 0,95 verwendet wird, ergibt sich als gewichtetes Gesamtergebnis eine durchschnittliche Verbesserung von 1,8 %. Der vergleichsweise schlechte Wert beim All-Timings-Setup lässt sich mit dem schnelleren Refresh erklären: Dadurch gewinnt der Einfluss von tCL und tCWL relativ an Gewicht - was in diesem Fall zu einer Performanceeinbuße führt.
(Der Prof hat natürlich auch drüber geschaut
)Als Vergleich zu DRAMSys4.0 halten die pChase Benchmarks her, da dieser auch speziell sequentiell und random Werte liefert.
Random Bandbreite:
Grundsätzlich zeigen die meisten Timing-Sets bei der Random-Bandbreite dieselbe Tendenz im Performancegewinn - die absoluten Werte zwischen DRAMSys und pChase unterscheiden sich jedoch. Besonders interessant sind zunächst das XMP-Profil und die damit verbundenen Haupt-Timings. Während pChase eine gute und nahezu gleichmäßige Skalierung von XMP, tCL, tCWL, tRCD, tRP, tRAS und tRC zeigt, weicht DRAMSys davon ab: Das XMP-Scaling fällt deutlich schwächer aus, und das tRCD-Scaling ist noch geringer. Row-to-Column-Delays sind im Simulator insgesamt seltener vertreten als im realen System, was das schwache tRCD-Scaling praktisch den XMP-Gewinn neutralisieren lässt. Die übrigen Haupt-Timings skalieren in absoluten Werten ebenfalls schwächer als bei pChase, liegen in der Tendenz aber bei etwa der Hälfte des realen Wertes.
Die Row-to-Row-Timing-Gruppe mit tRRD_ und tFAW deutet auf ein kontinuierliches Öffnen und Schließen von Rows hin - was bei Random Access genau zu erwarten ist, da dort ständig zwischen Rows gewechselt wird. Beide Simulationsumgebungen bestätigen dieses Verhalten. tWR und tRTP liefern in beiden Umgebungen vergleichbare Ergebnisse, während die Turnaround-Timings nicht direkt verglichen werden können: Im realen System wurden tWTRL, tRDWR und tWRRD angepasst, in DRAMSys war nur tWTRL veränderbar. Hinzu kommt, dass DRAMSys mit einem Leseverhältnis von 95 % konfiguriert ist, weshalb diese Timing-Gruppe dort kaum Wirkung zeigt.
Wie schon in den realen Tests hat tRFC einen großen Einfluss auf die pChase-Ergebnisse - DRAMSys bestätigt dieses Verhalten sogar noch deutlicher. Der hohe Gewinn beim kombinierten All-Timings-Setting sowie bei 3.800 MT/s ist wenig überraschend. Der Unterschied zwischen pChase und DRAMSys beim 3.200-MT/s-Setting - wo pChase etwas weniger Gewinn liefert - sowie beim 3.800-MT/s-Setting - wo pChase höher liegt - ist auf den FCLK zurückzuführen: DRAMSys kennt diese Einschränkung nicht, während die AM4-Plattform beim Sprung auf 3.800 MT/s vom höheren FCLK-Takt zusätzlich profitiert.
Random Latenz:
Besonders ins Auge fällt zunächst die enge Korrelation zwischen Bandbreite und Latenz im pChase-Benchmark: Beide Ergebnisse zeigen nahezu denselben prozentualen Gewinn - und genau das ist ein zentraler Aspekt vieler realen Analysen. DRAMSys weicht davon ab, was sich damit erklären lässt, dass der Simulator stets mit einem streng theoretischen, idealen Zugriffsmuster arbeitet - ohne den Einfluss eines Betriebssystems, von Software oder alltäglichen Hintergrundprozessen wie Netzwerkprüfungen, USB-Handling, Antivirenprogrammen und Ähnlichem. DRAMSys liefert damit einen theoretischen Idealwert bei konstant 95 % Lesezugriffen.
Die interessanteste Timing-Gruppe ist hier tRRD_ und tFAW, die mit Abstand den größten Performancegewinn erzielen. Das entspricht der Erwartung: Bei idealem Random Access müssen Rows ständig geöffnet und geschlossen werden, weshalb diese Timings besonders stark ins Gewicht fallen. Wie schon bei den Bandbreiten-Benchmarks unterscheiden sich die Ergebnisse des 3.200-MT/s- und 3.800-MT/s-Settings zwischen pChase und DRAMSys - der Grund ist auch hier der FCLK.
Sequentielle Bandbreite:
Die sequenziellen Benchmarks unterscheiden sich erheblich zwischen DRAMSys und den pChase-Random-Benchmarks. Bei DRAMSys sind die Performancegewinne für nahezu alle Timing-Sets vernachlässigbar - einzige Ausnahme ist der Refresh. Eine mögliche Erklärung liegt im verwendeten Address Mapping, das zunächst alle Columns durchläuft und erst danach die Rows wechselt. Bei konsekutiven sequenziellen Zugriffen beeinflusst das die Timings erheblich. Interessant wäre in diesem Zusammenhang ein Blick auf tCCDL - den Column-to-Column-Delay - der jedoch auf AM4 nicht veränderbar ist und daher möglicherweise einen großen Gewinn verbergen könnte. Die DRAMSys-Abhängigkeitsanalyse zeigt beim JEDEC-Setting eine zeitliche Abhängigkeit von rund 75 % für tCCDS und rund 18 % für tCCDL, beim 3.200-MT/s-All-Timings-Setting verschiebt sich das leicht auf rund 78 % für tCCDS und rund 15 % für tCCDL.
Unabhängig davon hat der Refresh als einziges Timing hier einen messbaren Einfluss - was wenig überrascht, da Refreshes unabhängig vom Zugriffsmuster und vom Address Mapping immer durchgeführt werden müssen. Der Gesamtgewinn des 3.200-MT/s-All-Timings-Settings ergibt sich hauptsächlich aus tCL, tCWL und tRFC, während beim 3.800-MT/s-Setting primär die höhere Datenrate die Bandbreite steigert. Der deutlich abweichende pChase-Befund lässt sich damit erklären, dass pChase mit kleinen, vom Betriebssystem verwalteten Blöcken arbeitet, während DRAMSys größere Blöcke in einem theoretisch idealen Bereich verwendet.
Sequentielle Latenz:
Wie bereits bei den Random-Benchmarks stimmen Latenz und Bandbreite beim sequenziellen pChase-Benchmark auch hier gut überein. Die DRAMSys-Ergebnisse weichen davon etwas ab - die Erklärung ist dieselbe wie zuvor: DRAMSys arbeitet stets mit einem streng theoretischen, idealen Zugriffsmuster ohne OS-Einflüsse.
Eine besonders interessante Timing-Gruppe ist tCL und tCWL. Während die Leselatenz um 4,81 % sinkt, steigt die Schreiblatenz um 17,74 % an. Da ein Lese-Schreib-Verhältnis von 0,95 verwendet wird, ergibt sich als gewichtetes Gesamtergebnis eine durchschnittliche Verbesserung von 1,8 %. Der vergleichsweise schlechte Wert beim All-Timings-Setup lässt sich mit dem schnelleren Refresh erklären: Dadurch gewinnt der Einfluss von tCL und tCWL relativ an Gewicht - was in diesem Fall zu einer Performanceeinbuße führt.
VIII. Fazit
Zu Beginn wurden die wichtigsten DRAM-Mechanismen und Timings vorgestellt. Anschließend wurde das Overclocking-Potenzial von DDR4-RAM anhand von Samsung 8-Gbit-B-Die-Bausteinen analysiert. Dazu kamen verschiedene Timing-Sets - etwa tRP, tRAS und tRC als Gruppe - zum Einsatz, um den Performancegewinn in einer Vielzahl von Anwendungen zu bewerten: AIDA, PyPrime, Microbenchmarks, pChase und einige Spiele. Die einzelnen Tests reagierten unterschiedlich auf die Timing-Sets, wobei das Refresh-Timing in den meisten Fällen den größten Einzeleinfluss hatte. Den mit Abstand größten Performancesprung lieferte erwartungsgemäß die Kombination aller Timings - insbesondere in Verbindung mit einer erhöhten Datenrate. Ohne Änderung der Datenrate wurde ein DDR4-Performancegewinn von bis zu rund 29 % beobachtet, mit höherer Datenrate und gesteigertem FCLK sogar bis zu rund 48 %.
Die DRAMSys4.0-Analyse zeigte sowohl Gemeinsamkeiten als auch Unterschiede im Vergleich zur realen Umgebung mit pChase. Bei Random Access liegt der Bandbreitengewinn in DRAMSys bei rund 19 % für 3.200 MT/s und rund 29 % für 3.800 MT/s - Werte, die gut mit den realen Ergebnissen übereinstimmen. Die Latenzverbesserung fällt in DRAMSys jedoch höher aus als in der Praxis, während die absolute Bandbreite etwas geringer ist. Bei sequenziellem Access weichen die Ergebnisse stärker vom realen Verhalten ab: Sowohl Bandbreite als auch Latenz zeigen in DRAMSys kaum eine Reaktion auf die Timing-Optimierungen.
Insgesamt lässt sich festhalten, dass die gezielte Optimierung von Timings - selbst bei einer für die jeweilige Plattform spezifizierten Datenrate wie 3.200 MT/s für AMD-Ryzen-5000-CPUs - einen erheblichen Performancegewinn mit sich bringen kann, der sich in schnelleren Workflows und effizienteren Arbeitsprozessen niederschlägt. Darüber hinaus eröffnet RAM-Overclocking interessante Möglichkeiten zur Steigerung der Energieeffizienz oder zur Kosteneinsparung: Ein langsamerer oder untertakteter Prozessor lässt sich durch optimierten DRAM-Durchsatz auf das Leistungsniveau eines schnelleren CPUs anheben - oder sogar darüber hinaus.
Die DRAMSys4.0-Analyse zeigte sowohl Gemeinsamkeiten als auch Unterschiede im Vergleich zur realen Umgebung mit pChase. Bei Random Access liegt der Bandbreitengewinn in DRAMSys bei rund 19 % für 3.200 MT/s und rund 29 % für 3.800 MT/s - Werte, die gut mit den realen Ergebnissen übereinstimmen. Die Latenzverbesserung fällt in DRAMSys jedoch höher aus als in der Praxis, während die absolute Bandbreite etwas geringer ist. Bei sequenziellem Access weichen die Ergebnisse stärker vom realen Verhalten ab: Sowohl Bandbreite als auch Latenz zeigen in DRAMSys kaum eine Reaktion auf die Timing-Optimierungen.
Insgesamt lässt sich festhalten, dass die gezielte Optimierung von Timings - selbst bei einer für die jeweilige Plattform spezifizierten Datenrate wie 3.200 MT/s für AMD-Ryzen-5000-CPUs - einen erheblichen Performancegewinn mit sich bringen kann, der sich in schnelleren Workflows und effizienteren Arbeitsprozessen niederschlägt. Darüber hinaus eröffnet RAM-Overclocking interessante Möglichkeiten zur Steigerung der Energieeffizienz oder zur Kosteneinsparung: Ein langsamerer oder untertakteter Prozessor lässt sich durch optimierten DRAM-Durchsatz auf das Leistungsniveau eines schnelleren CPUs anheben - oder sogar darüber hinaus.
Zum Abschluss möchte ich mich an dieser Stelle fürs lesen bedanken.
Ich hoffe ich konnte euch einige interessante Einblicke geben!
Wir lesen uns dann bei der DDR5 Analyse
Zuletzt bearbeitet:
