Frametime vs FPS

Baal Netbeck

Fleet Admiral
Registriert
Apr. 2008
Beiträge
12.481
Dies ist ein ausgelagertes Thema aus diesem Hauptthread:
https://www.computerbase.de/forum/t...kussion-zu-spieletests.1728575/#post-20678303
Edit: Achtung, das ist ein alter artikel mit teilweise veralteten Infos:
Intro:
Bei den meisten Spieletests werden die durchschnittlichen Frames Pro Sekunde angegeben(avg FPS) und daran festgemacht wie gut ein Spiel läuft und wie gut welche Hardware sich im Vergleich schlägt.

Das ist nicht richtig schlecht, bildet aber meiner Meinung nach nicht zuverlässig die Realität ab.

Von vielen Testseiten und auch hier auf CB werden inzwischen 99 Perzentil(manchmal auch 99.8) Werte angegeben. Wenn über diese in Foren gesprochen wird, sehe ich aber viel Unsicherheit und Missverständnisse. In der Nomenklaturerläuterung im Hauptthread habe ich bereits geschrieben wie sie gebildet werden und das sie nicht immer unproblematisch sind.

Schon bevor CB 99 Perzentil Werte angegeben hat, gab es vereinzelt Frametime-Graphen zu begutachten. Leider sind diese jetzt wieder seltener geworden und wurden dem Publikum auch nicht näher erläutert, sodass kaum jemand sie beachtet hat.

Ich selbst fand diese Artikel sehr interessant und wenn man auf das erste Datum schaut sieht man, das die Thematik eigentlich keine neue ist. Der Fokus liegt hier zwar erst mal auf Grafikkarten aber es lässt sich gut auf CPUs übertragen.
http://techreport.com/review/21516/inside-the-second-a-new-look-at-game-benchmarking
http://techreport.com/review/24553/inside-the-second-with-nvidia-frame-capture-tools
http://techreport.com/review/31546/where-minimum-fps-figures-mislead-frame-time-analysis-shines


In diesem Artikel will ich versuchen mit ein paar Beispielen Vorteile und Probleme von verschiedenen Bewertungsmethoden aufzuzeigen. Dabei benutze ich überwiegend Extrembeispiele und Cherry picking um meine Punkte zu erläutern und Aussagen zu falsifizieren. Das ist mit meinen Möglichkeiten nicht anders möglich weil ich für allgemeingültige Aussagen alle Spiele auf allen erdenklichen Systemkonfigurationen testen müsste....aber einzelne Gegenbeispiele bekomme ich hin ;)

Grundsätzliches zu Frametimegraphen:
Fangen wir mit einer einfachen bildlichen Darstellung von zwei Frametimeverläufen an.
Auf der X-Achse ist die Zeit in Sekunden aufgetragen und auf der Y-Achse die Frametimes in Millisekunden. Längere und damit in der Auftragung höhere Frametimes sind schlecht.
PreyTestbild1.png PreyTestbild2.png

Auf den ersten Blick sieht Bild 1 nach deutlich mehr und höheren Schwankungen aus. Doch auf den zweiten Blick sollte man die Skalierung beachten und sehen, dass im linken Bild der schlechteste Frametime immer noch unter 15ms liegt und damit gut unterhalb der 16,67ms, die 60FPS entsprechen. Im folgenden schauen wir uns die Diagramme bei gleicher Skalierung an und vergrößern einen Bereich mit einem inset:
PreyTestbild1c.pngPreyTestbild2c.png

Hier wird klar, das Bild 1 in Wahrheit besser läuft und an der gleichen Stelle mit einer größeren Schwankung zu kämpfen hat.
Nicht so schön finde ich das bei CB gelöst, denn da sind zwar beide Graphen im selben Diagramm und das löst das Problem der y-Achsenskalierung, aber auf der X-Achse ist nicht die Zeit sondern die Framenummer angegeben und dann werden Verläufe mit weniger FPS kürzer dargestellt.Edit:das wurde gefixt
https://www.computerbase.de/2017-03...player-frametimes-ryzen-7-1800x-gegen-fx-8370

Interessant für den Aspekt Frametimes vs. FPS ist zu erwähnen, das Bild 2 einen Durchschnitt von 8.97 +-2.35 ms bzw. 111,5 FPS hat. Bild 1 kommt auf 8,6 +- 0,89 ms bzw. 116,2 FPS.

Das macht nur 4,2% mehr FPS für Bild 1 aber Bild 1 fällt gar nicht unter 60FPS und Bild 2 43 mal.

Die Auftragung als Graphen mit richtiger Skallierung und am besten zusammen in einem Diagramm ist also schonmal vielversprechend und hilft für die Bewertung viel.
Aber müssen wir dann dutzende Diagramme durchschauen? Immer nur 2 bis 3 CPUs oder CPU Konfigurationen gleichzeitig vergleichen? Wie vergleich man sowas wenn alles recht gleich ist, man aber Feinheiten sehen möchte? Schlimmer noch Werte quantifizieren, die man dann prozentual vergleichen kann?
So schon mal nicht:
witcher3zuviel.png

Perzentilwerte und mögliche Probleme
Ich beginne mit einem Beispiel aus einer meiner Heros of the Storm Messungen:
Graph224021datei1.png

Vorgegriffen stehen hier schon ein paar mehr statistische Werte dabei, interessant ist aber der 99.9Percentil Wert. Die Graphen zeigen einen Vorteil für 4+0 aber keine so dramatischen, wie die 63% Unterschied die der Wert suggeriert.
Warum der große Unterschied? Beide Messungen haben 5 Ausreißer und einer von ihnen macht bei 2+2 die 51,63 ms. Denn die Messung hat 4988 Wertepaare und der P99.9 Wert entspricht dem 5. schlechtesten Frametime Wert.
Die Messung für 4+0 hat 5144 Wertepaare und daher wird der 6. schlechteste Wert betrachtet. Etwas niedrigere avg FT sorgen also für den entscheidenden Sprung.

Zugegeben...bei P99 Werten ist mir sowas noch nicht passiert.
Das liegt aber auch daran, dass meine Testszenen eher 40s bis 3min dauern. Da geht es für die P99 Werte nicht mehr um einzelne Ausreißer sondern um ganze Bereiche hoher FT.
Wenn die Testszenen 25s dauern wie bei CB und dann nur weniger FPS erreicht werden, landet man schonmal bei um die 1000-2000 Wertepaaren....und dann ist der Sprung von knapp unter zu knapp über 2000 für die P99 Werte der Unterschied zwischen dem 20. und 21. schlechtesten Wert. Je nachdem wie viele Ausreißer in den Frametimes enthalten sind, können diese also zahlreich vorhanden sein und werden trotzdem ignoriert oder kommen gerade über die Grenze und fallen dann um so stärker auf....siehe Beispiel 2

Beispiel 2( Forza 7):
https://www.computerbase.de/2017-09/forza-7-benchmark/3/
Im obere Frametimeverlauf bitte auf die Vega Performance achten und im unteren auf die 1080FE mit neuem Treiber.
Der neue Treiber bessert nicht nur die avg FT der 1080FE sondern auch die Anzahl und Höhe der Ausreißer. Trotzdem sieht man noch ca 17 deutliche Ausreißer in diesen 25s. Bei Vega sind es je nach Betrachtung 5-9. Ein nicht zu verachtender Unterschied in meinen Augen, der sich in der Angabe der Perzentil Werte wiederspiegeln sollte...aber schauen wir sie uns an...
1080 neuer Treiber----- avg FPS = 88FPS----- P99 = 75,4FPS
Vega64---------------- avg FPS =83,7FPS---- P99 = 75,3FPS
Warum sieht man keinen Unterschied? Weil in beide Fällen knapp über 2100Frames aufgenommen wurden und die P99 Werte daher die schlechtesten 21 Werte ignoriert.
Würden die P99.9 Werte angegeben, würde beide Male der 3. schlechteste Frametime betrachtet und wenn ich das richtig aus dem Frametimeverlauf ablese, komme ich auf:
1080 neuer Treiber----- =16,8ms = 59,52FPS
Vega64 ----------------= 13,6ms = 73,5FPS
Ein deutlicher Unterschied, der meiner Meinung nach besser den Verlauf repräsentiert.
Man kann argumentieren, dass der P99 Wert gar keine Ausreißer enthalten soll und mehr ein Ersatz für die minimum FPS darstellt.
Aber schaut man sich den alten Treiber an:
1080 alter Treiber P99 = 62,1FPS
Dann sieht man wie hier die Ausreißer enthalten sind, weil es ca 30 sind und bei knapp unter 2000Frames, der 20. schlechteste von ihnen den P99 Wert ausmacht. Wen es interessiert....ich würde hier als P99.9 Wert ca 13,6ms = 45,3FPS ablesen.

Man kann weiter argumentieren, dass sowohl die Vega64 als auch die 1080 mit neuem Treiber ein flüssiges spielen ermöglichen und die Ausreißer zu klein sind um wahrgenommen zu werden....dem stimme ich als Aussage zu, aber die gleichen Unzulänglichkeiten, die sich hier bei den P99 Werten offenbaren, könnten in einem anderen Fall durchaus relevant für das Spielgefühl sein.
Wie das Beispiel von Forza 7 zeigt, kann es Situationen geben, wo Perzentil Werte minimale Unterschiede aufweisen obwohl diese größer sind. Ober es werden wie bei dem Heroes of the Storm Beispiel große Unterschiede suggeriert, die eigentlich nur gering sind. Das soll nicht heißen, dass dies oft passiert. Aber ich denke man sollte die Möglichkeit im Hinterkopf haben, bevor man die Perzentil Werte auf die Goldwaage legt;).
Die P99 Werte sind je nach Spiel anders zu interpretieren.
So ist der P99 Wert in meiner einen RomeTW Testszene fast gleich den Minimum FPS aber in City Skylines so ein Mittelding.
FTFPSvergl rome intro.png FTFPSvergleich city skylines.png

Das Diagramm von Rome zeigt zusätzlich ein weiteres Problem. Mittelwerte sind schlechte Darstellungen der Spieleperformance wenn die Testszene Kamerasprünge und Szenenwechsel beinhaltet. Und wie oben schon gezeigt, Perzentil Werte decken nur die schlechten Teile der Szene ab und ignorieren den Rest.

Mehr Messgrößen für ein besseres Gesamtbild.
Die Grenzwertverletzungen die ich bei der Nomenklatur(Hauptthread) schon beschrieben habe sind eine nette Ergänzung und zusammen mit den Percentile Werten geben sie einen guten Eindruck, was man schlimmstenfalls zu erwarten hat.
Sie schwanken aber auch gerne stärker und natürlich sollte man nicht wie in den Beispielen hier nur eine Messung betrachten sondern über mehrere Mitteln. Ebenso ignorieren sie weite Teile der Messung.

Mittelwerte haben also auch ihre Berechtigung, aber der klassische Mittelwert widerstrebt mir wenn ich mir die Mikroschwankungen angucke, die man in vielen Spielen findet.

Zoomen wir mal in eine Sekunde von Heroes of the Storm hinein:
Heroes one sec 1.png

Ich habe die einzelnen Messpunkte mit Punkten markiert und man sieht, das jeder 5. bis 6. Frametime deutlich schlechter ist. Liegen die guten Werte im Bereich von 100+FPS, schwanken die schlechten im Bereich von 60FPS. Schauen wir uns die lokalen Mittelwerte über jeweils 11 Frames an:
Heroes one sec 2.png

Wie man sieht liegt der Mittelwert eher im Bereich der guten Frametimes weil diese in der Überzahl sind.
Da kommen meine effektiven Frametimes ins Spiel.
Heroes one sec 3.png

Das bestimmen der effektiven Frametimes gibt weitere Informationen
Diese eff FT orientieren sich eher an den schlechten Frametimes und ihr Mittelwert ist demnach näher am eigentlichen Spielgefühl. In diesem Beispiel würde ich sie gerne noch etwas extremer haben, aber dann würden sie in anderen Spielen über das Ziel hinausschießen und das möchte ich vermeiden.
weitere Beispiele:
devision one sec.png witcher3 one sec.png witcher2 one sec.png

Was bringen sie mir also? Als Graph nicht viel...eventuell eine besse Übersicht, wenn man mehrere Graphen mit vielen Mikroschwankungen zusammen darstellen möchte. Den Durchschnitt der eff FT als statistische Messgröße(avg eff FT) kann man angeben. Er ist meiner Meinung nach eine bessere Angabe als der klassische Durchschnitt, aber sicherlich problematisch, weil keine allgemeine Definition dahinter steht.
Für mich, war der prozentuale Unterschied zwischen den avg FT und den avg eff FT, ein guter Indikator für das Maß an Mikroschwankungen. Unter 5% Abweichung ist dabei noch gut und ab 10% wird es schlecht.

Später hinzugenommen habe ich noch die 95% low, 99% low und 0.1% low Werte. Diese stellen den Mittelwert der Frametimes dar, die z.B. schlechter sind als der 95 Perzentil Wert.
So werden die Ausreißer sicher erfasst und das mit einer allgemeingültigeren Form als bei den Grenzwertüberschreitungen.

Die 0.1% low Werte unterliegen oft einer schlechten Reproduzierbarkeit, aber die 1% low Werte sind für mich inzwischen die beste Möglichkeit um das Spielgefühl einer Testsequenz zu beschreiben.
Die reine Angabe der avg FPS hat meiner Meinung nach nur minimale Aussagekraft und sollte immer mit Frametimemessungen ergänzt werden.

So bleibt bei der Erfassung der Frametimes die Möglichkeit der graphischen Darstellung und der statistischen Auswertung. Beides hat Vor- und Nachteile....und für diese zu sensibilisieren war ein großes Ziel dieses Themas.



Das soll es erstmal gewesen sein....eventuell fällt mir später noch was ein.

Was meint ihr dazu? Fallen euch weitere Punkte ein?
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: ridgero, GERmaximus und Tweakit
Kommt natürlich immer aufs Genre an, aber sobald die min FPS nicht unbedingt unter ein unspielbares Level rutschen, sind die Frametimes zu priorisieren.
 
Womit kann man die Frametimes in einem Spiel so als Diagramm loggen?
Ich würde mal gerne so ein Diagramm zu einer mir problematischen Software sehen wollen.
 
Mit MSI Afterburner kann man das machen soweit ich weiß. Für das beste Ergebnis würde ich aber das OSD komplett deaktivieren, da das auch immer ein paar FPS zieht (1-5). Gleiche gilt eigentlich auch für das Steam Interface.
 
@Baal:

Ich habe nun einmal Daten aus meiner Problemsoftware extrahiert und sie mit Excel aufgearbeitet.
Was würdest du zu diesem Frametime-Verlauf sagen?

Untitled.jpg
 
Das sieht nach einer überforderten Grafikkarte aus 😉
 
5 Threads zu einen Thema, das ist zu viel des guten. Überlege dir bitte welche wie zusammengelegt werden können.
 
SKu schrieb:
@Baal:
....
Was würdest du zu diesem Frametime-Verlauf sagen?
Ich habe dir eine ausführliche PM dazu geschickt....aber hier nochmal meine Vermutung zu deinem Frametimeverlauf.
Da passieren drei Dinge:
Erstens, einzelne Ausreißer, die vermutlich durch Wartezeiten der Hardware zustande kommen... vermutlich Daten, die noch nicht im VRam liegen und erst aus dem Ram geladen werden müssen. Um vom Laufwerk geladen zu sein sind die Ausreißer meiner Einschätzung nach eher zu klein. Kann aber auch sein...SSDs sind ja flott.

Die gleiche Szene mehrfach testen sollte dann viele der Ausreißer dezimieren.

Zweitens....die Frametimes ändern sich blockweise. Vermutlich wechselst du die Kameraposition oder etwas anderes ändert sich in der Szene.

Drittens....und das ist interessant...diese Mikroschwankungen, die auch blockweise, mal nach oben und mal nah unten streuen.

Meine Spekulation dazu ist ein Zusammenspiel aus zwei Zeitschrittweiten in der Spieleengine. z.B. ein Zeitintervall, nachdem das Spielgeschehen aktualisiert wird und dann ein Zeitintervall, dass die Frameausgabe taktet.
Liegen beide Intervalle in der gleichen Größenordnung, verschieben sich die Aktualisierungszeitpunkte zueinander und irgendwann springen sie über.
Sind die Frameausgabe-Intervalle leicht kürzer, gibt es erst einige Frames im Einklang mit dem Spielgeschehen-Intervall. Und dann kommt ein Frame, bei dem das Ausgaben-I genau in ein Geschehens-I passt und es wird ein Frame mehr ausgegeben.
Das Gegenteil, wenn das Ausgabe-I leicht größer ist, weil dann ab und zu der Fall eintritt, dass in einem Geschehens-I gar kein Aktualisierungspunkt der Ausgabe-Intervalls liegt. Es fehlt also ein Frame und das Frametime steigt an.

Das Ganze funktioniert natürlich auch mit Vielfachen....wenn normalerweise jedes zweite mal ein Frame ausgegeben wird...und dann je nach verschiebung mal jedes oder nur jedes dritte Mal ein Frame ausgegeben wird.

Vermutlich funktioniert es intern anders und meine Spielgeschehen/Frameausgabe Intervalle sind Blödsinn.....das es irgendwelche Intervalle gibt, die dieses Verhalten hervorrufen glaube ich aber schon.
Ich würde vermuten, dass das Spiel gar nicht so schlecht läuft wie es dieser Frametimeverlauf vermuten lässt. Ich für meinen Teil sehe Ruckler nur zuverlässig wenn sie über 50ms gehen. Die einzelnen Ausreißer um die 30-40ms, die du im Verlauf hast, können, müssen aber nicht sichtbar sein. Kommt auch stark auf das Spiel an. Bei einem Autorennspiel sicherlich...bei einem Top down Spiel eher weniger.

Edit:
Damit meine Theorie funktioniert, muss es etwas anders ablaufen.....Das zweite Intervall muss warten bis das erste Intervall abgeschlossen ist. Dann erst gehen auch Frames verloren oder werde doppelt ausgesendet. Braucht das zweite zu lange und verpasst eine volle Aktuallisierung des ersten, ist der Frame verloren und es muss auf das nächste volle erste Intervall gewartet werden.

.....Bitte sagt mir ob das irgendwie Sinn ergibt oder kompletter Blödsinn ist:freak:
 
Zuletzt bearbeitet:
Danke Baal fürs aufmachen dieses Threads und das Ansprechen des Themas.

Es wird immer einige geben die sagen das FPS das einizige ist was wirklich zählt und das Frametimes zweitrangig sind.

Wie falsch man damit liegen kann wird sehr eindrucksvoll beim Anschauen dieses Videos, das eigentlich einen ganz andere Frage verfolgt. Der Test ist zwar ansich schon schlecht, weil wir nichts außer dem CPU Takt und die verwendete Grafikkarte genannt bekommen, man kann aber sehr eindrucksvoll sehen, dass das verwendete Spiel (ArmA3) auf dem System mit den niedrigsten FPS am flüssigsten läuft.

Auf den Systemen links und mitte treten ständig, teils sehr heftige Ruckler auf. Wenn man als einzige Info Average FPS bekommt, würde man den Kauf des Systems mit der flüssigsten Darstellung direkt ausschliessen.

https://youtu.be/6yh9doMXt3I?t=2m6s
 
Zuletzt bearbeitet von einem Moderator:
  • Gefällt mir
Reaktionen: MaexxDesign und CMDCake
Danke für deinen Beitrag:).

Szenen wie in dem Video sind natürlich ein Extrembeispiel. Gerade ab 4min wo über das Wasser geflogen wird, sieht man es besonders gut.

Ich hätte allerdings im OSD gerne einen Frametimeverlauf, denn teilweise haben Aufnahmen auch Ruckler, die im original nicht da waren. Ein Frametimeverlauf bringt da Gewissheit.
 
Baal Netbeck schrieb:
Ich hätte allerdings im OSD gerne einen Frametimeverlauf, denn teilweise haben Aufnahmen auch Ruckler, die im original nicht da waren. Ein Frametimeverlauf bringt da Gewissheit.

Das ist ArmA3... das hackelt in der Tat so. Irgendwo gabs hier mal einen thread dazu auch inkl. Frametime verläufen. Ich schau mal ob ich den wiederfinde.

Et voila: https://www.computerbase.de/forum/threads/arma3-performance-of-ryzen.1672767/page-3#post-19973619

frametimes-yaab-png.617605


vs.

untitled-i7-png.617404



Das ist natürlich wirklich ein heftiges Beispiel, auch weil selbst die 99 Percentile diese wenigen einzelnen hänger vermutlich garnicht wiederspiegeln würde. Da bräuchte es schon 99.9 Percentile um das aus den Daten lesen zu können oder am besten einen Frametime verlauf wie hier.
 
Zuletzt bearbeitet von einem Moderator:
Deshalb habe ich jetzt angefangen mehr Wert auf "1% low" und "0.1% low" Werte zu legen. Die percentile Werte sind da viel zu unzuverlässig.

Dein Frametimeverlauf ist zwar etwas ungewöhnlich in μs anstatt ms angegeben, die Verläufe passen aber zusammen.
Das erste Bild stoppt halt bevor sich diese heftigen Ausreißer zeigen, die die Skala sprengen.

Mit was ist das denn aufgenommen? Kann es sein, dass beim einlesen der Daten ab und zu Fehler entstehen?

Denn Fraps hat z.B. die blöde Angewohnheit nicht die Abstände der Frames sondern den Zeitpunkt bezogen auf den ersten Frame anzugeben und um die Werte untereinander zu plazieren werden längere Zahlen mit weniger Leerzeichen davor in die Datei geschrieben.

Ich hatte da in der Vergangenheit das Problem, dass dies beim Einlesen probleme machen kann, wenn bei bestimmten Zahlen eine neue Dezimalstelle hinzukommt und oder die letzte Ziffer eine 0 ist. Dann wird teilweise vom einlesenden Programm die null am Ende(in Fraps eine Nachkommastelle) weggestrichen und durch eine richtige Null ersetzt(Die Zahl 10 mal so groß gemacht).

Ich habe nur kurz in the Thread geguckt aber wenn diese gigantischen Frametimepeaks nicht spürbar sind, muss man sich nochmal die originaldaten in Fraps angucken ob an diesen Stellen nicht ein Übertragungsfehler vorliegt.

Oder es sind Szenenwechsel, bei denen zwar der Wechsel dauert, es aber nocht als Ruckeln wahrgenommen wird.
 
Zuletzt bearbeitet:
Hey @Baal Netbeck ich grabe den Thread hier mal aus, weil ich mich gerade auch etwas mit dem Benchmarktool vom Afterburner beschäftige und dort auch 1% low und 0.1% low Werte ausgegeben werden, jedoch nur als finaler Wert in FPS umgerechnet ohne einzelne Frametime Angaben.

Ich glaube du warst sogar derjenige, der mir vor nicht allzu langer Zeit mal den Unterschied zwischen 99th Percentil und 1% low erklärt hat, indem 99th Percentil der obere Grenzwert und 1% low der Durchschnitt der schlechtesten 1% der Frames ist.

Jetzt habe ich angenommen, dass die 1% low Angabe vom Afterburner eben auch der Schnitt ist, aber bei einer Testmessung vorgestern kamen mir die Werte merkwürdig vor, ich glaube der Afterburner gibt in Wirklichkeit das 99. Percentil aus und betitelt es mit 1% low.

Hier mal das "Protokoll" welches Afterburner ausgibt.

28-11-2018, 02:15:43 ACOdyssey.exe benchmark completed, 2915 frames rendered in 62.078 s
Average framerate : 46.9 FPS
Minimum framerate : 22.5 FPS
Maximum framerate : 68.5 FPS
1% low framerate : 36.0 FPS
0.1% low framerate : 30.5 FPS


Der absolut schlechteste Frame ist immer bei "Minimum framerate" zu sehen, in dem Fall 22.5 FPS.
2915 Frames wurden gerendert, also befinden sich bei den 0.1% low genau zwei Frames, der 22.5 und ein weiterer.

Wenn die 0.1% low jetzt der Schnitt der schlechtesten 0.1% sein sollen, müsste der zweit schlechteste Frame 38.5 FPS sein, um auf den Schnitt von 30.5 FPS zu kommen.
Da aber die 1% low Framerate mit 36.0 FPS über 29 Frames angegeben ist, kann das absolut nicht sein, wenn bereits der zweit schlechteste Frame schneller ist, als der Schnitt der 29 schlechtesten Frames.

Der dritt schlechteste Frame müsste demnach ja mindestens bei ebenfalls 38.5 FPS liegen, selbst wenn alle weiteren 27 Frames genau 38.5 betragen, kommen wir über 29 Frames auf einen Schnitt von 37.9 FPS und nicht 36.0 FPS.

Folglich kann der 0.1% low Wert sich nur auf den besten der zwei Frames beziehen und daher dürfte sich auf der 1% low Wert auf den besten der 29 Frames beziehen.



Da wir aber so gleichzeitig den 99th Percentil, den 99.9th Percentil und auch den Min Wert haben, ist es für die Genauigkeit eigentlich nicht so tragisch, dass nur der beste Werte genommen wurde.
Wenn die Abstände der drei Werte gering sind, weiß man ja, dass keine größeren Ausreißer dabei sein können.

Dazu ein weiteres Beispiel

30-11-2018, 11:24:29 SOTTR.exe benchmark completed, 6880 frames rendered in 100.203 s
Average framerate : 68.6 FPS
Minimum framerate : 26.7 FPS
Maximum framerate : 149.6 FPS
1% low framerate : 58.4 FPS
0.1% low framerate : 46.6 FPS

68 Frames, der beste 58.4 fps und der schlechteste 26.7fps.
Die dazwischenliegenden 66 Frames könnten jetzt sowohl nahe 27fps als auch nahe 58fps liegen, viel Platz für Ausreißer.

Durch die zusätzliche 0.1% low Angabe(6 Frames) wissen wir aber immerhin, dass 61 der Frames über 46.6 liegen, da nur 5 Frames schlechter als 46.6 sind.

Beim Rest weiß man jetzt nicht mehr genaueres, es könnten worst case 61 Werte zwischen 55 und 58 sein, es könnten aber auch best case 61 Werte zwischen 47 und 50 sein.
Aber die Angabe der 0.1% low hat uns die mögliche Spanne immerhin von 27-58 auf 47-58 eingegrenzt.


Ich dachte vielleicht interessiert es dich oder jemand anderen, der sich über das Thema schlau machen will^^
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Baal Netbeck
Danke für den Input. :)
Ich muss mir das mal genauer angucken, aber wenn der Afterburner sich mit der Berechnung an die gängigen Minimum und Maximum FPS hält, dann ist das nicht das beste und schlechteste Frametime in 1/s umgerechnet, sondern die Sekunde mit den meisten Frames und die Sekunde mit den wenigsten Frames.
Also zumindest macht Fraps das so.
Jede Sekunde summiert es die Frames auf(also das was man auch als Overlay zu sehen bekommt) und wenn man die Checkbox "FPS" angewählt hat, bekommt man ein file, das all diese Werte enthält....und im "MinMaxAVG" File stehen dann der Durchschnitt, und der höchste und niedrigste Wert aus der FPS liste.....nicht der höchste und niedrigste Wert aus der "Frametimes" Liste(in 1/s umgerechnet).

Ich bin mit dem Afterburner aber auch nicht wirklich überzeugt...ich habe keine andere Möglichkeit, mir Frametimegraphen als Overlay anzeigen zu lassen, aber man muss ziemlich aufpassen, weil mit meiner Vega gibt es ab und zu den Bug, dass das Overlay selbst schlechte Frametimes macht.
Als ich die Tage Kingdome come Deliverance getestet habe, wurden die Frametimes mit dem Overlay um 15% schlechter.....das Overlay hat in regelmäßigen Abständen schlechte Frametimes verursacht. sogar der Durchschnitt ist um 10% gesunken.

So richtig reproduzierbar ist das aber nicht...manchmal kommt es wenn man nochmal das Spiel minimiert .....manchmal heilt es sich so auch.....aber zuverlässig ist es meiner Meinung nach nicht.
 
Du must im Afterburner die Min FPS aktualisierung auf 1ms stellen. Die steht auf 1000 ms, daher kommt es schon vor, dass die 0.1% niedriger sind als die Min FPS. ^^
 
Baal Netbeck schrieb:
wenn der Afterburner sich mit der Berechnung an die gängigen Minimum und Maximum FPS hält, dann ist das nicht das beste und schlechteste Frametime in 1/s umgerechnet, sondern die Sekunde mit den meisten Frames und die Sekunde mit den wenigsten Frames.
Also zumindest macht Fraps das so.
So dürfte er nicht arbeiten, denn in meinem ersten Beispiel gibt es ja nur 2 Frames beim 0.1% low Wert, wenn er die Sekunde mit den wenigsten Frames nimmt, dann müsste der 0.1% Low Wert ja identisch mit den min fps sein oder nicht? Die Sekunde mit den wenigsten Frames müsste ja diejenige sein, in der die 22.5 entstanden sind.
 
1000ms würde ja mit dem Vorgehen von Fraps entsprechen, also die Summe über jede volle Sekunde.

Allerdings habe ich jetzt mal die Probe aufs Exemple gemacht und mit Fraps und dem Afterburner gleichzeitig gemessen.

Die start und Endpunkte sind sicher nicht auf die millisekunde genau geroffen, aber avg min und max FPS passen sehr gut.
avg sind 84,5FPS.
min MSI=66,7 und Fraps=66
max MSI=98,6 und Fraps=99

Aber die Frametimes passen nicht wirklich.
Was MSI 1% low nennt, liegt mit 57,1 sehr nah an Fraps 99th Percentile Wert von 56.39.
Aber was MSI 0.1% low nennt passt mit 34,0 ganz gut zu den 0,1% low aus der Fraps Messung mit 33,38.

Also einmal passt es zu den Percentile werten und einmal zu den low Werten....ich mache nochmal ein paar mehr Vergleiche.
Ergänzung ()

Taxxor schrieb:
Die Sekunde mit den wenigsten Frames müsste ja diejenige sein, in der die 22.5 entstanden sind.
Nicht unbedingt....in der Sekunde mit der 22,6ms Frametime, gab es ja noch 977,4 andere ms, die mit besseren Frames abgedeckt wurden. und der gemeinsame Durchschnitt kann ja durchaus besser sein, als in einer anderen Sekunde, wo zwar keine so großen Ausreißer drin waren, aber dafür konstant schlechte Frametimes.
 
Baal Netbeck schrieb:
1000ms würde ja mit dem Vorgehen von Fraps entsprechen, also die Summe über jede volle Sekunde.
Es gibt beim Riva Tuner die Auswahl für "Framerate averaging intervall", das steht bei mir auf 1000ms, es gibt aber auch noch eine Auswahl für "Peak framerate calculation mode", wo man average oder instantaneous auswählen kann. bei ersterem passiert es öfter, dass die min fps über den 0.1% low liegen, was Sinn macht, wenn es so läuft, wie du es beschrieben hast.
Ich habe es deshalb aber auf instantaneous stehen.
Somit sollten die min fps auch wirklich der schlechteste Frametime in 1/s umgerechnet sein.
In Kindom Come habe ich es auch mal getestet und auch einen 20er Wert bei den min stehen gehabt, und eine volle Sekunde, in der der Schnitt auf 20fps gefallen ist, wäre mir aufgefallen.

Baal Netbeck schrieb:
Aber die Frametimes passen nicht wirklich.
Was MSI 1% low nennt, liegt mit 57,1 sehr nah an Fraps 99th Percentile Wert von 56.39.
Aber was MSI 0.1% low nennt passt mit 34,0 ganz gut zu den 0,1% low aus der Fraps Messung mit 33,38.
Nun ja das kann trotzdem beides Percentil sein.
Wie viele Frames enthielt denn die Aufnahme? in den 0.1% low sind ja bei 100 Sekunden mit ca 60fps nur zwei Frames enthalten, da ist der beste der zwei schlechtesten Werte und der Durchschnittswert der beiden natürlich fast gleich.
Ergänzung ()

Baal Netbeck schrieb:
Nicht unbedingt....in der Sekunde mit der 22,6ms Frametime, gab es ja noch 977,4 andere ms, die mit besseren Frames abgedeckt wurden. und der gemeinsame Durchschnitt kann ja durchaus besser sein, als in einer anderen Sekunde, wo zwar keine so großen Ausreißer drin waren, aber dafür konstant schlechte Frametimes.
Gut, das verfälscht das Ergebnis aber auch nicht, denn auch wenn in der Sekunde mit den wenigsten Frames nicht die schlechteste Frametime drin ist, in dem 0.1% low sind so oder so die schlechtesten Frametimes drin.
 
Zuletzt bearbeitet:
Die Messung hatte 10641 Frames...Da unterscheiden sich die low und Percentile Werte deutlich.

Ich habe jetzt nochmal Mafia 3 angeworfen....auch da passt der 0.1% low Wert von MSI zu Fraps...zumindest halbwegs. 40,3 zu 41,96
Aber der 1% low Wert passt gar nicht. MSI sagt 63,2....aber mit Fraps komme ich auf 55,88...hier würde MSI eher zu dem 95th Percentile passen.

Ich probiere mal auf instantaneous zu stellen.
 
Ich würde ja auch FRAPS nutzen, die ganzen zusätzlichen Features des MSI Overlays habe ich sowieso durch Rainmeter auf dem zweiten Monitor im blick.
Aber MSI hat halt den Vorteil, dass es dir die 1%low und 0.1% low Werte direkt ausspuckt, während FRAPS dir nur eine elend lange Tabelle gibt mit den gesamt Zeiten der Frames. Das müsste man sich ja alles erst mal irgendwie konvertieren und umrechnen.
 
Zurück
Oben