Erläuterungen zu der verwendeten Auswertung und den gezeigten Diagrammen
Entstehung und Erklärungen zum Skript-Benchmark
Dieser Thread ist ein Ableger eines großen Anno 1800 Benchmarks, der aufgeteilt werden musste.Der Hauptthread mit den Inhaltsverzeichnis bietet Erläuterungen die vorher gelesen werden sollten.
Der Ablauf der Messungen
Für das Skript wird Autohotkey benutzt und es wird erst eine lange Vorbereitungsphase abgespult, bevor das Skript im Wechsel fünf Benchmarksequenzen mit Zwischensequenz durchführt.
Die fünf Frametimes Messungen werden mit CapFrameX bei ausgeblendetem Overlay aufgenommen und mit einem selbstgeschriebenen C++ Programm ausgewertet.
Informationen über mittlere RAM/VRAM Belegung, GPU/CPU Auslastungen wurden dem Sensor-Tab aus CapFrameX entnommen.
Die Messungen werden in speziell beschrifteten Ordnern abgelegt und der Dateipfad wird dem C++ Programm übergeben.
Das Programm berechnet pro Messung viele statistische Daten inklusive Percentile und “avg“ low Frametimes.
Dann bildet es von den Daten die arithmetischen Mittelwerte und die Standardabweichung der Einzelwerte(empirische Standardabweichung). Diese Standardabweichung wird in den Diagrammen als Fehlerbalken benutzt.
Die Ergebnisse werden wieder in dem Ordner abgelegt und automatisch beschriftet.
Für die prozentualen Unterschiede wird LibreOffice Calc benutzt und für die Diagramme OriginPro 2022
Das Programm berechnet pro Messung viele statistische Daten inklusive Percentile und “avg“ low Frametimes.
Dann bildet es von den Daten die arithmetischen Mittelwerte und die Standardabweichung der Einzelwerte(empirische Standardabweichung). Diese Standardabweichung wird in den Diagrammen als Fehlerbalken benutzt.
Die Ergebnisse werden wieder in dem Ordner abgelegt und automatisch beschriftet.
Für die prozentualen Unterschiede wird LibreOffice Calc benutzt und für die Diagramme OriginPro 2022
Erklärungen zu der Handhabung der Messunsicherheiten
Obwohl ich Mittelwerte und keine Einzelmessungen präsentiere, gebe ich absichtlich die Standardabweichung der Einzelwerte an, da diese nicht der "Qualität" des Mittelwertes entspricht, sondern ein Maß für die Schwankung der Ergebnisse angibt.In der Berechnung der beiden Methoden kann man den Unterschied im Nenner unter der Summe der Abstandsquadrate sehen. (“n“ ist die Zahl der Messungen, das "x" mit Überstrich ist der Durchschnitt)
Lautet er “n(n-1)“, steckt hier ein n^2 drin, das das Ergebnis schon nach einigen Messungen Richtung 0 drückt und es handelt sich um die Standardabweichung des Mittelwertes.
Lautet der Nenner “n“ oder “n-1“, dann steigt mit mehr Messungen die Zuverlässigkeit der Aussagekraft der Standardabweichung, aber die Aussagekraft über die Schwankung der Messwerte bleibt erhalten, da Zähler und Nenner linear steigen.
Direkt hintereinander gemessen erscheint die Standardabweichung des Mittelwertes als viel zu gut.
Nach einem Neustart kann ein weiterer Satz an Messungen durchaus leicht abweichen, weil z.B. die Daten anders im Speicher angeordnet werden und zufällige Ereignisse im Spiel oder im Hintergrund die Ergebnisse beeinflussen können.
Teilweise wurden daher zusätzliche Messungen an mehreren Tagen gemacht um die Ergebnisse zu verifizieren und den Mittelwert weiter zu verbessern.
Es zeigt sich jedoch, dass die Standardabweichung der Einzelwerte nicht nur ein gutes Maß für die Schwankungen von Messung zu Messung ist, sondern auch abbildet, wie die Ergebnisse von Tag zu Tag schwanken.
Systematische Abweichungen durch die Messsoftware oder die Auswertung kann ich nicht völlig ausschließen, sie würde aber alle Messungen betreffen und der Vergleich bliebe erhalten.
Da sich bei Beachtung der Reihenfolge der Messungen ein Muster zeigt, muss man von einem unerwünschten Drift der Messwerte ausgehen. So zeigt die erste Messung immer etwas höhere avg FPS die dann von Messung zu Messung sinken und auch die low Frametimes zeigen ein öfter wiederkehrendes rauf-bleib-runter-runter Muster.
Deshalb kann man nicht einfach Einzelmessungen auswerten oder eine irgendwie versaute Messung durch eine hinten angehängte 6. Messung ersetzen. Es müssen immer die ersten fünf Messungen ausgewertet werden und bei einem Problem die ganze Serie wiederholt werden.
An einem zweiten Tag weitere fünf Messungen durchzuführen und dann die 10 Messungen auszuwerten ist hingegen kein Problem.
Ich hatte die Idee die Messung mit den höchsten FPS und die Messung mit den niedrigsten 0,1% low Frametimes zu ignorieren und nur über die verbliebenen 3 Messungen zu Mitteln, da dies, bei bestimmten Problemen, eine Art automatische Auslese sein kann.
So können z.B. durch Hintergrundprozesse verursachte Frametimepeaks eine der Messungen stören und diese würde dann ignoriert, was die Abweichung zum Erwartungswert verringert.
Da das spätere Selektieren von Messungen höchst problematisch sein kann(auch wenn es hier automatisiert abgelaufen wäre), habe ich mich dagegen entschieden, mich in diesem Punkt angreifbar zu machen und habe lieber ein paar fragwürdige Messserien wiederholt.
Warum avg low Frametimes und keine Perzentile?
Da ich neben den durchschnittlichen FPS auch an den Frametimes interessiert bin, gebe ich je nach Thema die 1% oder 0,1% low Frametimes an.(In CapFrameX sind sie inzwischen als X% low integral beschriftet)
Das ist jeweils der Durchschnitt der schlechtesten 1%(bzw. 0,1%) der Frametimes.
Bei 20001 Frametimes wären das also der Durchschnitt der schlechtesten 200 bzw. 20 Frametimes.
Im Gegensatz zu den Perzentile, die nur dem 200. bzw. 20. Frametime entsprechen, hat das den Vorteil, dass die Informationen über die darunter liegenden Frametimes nicht verloren gehen.
Die 0,1% low Frametimes sind fast vollständig von den Sprüngen zwischen den Welten und einzelnen Ausreißern dominiert.
Die 1% low Frametimes zeichnen ein gutes Bild von den allgemeinen Kamerasprüngen, dem Öffnen von Menüs, und den zufällig auftretenden Rucklern.
Die FPS sind vor allem ein Maß für den Input lag bei Mausbewegungen/Bauvorhaben und die maximal mögliche Spielgeschwindigkeit.
Es wurde auch versucht diese maximale Spielgeschwindigkeit direkt zu messen, indem am Ende des Benchmarkskriptes eine einsame Stelle über dem Meer angesehen wird und die höchstmögliche Spielbeschleunigung (fünffach) gewählt wird.
Dann wurde mit der Hand gestoppt wie lange es dauert bis 5 Spielminuten verstrichen sind.
Einige Messungen lieferten auch erwartbare und scheinbar gut reproduzierbare Ergebnisse.
Leider war das nicht zuverlässig und zeitweise waren die Abweichungen enorm und die Ergebnisse unrealistisch.
Da die scheinbar gelungenen Messungen sich in den prozentualen Unterschieden ähnlich verhalten haben wie die FPS und das manuelle Stoppen verlangt, dass der Tester zum Ende des Skriptes vor Ort ist, wurde auf weitere Messungen verzichtet und es wird stattdessen auf die FPS verwiesen.
Dann wurde mit der Hand gestoppt wie lange es dauert bis 5 Spielminuten verstrichen sind.
Einige Messungen lieferten auch erwartbare und scheinbar gut reproduzierbare Ergebnisse.
Leider war das nicht zuverlässig und zeitweise waren die Abweichungen enorm und die Ergebnisse unrealistisch.
Da die scheinbar gelungenen Messungen sich in den prozentualen Unterschieden ähnlich verhalten haben wie die FPS und das manuelle Stoppen verlangt, dass der Tester zum Ende des Skriptes vor Ort ist, wurde auf weitere Messungen verzichtet und es wird stattdessen auf die FPS verwiesen.
Die Ergebnisse werden in fünf Arten von Diagrammen präsentiert.
Das Balkendiagramm:
Typisch und hoffentlich selbsterklärend.Die Y-Achse ist mit den wichtigen Hardware oder Software Parametern beschriftet.
Die X-Achse zeigt entweder prozentuale Unterschiede, oder die absoluten Werte in 1/Sekunde.
1/s ist dabei die gleiche Einheit bei den FPS als auch bei den 1%(bzw. 0,1%) low Frametimes. Beide Male wird der Mittelwert der Ergebnisse aus den 5 Messungen, welcher in Millisekunden vorliegt über f(x)=1000/x in 1/s überführt um gewohntere Zahlen zu erhalten, bei denen größere Werte besser sind.
Bei den Prozenten beziehen sich die Werte immer auf den Wert mit 100%. Gibt es mehrere Blöcke, bei denen jeweils ein anderer Bezugswert vorliegt, werden die Blöcke durch Linien getrennt.
Werden z.B. FPS und 1% low Frametimes gleichzeitig dargestellt, sind sie farblich getrennt und in der Legende gekennzeichnet.
Die Fehlerbalken sind immer in der gleichen Einheit wie die Daten selbst und geben die Unsicherheit der Ergebnisse an.
Die X-Achse zeigt entweder prozentuale Unterschiede, oder die absoluten Werte in 1/Sekunde.
1/s ist dabei die gleiche Einheit bei den FPS als auch bei den 1%(bzw. 0,1%) low Frametimes. Beide Male wird der Mittelwert der Ergebnisse aus den 5 Messungen, welcher in Millisekunden vorliegt über f(x)=1000/x in 1/s überführt um gewohntere Zahlen zu erhalten, bei denen größere Werte besser sind.
Bei den Prozenten beziehen sich die Werte immer auf den Wert mit 100%. Gibt es mehrere Blöcke, bei denen jeweils ein anderer Bezugswert vorliegt, werden die Blöcke durch Linien getrennt.
Werden z.B. FPS und 1% low Frametimes gleichzeitig dargestellt, sind sie farblich getrennt und in der Legende gekennzeichnet.
Die Fehlerbalken sind immer in der gleichen Einheit wie die Daten selbst und geben die Unsicherheit der Ergebnisse an.
Das Verlaufsdiagramm
Hier geht es vor allem darum zu sehen wie sich die Leistung in Abhängigkeit vom Takt verändert.Man kann in diesen Diagrammen besser sehen ob es linear verläuft oder ab wann es abflacht.
Die gestrichelten Verbindungslinien sind dabei nur zur besseren Lesbarkeit eingeblendet und sollen keinen linearen Verlauf zwischen den Datenpunkten suggerieren.
Die lineare Regression wird manchmal zusätzlich eingeblendet.
Die gestrichelten Verbindungslinien sind dabei nur zur besseren Lesbarkeit eingeblendet und sollen keinen linearen Verlauf zwischen den Datenpunkten suggerieren.
Die lineare Regression wird manchmal zusätzlich eingeblendet.
Der Statistikverlauf
Hier wird es schnell unübersichtlich, weshalb ich diese Diagramme kaum zeige.Auf der X-Achse sind verschiedene Statistik-Parameter von FPS bis zu den 0,1% low Frametimes aufgetragen.
Jede Farbe ist hier eine andere Konfiguration und die gestrichelten Verbindungslinien zwischen den Datenpunkten sind nur zur besseren Lesbarkeit eingeblendet.
Um so weiter rechts im Diagramm, um so mehr geht es um Bereiche mit niedrigen FPS und die Menge, sowie die Höhe von Frametimepeaks.
Hier kann man dann gut sehen wenn eine Konfiguration zwar bessere avg FPS erreicht, jedoch stärker ruckelt als eine andere.
Die gestrichelten Linien müssen sich dann irgendwo kreuzen und an welcher Stelle sagt einem etwas über den Einfluss im Spiel aus.
Passiert es direkt zwischen den avg FPS und den 95th Percentile, dann kann man davon ausgehen, dass die hohen avg FPS nur durch höhere maximale FPS erreicht wurden und das Spielerlebnis grundsätzlich schlechter ist.
Passiert es zu den 99th Percentile hin, kann man vermuten, dass hier einzelne Bereiche der Testszene schlechter laufen, oder das es einen starken Anstieg der Menge an Frametimepeaks gibt.
Passiert es erst zu den 0,1% low Frametimes, dann sind es vermutlich die Ausprägung der schlimmsten Peaks und oder einige Peaks mehr als in der Vergleichskonfiguration.
Jede Farbe ist hier eine andere Konfiguration und die gestrichelten Verbindungslinien zwischen den Datenpunkten sind nur zur besseren Lesbarkeit eingeblendet.
Um so weiter rechts im Diagramm, um so mehr geht es um Bereiche mit niedrigen FPS und die Menge, sowie die Höhe von Frametimepeaks.
Hier kann man dann gut sehen wenn eine Konfiguration zwar bessere avg FPS erreicht, jedoch stärker ruckelt als eine andere.
Die gestrichelten Linien müssen sich dann irgendwo kreuzen und an welcher Stelle sagt einem etwas über den Einfluss im Spiel aus.
Passiert es direkt zwischen den avg FPS und den 95th Percentile, dann kann man davon ausgehen, dass die hohen avg FPS nur durch höhere maximale FPS erreicht wurden und das Spielerlebnis grundsätzlich schlechter ist.
Passiert es zu den 99th Percentile hin, kann man vermuten, dass hier einzelne Bereiche der Testszene schlechter laufen, oder das es einen starken Anstieg der Menge an Frametimepeaks gibt.
Passiert es erst zu den 0,1% low Frametimes, dann sind es vermutlich die Ausprägung der schlimmsten Peaks und oder einige Peaks mehr als in der Vergleichskonfiguration.
Was haltet ihr von dem Vorgehen bei der Auswertung und der gewählten Darstellung der Ergebnisse?
<- Vorheriger Thread(Andere Benchmarks, Reproduzierbarkeit, Relevanz) --Übersicht-- nächster Thread(Hardware und Einstellungen) ->
Zuletzt bearbeitet:
