Sammelthread Baals Hauptthread: Diskussion zu Spieletests

Alles fing damit an, dass ich an einigen Stellen in The Witcher 3 heftige Ruckler hatte und verwirrt war von der Aussage in verschiedenen CB CPU-Reviews, dass die CPU in diesem Spiel keine Rolle spielt.

Dank HisN's bekannter "Was limitert?...MSI Afterburner...GPU Auslastung angucken usw." Anleitung war für mich schnell klar, dass mein damaliger i5 3570K in Verbindung mit 1600erCL9 DDR3 Ram meine GTX 680 nicht mit mehr als 50FPS zuverlässig versorgen konnte...zumindest nicht wenn mehr als ein paar einzelne NPCs in der Nähe waren....woran es lag dachte ich erst gefunden, jetzt ist es mir wieder unklarer

Im März 2017 beglückte ich mich mit einem Ryzen 1800X und schnell stand der Plan selbst CPU Tests zu machen um quantifizieren zu können ob/wie sich das update gelohnt hatte . Aber ich musste feststellen, dass es gar nicht so einfach ist sinnvoll und reproduzierbar zu messen.
Ebenso war meine alte GTX 680 oft ein zu großer Flaschenhals.

Dann kam Agesa 1006 und viel Herumprobieren später liefen meine 2x16GB G-Skill Trident Z dual ranked Ram mit ihren beworbenen 3200MHz und sogar mit besseren Timings als beworben(CL14 und teils leicht drunter).
Wie ich es geschafft habe ist hier nachzulesen:https://www.computerbase.de/forum/threads/ryzen-am4-ram-erfahrungsbericht-mit-agesa-1-0-0-6.1690744/
Inzwischen sind die Bios Versionen in 2018 aber so gut, dass man 95% der Tipps nicht mehr braucht.

Ich habe mich eingelesen, herumprobiert, Frametimeverläufe mit Fraps aufgenommen und eine eigene C++ Konsolenanwendung geschrieben um die Frametimeverläufe statistisch auszuwerten und in eine Form zu bringen, die ein OriginPro als ASCII einlesen kann

Viele Test und viele Erfahrungen später habe ich noch eine Berechnungsmethode programmiert, die aus dem Framtime-Verlauf einen (in meinen Augen) besseren "effektiven" Frametime-Verlauf baut und das in meinem Programm integriert.

Ich habe verschiedenste Statistikwerte ausrechnen lassen, unter anderem Perzentil Werte, wie CB sie nutzt und % low Werte, wie Gamers Nexus, Hardware unboxed und andere sie nutzen.
Grenzwertüberschreitungen, die ohne die Messungen zu plotten direkt zeigen wie viele und wie starke Ruckler in den Messungen waren.

Und die Möglichkeit bis zu fünf Messungen einlesen zu lassen, und entweder den Durchschnitt über drei Messungen, oder den Durchschnitt aus den besten und schlechtesten drei Messungen, der fünf Eingelesenen, inklusive Fehlerrechnung, auszugeben.

FPS: Sind die Anzahl von gelieferten Frames auf eine Sekunde bezogen.
Es ist zu unterscheiden ob wirklich über einen kurzen Zeitraum Frames gezählt wurden, oder ob es gar nur Abstände zwischen zwei Frames sind, die auf mittlere Frames pro Sekunde hochgerechnet wurden, oder ob es die mittleren FPS über den ganzen Testzeitraum sind...letztere würde ich als avg FPS bezeichnen.....die kleinen Mittelwerte, wie sie von Fraps oder MSI Afterburner als "FPS Counter" eingeblendet werden als lokale FPS oder aktuelle FPS und die FPS die sich aus einzelnen Frametimes berechnen einfach als FPS oder präzieser inverse Frametimes bezeichnet.
Vermutlich werde ich einfach generell von FPS sprechen und nur wenn die Unterscheidung wichtig ist "avg" oder "lokal" dazusagen.

Frametimes: Frametimes sind die zeitlichen Abstände zwischen zwei ausgegebenen Frames in ms.
Eine einzelne Frametime wird man nur im Zusammenhang von Ausreißern besprechen....in der Regel meint "Frametimes" den Verlauf und die Verteilung der einzelnen Frametimes über den Testzeitraum.

Anders als FPS sind hier geringere Werte besser!
Analog zu den FPS würde ich avg FT für den mittleren Abstand zwischen allen Frames des Testzeitraums nutzen. lokale FT als mittleren Abstand über einen kleinen Bereich und FT für einzelne Frametimes als Bezeichnung handhaben.

Fraps: Ist ein schlankes Programm, das es ermöglicht von der aktiven Anwendung die Zeitpunkte aller Frames aufzuzeichnen.

Mit einem Hotkey startbar und beendbar oder über einen festgelegten Zeitraum messend.
Die ausgespuckte Datei beinhaltet die Zeitpunkte aller Frames in ms mit drei Nachkommastellen in Bezug auf den ersten Frame.
Diese Zeitpunkte werden notiert, wenn die Spieleengine den "Frame" an die API weiter gibt. Der Zeitpunkt wenn das Bild an den Monitor geht ist natürlich später, weil die Grafikkarte den Frame ja erst rendern muss.
Alternativen wie FCAT behaupten eine bessere Methode zu sein, weil FCAT das eigentliche Monitorsignal analysiert aber das ist sehr aufwendig und meiner Meinung nach selbst für GPU Tests Augenwischerei.
Denn ob die Frames gleichmäßig aus der GPU kommen oder nicht ist zweitrangig, wenn dafür künstlich Frames zurückgehalten werden und der eigentliche Inhalt der Frames nicht gleichmäßig in Bezug auf den Spielverlauf ist. Fraps(oder Alternativen) ist somit die beste Methode die wir haben und für CPU Tests sowieso besser geeignet.
Leider kann Fraps teils kein DX12 aufnehmen(Forza 7 ging z.B. nicht)... aber PresentMon scheint eine unpraktische aber DX12 taugliche Alternative zu sein...In den anderen DX12 Titeln war es mir möglich Fraps für die MEssungen zu verwenden, auch wenn das Overlay nicht funktioniert, ich also halb "blind" teste und ich für Ashes of the Singularity und ROTTR erst das Spiel ohne Fraps starten muss um Abstürze zu vermeiden.
Das Spiel kann dann minimiert werden um Fraps zu öffnen und wieder im Spiel muss man im Falle von ROTTR noch den exklusiven Vollbildmodus erneut aktivieren.

Drops und Rants:Beides sind Frames die an die Grafikkarte weitergegeben wurden, aber Drops "verschwinden" und werden nicht an den Monitor weitergegeben und Rants werden so schnell vom nächsten Frame abgelöst, das sie auf dem Monitor nur einen winzigen Zeilenbereich stellen, der keinen Mehrwert bietet oder gar stört. Beides kann ich mit Fraps nicht analysieren, es ist aber auch eher ein GPU Problem.

Perzentil/percentile: Perzentil Werte müssen einen Zusatz wie "95" haben um definiert zu sein.
Es sind Grenzwerte, unterhalb(oder oberhalb) derer alle übrigen Prozent der Messwerte liegen.
95 Perzentil z.B. wäre der Frametime Messwert über dem die schlechtesten(größeren) 5% der Messwerte liegen.
Man berechnet dazu 5% von der Anzahl der Messwerte...z.B. 1750*0,05=87,5. Der nächstgrößere ganze Wert ist 88. Also sortiert man seine Frametimes der Größe nach und der 95 Perzentil Wert ist dann der 88. schlechteste Frametime. Ich nenne ihn P95.
Sonderfälle sind z.B. wenn man den P99.9 von 1000 Frametimes wissen möchte, dann ergibt 1000*0,001=1 eine ganze Zahl(eher selten) und jetzt ist P99.9 der Mittelwert aus den schlechtesten Frametimes Nr. 1 und 2 anstatt aufzurunden. Unter 1000 Werten wäre P99.9 also immer der schlechteste Wert und zwischen 1001 und 1999 wäre es der zweitschlechteste....usw.

Perzentil Werte sind also harte Grenzwerte....sie sagen nichts über die Verteilung der Messwerte darüber oder darunter aus....ein P99 Wert könnte sehr nah an den avg FT liegen und trotzdem könnte im Verlauf der Messung 1% der Messwerte aus sekundenlangen Pausen bestanden haben. In der Regel sind sie aber eine sinnvolle Ergänzung zur quantitativen Beschreibung der Messung.

Wenn ich Percentile Werte bilde(z.B. P99), dann beziehe ich mich auf die Frametime Messung und berücksichtige damit alle Frames. Der Wert ergibt sich also erstmal in ms. In manchen Fällen möchte ich den Wert z.B. mit avg FPS in 1/s vergleichen und rechne ihn dementsprechend in 1/s um. Ich belasse es dabei bei der Bezeichnung P99 auch wenn es eigentlich der Kehrwert ist und P01 heißen müsste.
Man verzeihe mir diese Ungenauigkeit. Es bleibt der Grenzwert zu den schlechtesten 1% der Frames und bezieht sich auf die gleiche Messmethode....es ist ja nur umgerechnet.
Auch meine avg FPS in 1/s sind so entstanden. Sie werden aus den avg FT in avg FPS umgerechnet.

Standardabweichung: Das ist eine mathematische Methode um die Schwankungen von Messungen zu quantifizieren.
Ich hoffe ich bekomme das korrekt hin....
Es gibt verschiedene Methoden und Bezeichnungen, die sich aber nur unwesentlich unterscheiden.
Ich orientiere mich hier an der empirischen Standardabweichung (2. Definition).
Würden wir mehrere(Gaußverteilt schwankende)Messungen machen und deren Mittelwert bilden um uns dem wahren Wert anzunähern, dann sollte uns die empirischen Standardabweichung einen "Fehler" angeben, sodass der wahre Wert mit 95%iger Wahrscheinlichkeit innerhalb des Intervalls von Mittelwert-2xFehler bis Mittelwert+2xFehler zu finden ist.
Perfekt passend ist es für unseren Fall nicht, weil wir nicht unbedingt gaußverteilte Streuungen haben.
Unsere Mittelwerte für einzelne Messungen (z.B. avg FT) messen nicht immer wieder den gleichen Frame, sondern entstehen bei sich verändernden Szenen.
Leider unterscheidet die Stdabw hier nicht zwischen lokalen Schwankungen und Belastungswechseln durch Szenenwechsel(sind zu vermeiden) oder durch schwankende Anforderungen weil mehr oder weniger im Spiel passiert. 12121212 ergibt das gleiche wie 11112222.
Dennoch ist die Standardabweichung, nennen wir sie stdabw, eine Möglichkeit ein Maß für die Schwankung der Messwerte über den Messzeitraum anzugeben.

Deutlich besser passt sie für den Mittelwert der Statistikwerte mehrerer Messungen und hier nutze ich sie auch am häufigsten um eine Fehlerabschätzung zur Reproduzierbarkeit meiner Messungen anzugeben.

Berechnung:
Sie berechnet sich auf Basis der quadrierten Abständen alle Messwerte zum gemeinsamen Mittelwert. Diese werden aufsummiert und durch das quadrieren werden die größeren Abweichungen stärker gewichtet. Dann teilt man diese Summe von Abstandsquadraten, durch die Anzahl der Messwerte "n"(1. Definition)...oder durch "n-1"(2. Definition) ....ist bei vielem Messwerten alles fast gleich und bei wenigen ergibt n-1 realisischere Werte und wird bevorzugt.
Dann zieht man noch die Wurzel.

Das Ergebnis hat die gleiche Einheit wie der Messwert und hilft enorm relevante Unterschiede von zufälligen Messchwankungen zu unterscheiden.

Teilweise wird (von anderen) auch die "Standardabweichung des Mittelwertes" aus der Statistik verwendet.
Diese unterscheidet sich nur dadurch, das statt durch "n-1", durch "n*(n-1)" geteilt wird.
Das hat zur Folge, dass mit höherer Anzahl an Werten, der ausgegebene Fehler weiter sinkt.
Das ist nicht hilfreich wenn man wissen möchte wie stark unsere Frametime Messung schwankt, sondern ist mehr dazu gedacht, dass Meinungsforscher eine Grundlage haben, um irgendwann zu sagen: "Wir haben ausreichend statistisch relevante Daten gesammelt und müssen keine weiteren Personen befragen!"
Daher benutze ich diese Definition nicht oder zumindest nicht im Zusammenhang mit schwankenden Messungen.

effektive Frametimes: Diese habe ich mir selbst ausgedacht...
Ich habe inzwischen herausgefunden, dass es schon mal Bemühungen gab "gefühlte Framtimes" zu definieren....aber mein Ansatz ist rein technisch und nicht mit logarithmischer Wahrnehmung.
Berechnung:
Für jeden effektiven FT Wert bilde ich einen lokalen Mittelwert local FT über 11 Werte. Dann bilde ich eine Art stdabw dieser 11 Werte, aber Abweichungen nach unten(also besser als der local FT), gehen nur zu einem tausendstel ein...der mittlere Wert wird mit einem Exponenten von 1,1 gepusht und die anderen Werte gehen zwar als Quadrate ein, jedoch mit einer linearen Korrektur je weiter entfernt sie sind.
Dieses Maß für die lokale Schwankung, hin zu schlechteren FT, wird auf den local FT Wert addiert.

Der sich ergebende "eff FT Verlauf" folgt dann dem Verlauf der schlechten Frametimes.
Ohne die nicht relevanten Schwankungen nach unten zu berücksichtigen.
Ausreißer werden abgebildet und im mittleren Bereich verbreitert.
Kurze Lücken werden geschlossen.
Die Peaks bis ca. 50ms werden, in der Regel, etwas zu niedrig aber verbreitert abgebildet....die über 50ms werden härter bestraft, weil sie von den eff FT überboten werden und weiterhin verbreitert werden.
Die avg eff FT unterscheiden sich von den avg FT nicht so heftig wie die P95, 95% low, P99, usw. Werte aber ihre prozentuale Abweichung von den avg FT ist ein gutes Maß für die "mikroskopischen Schwankungen".

X% low Werte: Diese habe ich mir von einigen Tech Youtubern abgeguckt und bin sehr angetan. Anstatt wie die Perzentil Werte nur den Grenzwert zu den schlechtesten X% der Frametimes anzugeben, bilden diese den Mittelwert über diese X%.
Das schließt Ausreißer nicht aus und gerade die 0.1% low Werte geben den Rucklern eine gute quantitative Entsprechung.

Schwankungen/Ruckler: Unter Rucklern versteht jeder etwas anderes. Jedem fallen sie unterschiedlich stark auf und empfindet sie unterschiedlich störend.
Dem einen reichen 30 avg FPS, der andere will 300.
Dem einen fällt es nicht auf wenn die FPS von avg 30 immer wieder auf 20 fallen und der andere sagt es stört ihn wenn sie von avg 300 auf 200 fallen.

Ich will das nicht werten, aber meiner Empfindung nach kommt es auf die Geschwindigkeit des Spiels an und dann sind Einbrüche unter 60 mal störend und mal sind 30 noch OK....spätestens unter 20FPS/ über 50ms für einzelne Frames oder durchschnittlich, fällt es mir zuverlässig negativ auf.

Rein objektiv möchte ich daher nicht von Rucklern sprechen sondern lieber Schwankungen verwenden. Da kann dann jeder für sich entscheiden ob die Schwankungen ihn stören oder nicht. Allerdings möchte ich zwischen makroskopischen und mikroskopischen Schwankungen unterscheiden. Makroskopische Schwankungen sind eine Änderung der lokalen FPS/FT über den Testzeitraum hinweg. Wenn sich also die Komplexität der Szene verändert und sich deshalb die lokalen FPS/FT ändern.
Gerade Perzentil Werte zeigen hier nur den schlechtesten Teil der Szene und ignorieren den Rest. Mikroschwankungen sind das was viele Leute als Mikroruckler kennen. Wenn also die FT lokal stark schwanken. Im Grunde macht das fast jedes Spiel das ich getestet habe, allerdings unterschiedlich stark. Mikroschwankungen führen dazu, dass das Spiel z.B. gefühlt wie 40FPS läuft obwohl die avg FPS bei 50FPS liegen.
Denn das Auge beschwert sich nur wenn die Animationen unsauber laufen....das sie zwischendurch immer wieder besonders gut sind, sollte normal sein und wird nicht beachtet. Der prozentuale Unterschied zwischen den avg FT und den eff FT die ich weiter oben erklärt habe geben den Mikroschwankungen eine quantitative Entsprechung.

Ausreißer/stottern: Bei den Schwankungen habe ich mich eher auf eine allgemein unsaubere Wiedergabe des Spielverlaufs bezogen.
Aber immer wieder gibt es zusätzliche "Ruckler", die unregelmäßig und einzeln auftreten, dafür aber umso heftiger. Diese "Ausreißer" zeigen sich als einzelne besonders schlechte FT in der Analyse und(wenn sie kritische Werte erreichen) im Spiel entweder durch einen Sprung der Animation oder durch ein kurzes Pausieren des Spielverlaufs. Zweiteres würde ich als Stottern bezeichnen.
Sie sind also besonders störend, finden sich aber weder in den avg FPS noch in den eff FPS oder P95 Werten wieder.

Um diesem Problem zu begegnen, zähle ich in der statistischen Auswertung auch die Anzahl der FT, die verschiedene Grenzwerte nicht halten können. Ein Grenzwert ist z.B "unter 30FPS bzw. "über 33,33ms" und ich nenne diesen G30 in Anlehnung an die FPS Grenze.

G30=5 +-0 (0.08133 %). Das bedeutet, im Testzeitraum(steht hier nicht, sind in diesem Fall aber 60s) wurde im Schnitt 5 Mal die Grenze von 30FPS unterschritten und das reproduzierbar in allen drei Messungen(daher die +-0). Der prozentuelle Anteil sind 0,08% der Frames insgesamt.
G60=7 +-5.568 (0.07332 %) sind im Schnitt 7 Grenzwertverletzungen aber mit +-5,6 nicht sehr zuverlässig. So wurden in der ersten Messung 6 gezählt, in der zweiten nur 2 und in der dritten 13.
Um ein vollständigeres Bild zu erhalten halte ich 10 Grenzwert fest und beziehe mich dann auf die sinnvolleren davon. Meine Grenzen sind 7, 10, 15, 20, 30, 45, 60, 90, 120, 140FPS. Wichtig: Egal ob auf FPS oder auf FT bezogen, niedrigere Werte sind immer besser! Und oft vergleiche ich nicht die Anzahl sondern die Prozente.
Besser auszuwerten und ebenfalls die Ausreißer beinhaltend sind die X% low Werte.
Gerade die 0.1% low Werte haben sich als gute Entsprechung für die Stärke und Häufigkeit von solchen Ausreißern erwiesen. Wie auch die P99.9 Werte unterliegen sie aber in der Regel größeren Fehlern, weil sie eben nur einen winzigen Teil der Messwerte nutzen.

Sys1:
Ryzen 7 1800X auf einem Asus Crosshair VI Hero mit Bios 3101
stabil bis 4008MHz @1,4V in der Regel@3,8GHz mit Pstate OC
32GB DDR4 aus 2x16GB 3200er CL14 Trident Z dual ranked
stabil bis 3205MHz, GearDown enabled und PowerDown disabled, 1,35V soc-Spannung 1,05V
Timings:

Grafikkarte:Vega64 LC 8GB VRam. Einstellungen: PT+50%, HBM2@1050MHz, P7 auf 1050mV und 1702MHz eingestellt. Je nach Spiel resultiert das in ca. 1560-1625MHz. richtig festnageln kann man den Takt leider nicht.
Grafikkarte alt:Zotac AMP GTX680 2GB VRam auf Standardtaktraten heruntergetaktet(im Moment nicht mit Kühler versehen).
M2 Samsung 960Pro 512GB, Crucial MX300 1TB, Samsung 850 EVO1TB und WD Red Pro 6TB
CPU und GPU von Custom Wasserkühlung mit 7x120mm Kühlfläche gekühlt.
BeQuiet Dark PowerPro 850W

Sys2:
i5 3570K auf Biostar Z77 xe4
stabil bis 4,6GHz @weiß ich nicht mehr...in der Regel @ 4,4GHz
16GB DDR3 aus 2x8GB Patriot Viper 3 1866MHZ CL11
seit 1,5Jahren nur noch mit 1333 CL11 richtig stabil...aber mit mehr Spannung wieder stabil auf 1866 CL11 allerdings keine Taktzyklus besser als XMP Timings möglich.
Grafikkarte ist die gleiche wie in Sys1, ich habe die Schläuche lang genug gelassen um sie umbauen zu können.

Weiter Systeme kommen erst mal nicht zum Einsatz, es gibt aber noch:
einen C2Q 9550 @2,8GHz mit 4x2GB DDR2 800 cl5 und GTX 285 1GB, Windows 7
einen Laptop mit C2D 8700 @2,5GHz mit 4GB 800er DDR2 CL6 und ATI 4650m 1GB Windows 7
einen Laptop mit i7 4710HQ @2,5-3,3GHz mit 1x8GB 1600CL10 DDR3 und GTX 860m 2GB Win 10
Zumindest einen IPC Vergleich von C2Q, i5 und Ryzen mit 4Kernen alle auf 2,8GHz habe ich mit Cinebench R15 und ein paar Spielen gemacht.