Baal Netbeck
Fleet Admiral
- Registriert
- Apr. 2008
- Beiträge
- 11.953
Dies ist ein ausgelagertes Thema aus diesem Hauptthread:
https://www.computerbase.de/forum/t...kussion-zu-spieletests.1728575/#post-20678303
Achtung!
Dieser Artikel ist nur eine Ergänzung zu anderen Artikeln, in denen ich die Ergebnisse aus dieser Testreihe analysiere.
Sozusagen ein Anhang mit Rohdaten, für Leute die das interessiert.
Bitte für die Auswertungen in diese Artikel gucken!
Dual ranked vs. single ranked Ram bei Ryzen
Dual Channel vs. single Channel bei Ryzen....folgt noch!
Sind Aufpreis und Timings optimieren es wert? 2933 Cl16 als Vergleich ....folgt noch
In diesem Artikel möchte ich vor allem die neuen Testszenen vorstellen, die Rohdaten präsentieren und grob ein paar Worte zu allen sagen.
Mir ist klar, dass sich die Datenpunkte oft nicht auseinanderhalten lassen. Ich müsste sie in Gruppen darstellen und nicht alle gleichzeitig.
Aber wenn sie sich so nicht auseinander halten lassen, sind die Unterschiede auch nicht relevant.
Auch möchte ich darauf hinweisen dass man einzelne Datenpunkte eigentlich nicht einfach mit Geraden verbinden sollte!
Das habe ich in diesem Fall trotzdem gemacht um die optische Zuordnung der Punkte zu erleichtern.
So sieht man besser, wo die Punkte, hin zu den schlechteren Frametimes, mehr oder weniger verlieren.
Und sind die Linien parallel oder kreuzen sie sich gar, hilft das auch.
Ich möchte nur darauf hinweisen, das man nicht annehemen sollte, das zwischen den Punkten ein linearer Verlauf ist...zumal ich oft Percentile und low Werte abwechselnd darstelle und man diese eigentlich nicht so direkt vergleichen kann.
Testsystem:
Wie ich meine Tests gemacht und verbessert habe:
Spiel Einstellungen:
Die Testsequenzen:
Ashes of the Singularity
Für eine genauere Betrachtung des Spiels, der Benchmarksequenz, die Unterschiede von CPU und GPU Test sowie DX11 v. DX12, bitte in diesen Spieletest schauen:
Ashes of the Singularity
Das Spiel ist schlecht zu testen!
Die Testsequenz dauert extrem lang(3min) und wenn man sie abbricht, muss man erstmal wieder die Spieldateien verifizieren und eine 14,1MB große Datei neu herunterladen...andernfalls stürzt er beim nächsten Benchmark ab.
Dann schwanken die Messungen zufällig hin und her. Mal hat man 50FPs dann 48 dann wieder 48 dann wieder 50...es ist undurchsichtig und dubios. Ich dachte erst es würde an dem Aufheizen meiner Wasserkühlung liegen aber es ist völlig zufällig.
Da die Unterschiede der Ram Konstellationen so deutlich sind werden trotzdem brauchbare Ergebnisse daraus.
DR profitiert gut, jedoch nicht bei den Frametimes und 3200MHz.
SC Betrieb kostet viel Leistung, jedoch besonders viel bei 2133.
Cities Skylines
Für eine genauere Betrachtung des Spiels, der Benchmarksequenz, usw. bitte in diesen Spieletest schauen:
Cities Skylines
Ich habe jedoch die Testdauer von 40 auf 50s angehoben um eine bessere Statistik für die 0.1% low Werte zu erhalten.
DR und SR Ram liegen gleichauf.
der SC betrieb kostet etwas Leistung.
2933 Cl16 liegen im Mittelfeld.
Company of Heroes 2
Ein Neuzugang bei meinen Spieletests, der nicht bleiben wird.
Das Spiel ist eigentlich ganz cool. Macht man AA runter ist es auch CPU limitiert und der integrierte Benchmark zeigt eine zum Spielgeschehen passende performance.
Es profitiert auch von mehr als 4 Kernen usw.
Leider ist es furchtbar unzuverlässig zu messen.
Es gibt in unregelmäßigen Abständen Rukler, die ich nicht in den Griff bekommen habe. Ich musste daher extrem oft messen und extrem viel Aussortieren.
Für eine bessere Reproduzierbarkeit habe ich für die Ram Tests nur die Thread 0 bis 7 zugewiesen. Es wird damit besser aber nicht gut^^
Der Vergleich von DR zu SR ist kaum relevant.
Der Wechsel zu SC kostet kaum Leistung und das auch nur bei 2133. Bei 3200 scheint die Bandbreite bereits gut genug zu sein.
Heroes of the Storm
Bitte in diesen Test gucken:
Heroes of the Storm
Für eine bessere Reproduzierbarkeit habe ich für die Ram Tests nur die Thread 0 2 4 und 6 zugewiesen.
Die Unterschiede bei DR zu SR sind gering aber die gute Reproduzierarkeit macht es wieder wett.
SC kostet nur wenig Leistung und 2933 sind mal wieder in der Mitte.
Hitman: Marrakesh
Die früheren Tests zu Hitman die ich gemacht habe, sind bei ausreichend CPU/Ram Power in ein FPS limit gelaufen.
Inzwischen wurde dieses Limit weg gepatcht und das Spiel zeigt endlich zu was die Engine in der Lage ist.
16 Threads bis zu 50% auszulasten ist schon ganz ordentlich.
Ich bin auch von der Szene in Paris auf die Szene in Marakesh gewechselt, weil hier noch mehr NPCs rumlaufen und die CPU Last noch etwas höher ist.
Es zeigen sich gute Vorteile für DR Ram und große Nachteile für eine SC Konfiguration.
Das Spiel liebt scheinbar Ram Bandbreite.
Prison Architect(64bit)
Siehe diesen Test:
Prison Architect
Für eine bessere Reproduzierbarkeit habe ich für die Ram Tests nur die Thread 0 2 4 und 6 zugewiesen.
Bei 3200 DR brechen die Frametimes stärker ein als für SR Ram.
Bei 2133 gewinnt DR jedoch.
Der SC Betrieb verliert deutlich.
293 ist wieder im Mittelfeld.
Rome TW: Barbarian Invasion
Auch dieses Spiel habe ich früher schon getestet:
Rome TW: Barbarian Invasion
Ich bin jedoch nicht so sehr mit der Reproduzierbarkeit zufrieden.
Ab und zu stirbt ein General in den 60s Test.
Manchmal schwingt das Schlachtenglück extremer zu einer Seite....und mal ist einfach der Wurm drin.
Zusätzlich sind die FPS so gering, das in den 60s unter 2000 Frames gerendert werden.
die 0.1% sind also nur der schlechteste Frame und gleich mit den P99.9
Ich konnte dieLeistung verbessern und die Ergebnisse stabilisieren, indem ich dem Spieleprozess nur die Threads 0 und 1 zuweise.
Ich habe schon früher festgestellt, dass sich das Spiel zwar gut für CPU Takt aber so gut wie nicht für Ram interessiert.
Daher sind die Unterschiede sehr klein und sehr schwer zu messen.
Grob gesagt is schnellerer Ram jedoch trotzdem besser.
Rise of the Tomb Raider
Ein schönes Spiel, das je nach Situation von vielen und schnellen CPU Kernen profitiert und auch Ram mag.
Sonst jedoch eher GPU limitiert ist.
Siehe dieser Test:
Rise of the Tomb Raider
Da das Spiel überwiegend GPU limitiert läuft(zumindest mit 8 Kernen) zeigen die avg FPS kaum Unterschiede.
Man sieht jedoch wie sich bei den Frametimes die Spreu vom Weizen trennt.
Die Unterschiede werden größer. Vor allem der SC bricht deutlich ein.
Und das vor allem bei 2133, hier scheint die Bandbeite besonders zu limitieren.
Starcraft 2
Auch hier möchte ich auf meine alten Tests verweisen:
Starcraft 2
Für eine bessere Reproduzierbarkeit habe ich für die Ram Tests nur die Thread 0 2 4 und 6 zugewiesen.
DR zu SR ist schwer zu unterscheiden, die gute Reproduziebarkeit macht dies jedoch möglich.
SC, 2933 und generell der Unterschied von 2133 und 3200MHz sind wie zu erwarten.
Thief(vier)
Kein besonderes Spiel aber einfach zu testen, wenn auch nicht super genau.
Thief
Für eine bessere Reproduzierbarkeit habe ich für die Ram Tests nur die Thread 0 2 4 und 6 zugewiesen.
Die Abhängigkeit vom Ram ist hoch.
DR und SR zeigen große Unterschiede, SC bringt starke Nachteile und 2933 liegt mittig.
F1 2015
Ein weiterer Neuzugang:
Ich habe zum Testen kurze 30s ausgewählt, da ich nur bis zu diesem Zeitpunkt eine zuverlässige CPU Last reproduzieen kann.
Ich starte dafür mit schlechtem Wagen in einem Einzelrennen aus der hinteren Reihe. Es stürmt und diverse Fahrhilfen sorgen dafür, das ich problemlos den Wagen steuern kann ohne Skill zu brauchen.
Die Dichte an Gegnern vor einem ist wichtig für die CPU Last. Ich fahre daher in der ersten Kurve immer in eine relativ mittige Position und halte diese dann bis zum Ende der 30 s
Ich war sehr überrascht, wie riesig die Unterschiede sind. Da macht das Testen Spaß!
DR gewinnt deutlich, SC verliert deutlich und das auch bei 3200MHz.
Frostpunk
Kein Spiel dieser Testreihe. Ich habe es mir gekauft als ich mit den anderen Tests schon durch war.
Ich hatte aber viel Spaß es zu spielen, und auch wenn das Spiel von Anfang bis Mitte GPU limitiert läuft, wurde meine CPU gegen Ende zimlich in die Knie gezwungen.
Es verdient eine kurze Vorstellung:
Im Video und in dem Diagram habe ich die Threads wieder auf 0 2 4 und 6 begrenzt.
Sonst hat das Spiel nämlich die böse Angewohnheit zwei Threads des gleichen CPU Kerns stark zu belasten und damit deutlich die Leistung zu drücken.
siehe hier:
The Witcher 2
Auch dies ein alter Bekannter:
The Witcher 2
Für eine bessere Reproduzierbarkeit habe ich für die Ram Tests nur die Thread 0 2 4 und 6 zugewiesen.
Leider ist trotzdem an manchen Tagen einfach der Wurm drin und die Messungen passen nicht zusammen.
Ich musste dieses Spiel viel zu oft messen und oft hat es trotzdem nicht für eine ausreichende Genauigkeit gereicht.
hat man dann alles dutzende Male getestet, ergeben die Messungen durchaus Sinn.
Leider sagen die Fehlerbalken trotzdem Nein zu diesem Test.
Es wird wohl aus meiner Auswahl fliegen^^.
Das was man sieht ist nicht so ungewöhnlich. DR etwas vor SR.
SC ist nur leicht zurück.....und 2933......mittig....wo sonst
The Witcher 3
Auch dies ein alter Bekannter:
The Witcher 3
Trotz fast durchgehendem GPU limit ein interessantes Spiel.
In der Wildnis mag die CPU keine Rolle spielen. In Städten wie Novigrad mit vielen NPCs können CPU Kerne, CPU Takt und Ram jedoch wichtig werden.
Bei 8 Kernen ist das dann eher weniger der Fall.
Nur 2133 mir SC fehlt die nötige Bandbreite und verliert massiv an Leistung.
Zusammenfassung
Ich habe Elex austauschen müssen(startet nicht mehr mit neuen Vega Treibern) und habe es durch COH2 und F1 2015 ersetzt.
COH2 wird wieder rausfliegen aber F1 2015 hat mit gut gefallen.
Meine Bemühungen um noch genauere Ergebnisse waren in den meisten Fällen erfolgreich.
Ich habe aber einen großen Preis in Form von noch mehr investierter Zeit gezahlt.
Einen Satz Messungen für alle Spiele kostet mehrere Stunden ...ich brauche zwei und immer wieder musste ich eine Reihe der Spiele noch ein drittes und viertes mal testen.
Aber das kommt davon, wenn man CPU intensive Szenen sucht und testet.
Ich könnte mir auch langweilige Szenen in den Spielen suchen und würde in einem Bruchteil der Zeit tolle Ergebnisse erhalten.
Nur würde ich dann eben nur da testen wo Spiele eh gut laufen und die Hardware eigentlich keine Rolle spielt.
Ich möchte aber da testen wo es kritisch wird....wo andere Hardware auch deutliche Unterschiede erzeugt.
Im Moment ist nur der Artikel zu DR vs. SR Ram fertig.... der Nächste folgt hoffentlich bald.
Was sind eure Meinungen dazu?
Habt ihr Verbesserungsvorschläge oder wollt ihr besimmte Sachen sehen, die ich hier nicht behandelt habe?
https://www.computerbase.de/forum/t...kussion-zu-spieletests.1728575/#post-20678303
Achtung!
Dieser Artikel ist nur eine Ergänzung zu anderen Artikeln, in denen ich die Ergebnisse aus dieser Testreihe analysiere.
Sozusagen ein Anhang mit Rohdaten, für Leute die das interessiert.
Bitte für die Auswertungen in diese Artikel gucken!
Dual ranked vs. single ranked Ram bei Ryzen
Dual Channel vs. single Channel bei Ryzen....folgt noch!
Sind Aufpreis und Timings optimieren es wert? 2933 Cl16 als Vergleich ....folgt noch
In diesem Artikel möchte ich vor allem die neuen Testszenen vorstellen, die Rohdaten präsentieren und grob ein paar Worte zu allen sagen.
Mir ist klar, dass sich die Datenpunkte oft nicht auseinanderhalten lassen. Ich müsste sie in Gruppen darstellen und nicht alle gleichzeitig.
Aber wenn sie sich so nicht auseinander halten lassen, sind die Unterschiede auch nicht relevant.
Auch möchte ich darauf hinweisen dass man einzelne Datenpunkte eigentlich nicht einfach mit Geraden verbinden sollte!
Das habe ich in diesem Fall trotzdem gemacht um die optische Zuordnung der Punkte zu erleichtern.
So sieht man besser, wo die Punkte, hin zu den schlechteren Frametimes, mehr oder weniger verlieren.
Und sind die Linien parallel oder kreuzen sie sich gar, hilft das auch.
Ich möchte nur darauf hinweisen, das man nicht annehemen sollte, das zwischen den Punkten ein linearer Verlauf ist...zumal ich oft Percentile und low Werte abwechselnd darstelle und man diese eigentlich nicht so direkt vergleichen kann.
Testsystem:
Ein Ryzen 1800X mit Pstate OC auf 3,8GHz. 100.2MHz BCLk(für die optik). Ich musste für die sommerlichen Temperaturen etwas undervolting zurücknehmem und komme unter IBT Last auf 1,3-1,312V.
Asus Crosshair VI Hero @ Bios 6002
Vega64 LC mit custom Wasserkühlung für CPU und GPU. PT+50%, P7 = 1702MHz, 1050mV(resultiert in ca 1610MHz bei 1V),
HBM2@1050MHz, P6 als min gesetzt
2x16GB DR und 2x8GB SR DDR4 mit Samsung B-die
Sämtliche im Bios einstellbaren Timings wurden für die höchste effektive Ram Taktrate des DR Kits optimiert und manuell festgesetzt.
dann für das SR Kit gleich gewählt.
Die Timings für 2933 CL16 habe ich aus verschiedenen Angaben aus dem Internet für Aegis 3000 CL16er Ram entnommen und bei widersprüchlichen Angaben den Mittelwert eingestellt. Die Subtimings sind dabei ganz in Ordnung aber natürlich weit von "optimiert" entfernt....eben das was man bekommt wenn man das docp Profil lädt und es so lässt.
Was mir fehlte war ein SR Kit, das ich mir dann diese Jahr in Form von 2x8GB 3600 CL15 gekauft habe.
Asus Crosshair VI Hero @ Bios 6002
Vega64 LC mit custom Wasserkühlung für CPU und GPU. PT+50%, P7 = 1702MHz, 1050mV(resultiert in ca 1610MHz bei 1V),
HBM2@1050MHz, P6 als min gesetzt
2x16GB DR und 2x8GB SR DDR4 mit Samsung B-die
Sämtliche im Bios einstellbaren Timings wurden für die höchste effektive Ram Taktrate des DR Kits optimiert und manuell festgesetzt.
dann für das SR Kit gleich gewählt.
Die Timings für 2933 CL16 habe ich aus verschiedenen Angaben aus dem Internet für Aegis 3000 CL16er Ram entnommen und bei widersprüchlichen Angaben den Mittelwert eingestellt. Die Subtimings sind dabei ganz in Ordnung aber natürlich weit von "optimiert" entfernt....eben das was man bekommt wenn man das docp Profil lädt und es so lässt.
Was mir fehlte war ein SR Kit, das ich mir dann diese Jahr in Form von 2x8GB 3600 CL15 gekauft habe.
Wie ich meine Tests gemacht und verbessert habe:
Ursprünglich hatte ich für jede Hardwarekonfiguration in jedem Spiel 6 mal hintereinander die Frametimes gemessen.
Dann habe ich die erste Messung("Vormessung") verworfen, da sie in vielen Spielen mit Nachladerucklern zu kämpfen hat und dabei teilweise sogar höhere Durchschnitts-FPS liefert. Ein Mysterium, das ich auf polygonärmere/fehlende Strukturen und schlechtere Texturen schiebe, die bis zum hereinladen der besseren Versionen höhere FPS ermöglichen....oder durch mehr Platz im Cache weil dieser noch nicht so voll ist.....außerdem sind in Spielen, die die GPU stark beanspruchen, kurz nach dem Spielstart die Temperaturen besser und damit der Boost-Takt leicht höher.
Von den fünf verbleibenden Messungen hatte ich mit einem eigenen Auswertungsprogramm die Frametimes über diverse statistische Methoden analysiert.
Um bis zu zwei Ausreißer zu eliminieren bildet das Programm dann nur einen Mittelwert der jeweils besten drei Werte und eine empirische Standardabweichung dieser drei.
Ich denke, dass diese Methode bereits deutlich bessere Ergebnisse lieferte als die der meisten anderen CPU/Ram orientierten Spieletests.
Jedoch musste ich herausfinden, dass die Reproduzierbarkeit trotzdem nicht gut genug für meine Ansprüche war.
Bei den älteren Tests, wo ich Ryzen gegen einen ivy i5 oder 2133 gegen 3200MhzRam getestet habe, waren die Abstände in der Regel deutlich genug um Unterschiede klar zu erkennen.
Lediglich mein Versuch mit einer 2+2 gegen eine 4+0 Konfiguration des Ryzen bei unterschiedlichen Ram Frequenzen die Einflüsse des IF zu untersuchen scheiterte an der Genauigkeit.
Nun sollte es also deutlich genauer werden!
Also habe ich mein Programm erweitert um einen zweiten Satz von 5 Frametime Messungen einlesen und verarbeiten zu können.
Das Programm wertet beide Messungen erst getrennt voneinander aus, so wie schon vorher, und dann nimmt es aus beiden, jeweils die 3 Besten und kombiniert diese.
Es werden jetzt also von 10 Messungen, der Mittelwert von 6 Auserwählten gebildet.
Was sich dabei gezeigt hat, ist wie oft die Messungen einen systematischen Fehler bekommen. Auch wenn die einzelnen Messreihen in sich eine geringe statistischen Schwankung haben, können sie von Tag zu Tag merklich abweichen. Teils sogar sehr deutlich.
Ich bin auf Ursachenforschung gegangen und habe die verschiedenen Spiele mit aktivem OSD getestet. Habe festgestellt, dass das OSD selbst schon überraschend viel Leistung zieht...egal.... es ist bei den späteren Messungen aus.
Es war aber weiterhin schwer die teils einige % betragenden Abweichungen zu ergründen.
Bei einigen Spielen hat die Arbeit des Schedulers den Ausschlag gegeben. Manchmal wurde die Last auf einzelnen Kernen festgehalten...am nächsten Tag eher hin und her geschoben.....dann haben einige Spiele einzelne Kerne überlastet, indem zwei Threads des gleichen CPU Kerns gleichzeitig stark belastet wurden.
Mal wurden Threads des gleichen CCX benutzt und mal gemischt.
Kurz gesagt macht der Windows Scheduler, (vor allem bei älteren Spielen) einen miesen Job auf Ryzen CPUs!
Um dies reproduzierbarer zu machen, habe ich in allen Spielen, die nur wenige Threads benutzen die zugewiesenen CPU-Threads angepasst.
Heroes of the Storm, Starcraft 2, Prison Architect, The Witcher 2, Thief und Frostpunk wurden nur die Threads 0, 2, 4 und 6 zugewiesen.
Also nur 4 echte Kerne eines CCX. Keine Inter-core-Kommunikation über den Infinity Fabric und keine Probleme mit SMT.
Rome TW habe ich die Threads 0 und 1 zugewiesen, also beide Threads des gleichen Kerns und Company of Heroes hat alle Threads eines CCX bekommen also 0-7...auch wenn es besser läuft mit mehr Kernen und ohne SMT.
Ich versuche den Großteil meiner Tests im CPU limit zu machen und da versucht meine Vega64 natürlich Strom zu sparen und niedrigere PStates zu nutzen. Leider schätzt sie die Last immer mal unterschiedlich ein und taktet dann unterschiedlich weit runter und geht auch beim HBM2 mal auf 500MHz und mal nicht.
Um diese Verhalten zu stabilisieren, habe ich für die Benchmarks den P6 als niedrigsten PState festgelegt.
Da die Karte wassergekühlt ist, kommt sie nie in Situationen, wo sie zu heiß läuft. Da die Taktrate aber die Temperatur als ständigen Faktor in die Berrechnung einbezieht, kann ich nicht ausschließen, das der Takt von Messung zu Messung weiterhin leicht unterschiedlich ist. Die Unterschiede sind aber gering und werden im CPU limit keine Rolle spielen.
Ein weiterer Punkt bei Ryzen ist der "sleep-Bug". Etwas das beim Wechsel in den Standby oder auch beim Herunterfahren unter Windows 10 passieren kann. Danach läuft der Timer falsch und da Frametimemessungen Zeitmessungen sind, fallen die Ergebnisse falsch aus.
Um dem vorzubeugen, habe ich den PC jeweils erst aus und wieder an gemacht und dann noch einen Neustart hinterhergeschoben.
Das an/aus bietet eine gleiche Ausgangsbasis und der Neustart behebt einen eventuell auftretenden Sleep Bug.
Interessanterweise konnte ich mehrere Male feststellen, das nach dem Prozedere die Messungen typische Werte ergaben, bei einem zweiten Neustart, die Ergebnisse jedoch viel zu gut ausgefallen sind. Und nach mehr und mehr Neustarts nährt man sich dann wieder immer mehr dem "Normalfall" an.
Sehr strange
.
Ich habe eine saubere 1803 Win10 Installation aufgespielt.
Nur die Treiber und nötigsten Programme installiert und die HDD abgekoppelt um nur SSDs im System zu haben.
Ich habe musste Elex aus meiner Spieleauswahl streichen, da die neueren Radeon Treiber einen Start des Spiels verhindern
.
Dafür habe ich Company of Heroes 2 und F1 2015 mit aufgenommen.
COH2 fand ich überraschend gut und es hat einen integrierten Benchmark. Leider hat der sich als notorisch unzuverlässig erwiesen.
Es gibt fast jedes mal im Benchmark heftige Frametimeausreißer, die aber eben nicht jedes Mal auftreten und machmal auch häufiger als üblich.
Ich musste also statt 6 Messungen je Durchgang eher 8-9 machen um dann nachträglich die zu guten und zu schlechten auszusortieren.
Dazu sind die Ladezeiten in den Benchmark und auch ins Menü quälend langsam...kurz gesagt werde ich das nicht nochmal testen.
F1 2015 wird bleiben...eine Startphase vom Ende des Feldes, bei Sturm, liefert eine hohe CPU Last und kann gut reproduzierbar sein...man darf nur keinen Unfall bauen oder sich von der KI abschießen lassen.
Auch die anderen Spiele habe ich öfter als vorher getestet(7-9 mal je Messreihe) und habe aktiv Ausreißer eliminiert um die "normalsten 5" in das Programm zu füttern. Das führt dazu, das jedes Set an Messungen in sich sehr zuverlässig wird.
Um auf 10 Messungen zu kommen habe ich das zweite Set an Messungen an einem anderen Tag oder zumindest mit Pause/Neustart/usw dazwischen durchgeführt.
Wenn die Auswertung von Set 1 zu Set 2 dann unterschiedliche Ergebnisse gezeigt haben, habe ich mir das notiert und an einem dritten Tag nochmal gemessen...oder noch an einem vierten Tag....um sicher zu gehen, das ich keine versaute Messreihe dazwischen habe.
Ausnahme ist Ashes of the Singularity, wo ich einfach 2x5 Messungen genommen habe ohne zusätzliche Messungen und manuelle Auswahl. Denn der integrierte Benchmark ist einfach mal gut und mal schlecht....mit ca. 40% Chance auf gut...und dann dauert er 3 min.....Ich habe ihn drin weil er große Unterschiede zeigt, dafür habe ich hier bei der Genauigkeit geschludert.
Bei ein paar Spielen habe ich die Messdauer verlängert.(Cities Skylines von 40 auf 50s, Prison Architect von 90 auf 120s)
Hitman hatte bei meinen Tests im März noch einene FPS limiter eingebaut. Dieser ist inzwischen rausgepatched und ich bin gleichzeitig von der Testszene in Paris auf eine Szene in Marrakesh umgestiegen. Die hat noch mehr NPCs auf einem Haufen und noch höhere CPU Last, die teilweise 8 Kerne voll auslastet.
Das alles über 13 Spiele hat mich sehr viel Zeit gekostet! ....über 1800 Messungen und da sind noch nicht die "Vormessungen" drin, die ich nicht aufgezeichnet habe und auch nicht die bei denen was schief gelaufen ist, so dass ich sie direkt gelöscht habe.
Zusammenfassung der Verbesserungen:
-Win10 neu installiert und auf Neustarts geachtet.
-Teils länger und immer mehr als doppelt bis dreimal so oft gemessen.
-CPU Threads festgelegt wo es Sinn ergeben hat.
-Messungen bei Bedarf von Hand sortiert.
-Vega am heruntertakten gehindert..
Dann habe ich die erste Messung("Vormessung") verworfen, da sie in vielen Spielen mit Nachladerucklern zu kämpfen hat und dabei teilweise sogar höhere Durchschnitts-FPS liefert. Ein Mysterium, das ich auf polygonärmere/fehlende Strukturen und schlechtere Texturen schiebe, die bis zum hereinladen der besseren Versionen höhere FPS ermöglichen....oder durch mehr Platz im Cache weil dieser noch nicht so voll ist.....außerdem sind in Spielen, die die GPU stark beanspruchen, kurz nach dem Spielstart die Temperaturen besser und damit der Boost-Takt leicht höher.
Von den fünf verbleibenden Messungen hatte ich mit einem eigenen Auswertungsprogramm die Frametimes über diverse statistische Methoden analysiert.
Um bis zu zwei Ausreißer zu eliminieren bildet das Programm dann nur einen Mittelwert der jeweils besten drei Werte und eine empirische Standardabweichung dieser drei.
Ich denke, dass diese Methode bereits deutlich bessere Ergebnisse lieferte als die der meisten anderen CPU/Ram orientierten Spieletests.
Jedoch musste ich herausfinden, dass die Reproduzierbarkeit trotzdem nicht gut genug für meine Ansprüche war.
Bei den älteren Tests, wo ich Ryzen gegen einen ivy i5 oder 2133 gegen 3200MhzRam getestet habe, waren die Abstände in der Regel deutlich genug um Unterschiede klar zu erkennen.
Lediglich mein Versuch mit einer 2+2 gegen eine 4+0 Konfiguration des Ryzen bei unterschiedlichen Ram Frequenzen die Einflüsse des IF zu untersuchen scheiterte an der Genauigkeit.
Nun sollte es also deutlich genauer werden!
Also habe ich mein Programm erweitert um einen zweiten Satz von 5 Frametime Messungen einlesen und verarbeiten zu können.
Das Programm wertet beide Messungen erst getrennt voneinander aus, so wie schon vorher, und dann nimmt es aus beiden, jeweils die 3 Besten und kombiniert diese.
Es werden jetzt also von 10 Messungen, der Mittelwert von 6 Auserwählten gebildet.
Was sich dabei gezeigt hat, ist wie oft die Messungen einen systematischen Fehler bekommen. Auch wenn die einzelnen Messreihen in sich eine geringe statistischen Schwankung haben, können sie von Tag zu Tag merklich abweichen. Teils sogar sehr deutlich.
Ich bin auf Ursachenforschung gegangen und habe die verschiedenen Spiele mit aktivem OSD getestet. Habe festgestellt, dass das OSD selbst schon überraschend viel Leistung zieht...egal.... es ist bei den späteren Messungen aus.
Es war aber weiterhin schwer die teils einige % betragenden Abweichungen zu ergründen.
Bei einigen Spielen hat die Arbeit des Schedulers den Ausschlag gegeben. Manchmal wurde die Last auf einzelnen Kernen festgehalten...am nächsten Tag eher hin und her geschoben.....dann haben einige Spiele einzelne Kerne überlastet, indem zwei Threads des gleichen CPU Kerns gleichzeitig stark belastet wurden.
Mal wurden Threads des gleichen CCX benutzt und mal gemischt.
Kurz gesagt macht der Windows Scheduler, (vor allem bei älteren Spielen) einen miesen Job auf Ryzen CPUs!
Um dies reproduzierbarer zu machen, habe ich in allen Spielen, die nur wenige Threads benutzen die zugewiesenen CPU-Threads angepasst.
Heroes of the Storm, Starcraft 2, Prison Architect, The Witcher 2, Thief und Frostpunk wurden nur die Threads 0, 2, 4 und 6 zugewiesen.
Also nur 4 echte Kerne eines CCX. Keine Inter-core-Kommunikation über den Infinity Fabric und keine Probleme mit SMT.
Rome TW habe ich die Threads 0 und 1 zugewiesen, also beide Threads des gleichen Kerns und Company of Heroes hat alle Threads eines CCX bekommen also 0-7...auch wenn es besser läuft mit mehr Kernen und ohne SMT.
Ich versuche den Großteil meiner Tests im CPU limit zu machen und da versucht meine Vega64 natürlich Strom zu sparen und niedrigere PStates zu nutzen. Leider schätzt sie die Last immer mal unterschiedlich ein und taktet dann unterschiedlich weit runter und geht auch beim HBM2 mal auf 500MHz und mal nicht.
Um diese Verhalten zu stabilisieren, habe ich für die Benchmarks den P6 als niedrigsten PState festgelegt.
Da die Karte wassergekühlt ist, kommt sie nie in Situationen, wo sie zu heiß läuft. Da die Taktrate aber die Temperatur als ständigen Faktor in die Berrechnung einbezieht, kann ich nicht ausschließen, das der Takt von Messung zu Messung weiterhin leicht unterschiedlich ist. Die Unterschiede sind aber gering und werden im CPU limit keine Rolle spielen.
Ein weiterer Punkt bei Ryzen ist der "sleep-Bug". Etwas das beim Wechsel in den Standby oder auch beim Herunterfahren unter Windows 10 passieren kann. Danach läuft der Timer falsch und da Frametimemessungen Zeitmessungen sind, fallen die Ergebnisse falsch aus.
Um dem vorzubeugen, habe ich den PC jeweils erst aus und wieder an gemacht und dann noch einen Neustart hinterhergeschoben.
Das an/aus bietet eine gleiche Ausgangsbasis und der Neustart behebt einen eventuell auftretenden Sleep Bug.
Interessanterweise konnte ich mehrere Male feststellen, das nach dem Prozedere die Messungen typische Werte ergaben, bei einem zweiten Neustart, die Ergebnisse jedoch viel zu gut ausgefallen sind. Und nach mehr und mehr Neustarts nährt man sich dann wieder immer mehr dem "Normalfall" an.
Sehr strange
.Ich habe eine saubere 1803 Win10 Installation aufgespielt.
Nur die Treiber und nötigsten Programme installiert und die HDD abgekoppelt um nur SSDs im System zu haben.
Ich habe musste Elex aus meiner Spieleauswahl streichen, da die neueren Radeon Treiber einen Start des Spiels verhindern
.Dafür habe ich Company of Heroes 2 und F1 2015 mit aufgenommen.
COH2 fand ich überraschend gut und es hat einen integrierten Benchmark. Leider hat der sich als notorisch unzuverlässig erwiesen.
Es gibt fast jedes mal im Benchmark heftige Frametimeausreißer, die aber eben nicht jedes Mal auftreten und machmal auch häufiger als üblich.
Ich musste also statt 6 Messungen je Durchgang eher 8-9 machen um dann nachträglich die zu guten und zu schlechten auszusortieren.
Dazu sind die Ladezeiten in den Benchmark und auch ins Menü quälend langsam...kurz gesagt werde ich das nicht nochmal testen
.F1 2015 wird bleiben...eine Startphase vom Ende des Feldes, bei Sturm, liefert eine hohe CPU Last und kann gut reproduzierbar sein...man darf nur keinen Unfall bauen oder sich von der KI abschießen lassen.
Auch die anderen Spiele habe ich öfter als vorher getestet(7-9 mal je Messreihe) und habe aktiv Ausreißer eliminiert um die "normalsten 5" in das Programm zu füttern. Das führt dazu, das jedes Set an Messungen in sich sehr zuverlässig wird.
Um auf 10 Messungen zu kommen habe ich das zweite Set an Messungen an einem anderen Tag oder zumindest mit Pause/Neustart/usw dazwischen durchgeführt.
Wenn die Auswertung von Set 1 zu Set 2 dann unterschiedliche Ergebnisse gezeigt haben, habe ich mir das notiert und an einem dritten Tag nochmal gemessen...oder noch an einem vierten Tag....um sicher zu gehen, das ich keine versaute Messreihe dazwischen habe.
Ausnahme ist Ashes of the Singularity, wo ich einfach 2x5 Messungen genommen habe ohne zusätzliche Messungen und manuelle Auswahl. Denn der integrierte Benchmark ist einfach mal gut und mal schlecht....mit ca. 40% Chance auf gut...und dann dauert er 3 min.....Ich habe ihn drin weil er große Unterschiede zeigt, dafür habe ich hier bei der Genauigkeit geschludert.
Bei ein paar Spielen habe ich die Messdauer verlängert.(Cities Skylines von 40 auf 50s, Prison Architect von 90 auf 120s)
Hitman hatte bei meinen Tests im März noch einene FPS limiter eingebaut. Dieser ist inzwischen rausgepatched und ich bin gleichzeitig von der Testszene in Paris auf eine Szene in Marrakesh umgestiegen. Die hat noch mehr NPCs auf einem Haufen und noch höhere CPU Last, die teilweise 8 Kerne voll auslastet.
Das alles über 13 Spiele hat mich sehr viel Zeit gekostet! ....über 1800 Messungen und da sind noch nicht die "Vormessungen" drin, die ich nicht aufgezeichnet habe und auch nicht die bei denen was schief gelaufen ist, so dass ich sie direkt gelöscht habe.
Zusammenfassung der Verbesserungen:
-Win10 neu installiert und auf Neustarts geachtet.
-Teils länger und immer mehr als doppelt bis dreimal so oft gemessen.
-CPU Threads festgelegt wo es Sinn ergeben hat.
-Messungen bei Bedarf von Hand sortiert.
-Vega am heruntertakten gehindert..
Hierbei habe ich mich nicht auf maximale FPS durch niedrige Auflösungen und Einstellungen konzentriert, sondern die Auflösung auf 1440p gelassen und nur in komplett CPU limiterten Spielen die maximalen Details genutzt.
Wo die Grafikkarte eine Rolle spielt, habe ich die Optionen individuell angepasst um einen guten Kompromiss aus Grafik und FPS um die 80-100 pro Sekunde zu finden.
Ich habe die Spiele also so eingestellt, wie ich sie selbst spielen würde und dann getestet welche Unterschiede sich bei diesen realen Situationen ergeben.
Die getesteten Szenen waren dabei natürlich so gewählt, dass sie für die CPU typisch bis besonders anspruchsvoll sind.
Wo die Grafikkarte eine Rolle spielt, habe ich die Optionen individuell angepasst um einen guten Kompromiss aus Grafik und FPS um die 80-100 pro Sekunde zu finden.
Ich habe die Spiele also so eingestellt, wie ich sie selbst spielen würde und dann getestet welche Unterschiede sich bei diesen realen Situationen ergeben.
Die getesteten Szenen waren dabei natürlich so gewählt, dass sie für die CPU typisch bis besonders anspruchsvoll sind.
Die Testsequenzen:
Ashes of the Singularity
Für eine genauere Betrachtung des Spiels, der Benchmarksequenz, die Unterschiede von CPU und GPU Test sowie DX11 v. DX12, bitte in diesen Spieletest schauen:
Ashes of the Singularity
Das Spiel ist schlecht zu testen!
Die Testsequenz dauert extrem lang(3min) und wenn man sie abbricht, muss man erstmal wieder die Spieldateien verifizieren und eine 14,1MB große Datei neu herunterladen...andernfalls stürzt er beim nächsten Benchmark ab.
Dann schwanken die Messungen zufällig hin und her. Mal hat man 50FPs dann 48 dann wieder 48 dann wieder 50...es ist undurchsichtig und dubios. Ich dachte erst es würde an dem Aufheizen meiner Wasserkühlung liegen aber es ist völlig zufällig.
Da die Unterschiede der Ram Konstellationen so deutlich sind werden trotzdem brauchbare Ergebnisse daraus.
DR profitiert gut, jedoch nicht bei den Frametimes und 3200MHz.
SC Betrieb kostet viel Leistung, jedoch besonders viel bei 2133.
Cities Skylines
Für eine genauere Betrachtung des Spiels, der Benchmarksequenz, usw. bitte in diesen Spieletest schauen:
Cities Skylines
Ich habe jedoch die Testdauer von 40 auf 50s angehoben um eine bessere Statistik für die 0.1% low Werte zu erhalten.
DR und SR Ram liegen gleichauf.
der SC betrieb kostet etwas Leistung.
2933 Cl16 liegen im Mittelfeld.
Company of Heroes 2
Ein Neuzugang bei meinen Spieletests, der nicht bleiben wird.
Das Spiel ist eigentlich ganz cool. Macht man AA runter ist es auch CPU limitiert und der integrierte Benchmark zeigt eine zum Spielgeschehen passende performance.
Es profitiert auch von mehr als 4 Kernen usw.
Leider ist es furchtbar unzuverlässig zu messen.
Es gibt in unregelmäßigen Abständen Rukler, die ich nicht in den Griff bekommen habe. Ich musste daher extrem oft messen und extrem viel Aussortieren.
Für eine bessere Reproduzierbarkeit habe ich für die Ram Tests nur die Thread 0 bis 7 zugewiesen. Es wird damit besser aber nicht gut^^
Der Vergleich von DR zu SR ist kaum relevant.
Der Wechsel zu SC kostet kaum Leistung und das auch nur bei 2133. Bei 3200 scheint die Bandbreite bereits gut genug zu sein.
Heroes of the Storm
Bitte in diesen Test gucken:
Heroes of the Storm
Für eine bessere Reproduzierbarkeit habe ich für die Ram Tests nur die Thread 0 2 4 und 6 zugewiesen.
Die Unterschiede bei DR zu SR sind gering aber die gute Reproduzierarkeit macht es wieder wett.
SC kostet nur wenig Leistung und 2933 sind mal wieder in der Mitte.
Hitman: Marrakesh
Die früheren Tests zu Hitman die ich gemacht habe, sind bei ausreichend CPU/Ram Power in ein FPS limit gelaufen.
Inzwischen wurde dieses Limit weg gepatcht und das Spiel zeigt endlich zu was die Engine in der Lage ist.
16 Threads bis zu 50% auszulasten ist schon ganz ordentlich.
Ich bin auch von der Szene in Paris auf die Szene in Marakesh gewechselt, weil hier noch mehr NPCs rumlaufen und die CPU Last noch etwas höher ist.
Es zeigen sich gute Vorteile für DR Ram und große Nachteile für eine SC Konfiguration.
Das Spiel liebt scheinbar Ram Bandbreite.
Prison Architect(64bit)
Siehe diesen Test:
Prison Architect
Für eine bessere Reproduzierbarkeit habe ich für die Ram Tests nur die Thread 0 2 4 und 6 zugewiesen.
Bei 3200 DR brechen die Frametimes stärker ein als für SR Ram.
Bei 2133 gewinnt DR jedoch.
Der SC Betrieb verliert deutlich.
293 ist wieder im Mittelfeld.
Rome TW: Barbarian Invasion
Auch dieses Spiel habe ich früher schon getestet:
Rome TW: Barbarian Invasion
Ich bin jedoch nicht so sehr mit der Reproduzierbarkeit zufrieden.
Ab und zu stirbt ein General in den 60s Test.
Manchmal schwingt das Schlachtenglück extremer zu einer Seite....und mal ist einfach der Wurm drin.
Zusätzlich sind die FPS so gering, das in den 60s unter 2000 Frames gerendert werden.
die 0.1% sind also nur der schlechteste Frame und gleich mit den P99.9
Ich konnte dieLeistung verbessern und die Ergebnisse stabilisieren, indem ich dem Spieleprozess nur die Threads 0 und 1 zuweise.
Ich habe schon früher festgestellt, dass sich das Spiel zwar gut für CPU Takt aber so gut wie nicht für Ram interessiert.
Daher sind die Unterschiede sehr klein und sehr schwer zu messen.
Grob gesagt is schnellerer Ram jedoch trotzdem besser.
Rise of the Tomb Raider
Ein schönes Spiel, das je nach Situation von vielen und schnellen CPU Kernen profitiert und auch Ram mag.
Sonst jedoch eher GPU limitiert ist.
Siehe dieser Test:
Rise of the Tomb Raider
Da das Spiel überwiegend GPU limitiert läuft(zumindest mit 8 Kernen) zeigen die avg FPS kaum Unterschiede.
Man sieht jedoch wie sich bei den Frametimes die Spreu vom Weizen trennt.
Die Unterschiede werden größer. Vor allem der SC bricht deutlich ein.
Und das vor allem bei 2133, hier scheint die Bandbeite besonders zu limitieren.
Starcraft 2
Auch hier möchte ich auf meine alten Tests verweisen:
Starcraft 2
Für eine bessere Reproduzierbarkeit habe ich für die Ram Tests nur die Thread 0 2 4 und 6 zugewiesen.
DR zu SR ist schwer zu unterscheiden, die gute Reproduziebarkeit macht dies jedoch möglich.
SC, 2933 und generell der Unterschied von 2133 und 3200MHz sind wie zu erwarten.
Thief(vier)
Kein besonderes Spiel aber einfach zu testen, wenn auch nicht super genau.
Thief
Für eine bessere Reproduzierbarkeit habe ich für die Ram Tests nur die Thread 0 2 4 und 6 zugewiesen.
Die Abhängigkeit vom Ram ist hoch.
DR und SR zeigen große Unterschiede, SC bringt starke Nachteile und 2933 liegt mittig.
F1 2015
Ein weiterer Neuzugang:
Ich habe zum Testen kurze 30s ausgewählt, da ich nur bis zu diesem Zeitpunkt eine zuverlässige CPU Last reproduzieen kann.
Ich starte dafür mit schlechtem Wagen in einem Einzelrennen aus der hinteren Reihe. Es stürmt und diverse Fahrhilfen sorgen dafür, das ich problemlos den Wagen steuern kann ohne Skill zu brauchen.
Die Dichte an Gegnern vor einem ist wichtig für die CPU Last. Ich fahre daher in der ersten Kurve immer in eine relativ mittige Position und halte diese dann bis zum Ende der 30 s
Ich war sehr überrascht, wie riesig die Unterschiede sind. Da macht das Testen Spaß!
DR gewinnt deutlich, SC verliert deutlich und das auch bei 3200MHz.
Frostpunk
Kein Spiel dieser Testreihe. Ich habe es mir gekauft als ich mit den anderen Tests schon durch war.
Ich hatte aber viel Spaß es zu spielen, und auch wenn das Spiel von Anfang bis Mitte GPU limitiert läuft, wurde meine CPU gegen Ende zimlich in die Knie gezwungen.
Es verdient eine kurze Vorstellung:
Im Video und in dem Diagram habe ich die Threads wieder auf 0 2 4 und 6 begrenzt.
Sonst hat das Spiel nämlich die böse Angewohnheit zwei Threads des gleichen CPU Kerns stark zu belasten und damit deutlich die Leistung zu drücken.
siehe hier:
The Witcher 2
Auch dies ein alter Bekannter:
The Witcher 2
Für eine bessere Reproduzierbarkeit habe ich für die Ram Tests nur die Thread 0 2 4 und 6 zugewiesen.
Leider ist trotzdem an manchen Tagen einfach der Wurm drin und die Messungen passen nicht zusammen.
Ich musste dieses Spiel viel zu oft messen und oft hat es trotzdem nicht für eine ausreichende Genauigkeit gereicht.
hat man dann alles dutzende Male getestet, ergeben die Messungen durchaus Sinn.
Leider sagen die Fehlerbalken trotzdem Nein zu diesem Test.
Es wird wohl aus meiner Auswahl fliegen^^.
Das was man sieht ist nicht so ungewöhnlich. DR etwas vor SR.
SC ist nur leicht zurück.....und 2933......mittig....wo sonst
The Witcher 3
Auch dies ein alter Bekannter:
The Witcher 3
Trotz fast durchgehendem GPU limit ein interessantes Spiel.
In der Wildnis mag die CPU keine Rolle spielen. In Städten wie Novigrad mit vielen NPCs können CPU Kerne, CPU Takt und Ram jedoch wichtig werden.
Bei 8 Kernen ist das dann eher weniger der Fall.
Nur 2133 mir SC fehlt die nötige Bandbreite und verliert massiv an Leistung.
Zusammenfassung
Ich habe Elex austauschen müssen(startet nicht mehr mit neuen Vega Treibern) und habe es durch COH2 und F1 2015 ersetzt.
COH2 wird wieder rausfliegen aber F1 2015 hat mit gut gefallen.
Meine Bemühungen um noch genauere Ergebnisse waren in den meisten Fällen erfolgreich.
Ich habe aber einen großen Preis in Form von noch mehr investierter Zeit gezahlt.
Einen Satz Messungen für alle Spiele kostet mehrere Stunden ...ich brauche zwei und immer wieder musste ich eine Reihe der Spiele noch ein drittes und viertes mal testen.
Aber das kommt davon, wenn man CPU intensive Szenen sucht und testet.
Ich könnte mir auch langweilige Szenen in den Spielen suchen und würde in einem Bruchteil der Zeit tolle Ergebnisse erhalten.
Nur würde ich dann eben nur da testen wo Spiele eh gut laufen und die Hardware eigentlich keine Rolle spielt.
Ich möchte aber da testen wo es kritisch wird....wo andere Hardware auch deutliche Unterschiede erzeugt.
Im Moment ist nur der Artikel zu DR vs. SR Ram fertig.... der Nächste folgt hoffentlich bald
.Was sind eure Meinungen dazu?
Habt ihr Verbesserungsvorschläge oder wollt ihr besimmte Sachen sehen, die ich hier nicht behandelt habe?
Zuletzt bearbeitet:
