Frametime vs FPS

[Baal Netbeck]

aber bewegen sind auch zwischen 16 und 17ms, wenn "MsBetweenPresents" es tun.

Ich kann gerade nicht an meinen großen Rechner....aber ich gucke mir das auch nochmal an.
Ich bin nur verwundert, weil es bei meinem Test aus Post #54 ja so gut gepasst hat.
Ab und zu fehlte mal ein Peak hier und da....Die Peakhöhen waren mal bei Fraps und mal bei OCAT höher/niedriger.
Aber eigentlich war es sehr passend.
Am Ende waren die 99 Percentile mit 22,07 und 22,1757ms ziemlich nah zusammen und wenn ich die Zeiten in das Fraps Format umgewandelt hatte und eingelesen hatte, hat mein Programm 22,18 ausgespuckt, was ja passt.

Ich denke ich habe leichte Unterschiede durch Rundinksfehler im Durchschnitt...…Mein Code macht glaube ich wirklich den Durchschnitt der einzelnen Frametimes....weil in Fraps ja immer die Zeit seit dem starten der Messung drin steht und daher habe ich gleich beim Einlesen die Differenzen der Frames in ein array gespeichert und damit weitergearbeitet.
Ich hätte stattdessen wohl besser den Wert des letzten Frame durch die Anzahl teilen sollen, als wieder alle Frametimes aufzusummieren und dann zu teilen.
Ich muss da nochmal in den code gucken und das eventuell verbessern....aber die Abweichung ist mit 18,4264 zu 18,42 ja jetzt nicht so wichtig.

 

[Taxxor]

Jetzt noch mal ein Run mit FRAPS und OCAT in Tomb Raider

OCAT avg 49.2566
OCAT 99th 23.4404ms

FRAPS avg 49.3
FRAPS 99th 23.62

Hier passt es jetzt auch, aber wenn man sich die Frametimes von FRAPS anschaut, sind sie in Tomb Raider auch wesentlich gleichmäßiger als in Kindome Come, hier schwankt es immer nur +-0,5ms, genau wie bei OCAT.

Für möglichst ungleichmäßige Frametimes nehme ich mir jetzt mal No Mans Sky vor.
Edit: War wohl nix, OpenGL scheint OCAT nicht zu mögen.

Nehmen wir eben FFXV

OCAT avg 85.6482
OCAT 99th 18.7828ms

FRAPS avg 85.83
FRAPS 99th 18,78ms

hmm, diesmal passt es sogar noch exakter als bei Tomb Raider

 

[Baal Netbeck]

Wir könnten das gleiche Spiel testen.....hier habe ich eine Reihe Spiele drin, die ich schonmal getestet habe, und die auch installiert sein sollten......eventuell hast du ja ein paar gleiche:
https://www.youtube.com/playlist?list=PLP9fskJGwUOT5CByAJMJrXaggyMuUgsFt

 

[Taxxor]

Ich glaube ich könnte herausgefunden haben, woran es lag, teste es aber gleich direkt gegen.
Und zwar hatte ich glaube ich "Recording Detail" im OCAT auf Normal stehen, für die letzten beiden Benches habe ich es auf Simple gestellt, so wie es auch Standard ist.

Der jetzige Kindom Come Bench mit Simple ergibt das hier

OCAT avg 71.4516
OCAT 99th 21.4916ms

FRAPS avg 71.5
FRAPS 99th 21.47ms


Stelle jetzt mal auf normal

OCAT avg 75.5551
OCAT 99th 17.0701ms

FRAPS avg 75.65
FRAPS 99th 17.06ms


Okay, keine Veränderung, die frametimes schwanken jetzt auch in den FRAPS Daten nicht so sehr wie bei meiner Messung vorhin. Also Fazit ich weiß nicht, was bei besagter Messung passiert ist, alle folgenden Messungen liefern exakte Ergebnisse, genau wie deine AotS Messung.


Letzter Test für heute, AC Odyssey, wieder mit "normal"

OCAT avg 45.5488
OCAT 99th 29.8294ms

FRAPS avg 45.54
FRAPS 99th 29.83ms

Perfekter geht's ja fast nicht mehr^^

 

[Baal Netbeck]

Ich bin gespannt
Ich glaube ich hatte auf die dritte komische Option gestellt.

 

[Taxxor]

OCAT scheint also zuverlässig zu sein, trotzdem gibt es scheinbar nicht das perfekte Programm für alles...

Denn das Overlay von OCAT funktionierte in FFXV nicht, in AC Odyssey auch nicht(laut google blockiert uplay das wohl, also allgemein uplay Spiele, AC startet nicht mal, wenn man das Overlay aktiv hat)
Bei den beiden konnte man aber immerhin Messungen machen.
Bei No Mans Sky(OGL) funktionierte es gar nicht.

FRAPS hingegen macht überall Messungen, aber das Overlay geht in DX12 nicht, hier funktionierte OCAT wiederum, auch wenn es bei Tomb Raider falsche Dinge angezeigt hat, bei Battlefront 2 ging es.

Das einzige Overlay, welches in jedem getesteten Spiel funktionierte war der Afterburner.
Und in jedem getesteten Spiel konnten sowohl Afterburner als auch FRAPS Messungen machen.

 

[Baal Netbeck]

Da wir noch nicht klären konnten was der Afterburner für eine Berechnungsmethode für die low Werte hat und weil er bei mir in manchen Spielen( und auch da eher zufällig/unzuverlässig die Frametimes) verhagelt, kommt er für mich auch nicht in Frage.
Er ist sicherlich die beste Variante, um für sich selbst live die Performance zu überprüfen.
Man kann sich direkt die Frametimes als Graph angucken und so beim finden von passenden Grafikeinstellungen sehen welche die Frametimes beeinflussen und man sieht wann was limitiert.

Wenn ich aber zuverlässige Benchmarks machen möchte ist für mich Fraps immer noch die erste Wahl.....für Vulkan und eventuell DX12 kann ich ja auf OCAT ausweichen.

Das ist im Grunde auch das Fazit von Gamers Nexus gewesen.....Afterburner unzuverlässig, Fraps bewährt aber nicht fit für low level APIs …..und PresentMon/OCAT funktioniert manchmal nicht.

 

[Taxxor]

Bei meiner ersten OCAT Messung wird wohl irgendwas schief gelaufen sein, was entweder die Frametime Aufzeichnung bei OCAT betroffen und diese "geglättet" hat, oder aber die von FRAPS "zerhackt" hat.

Das ist doch mal ein Paradebeispiel für dein Programm und dem "Schnitt aus den besten 3 von 5 Messungen".
Hier wäre diese Messung dann rausgefallen.


Für den Alltag werde ich wohl den Afterburner nehmen, da ich hier zu jeder Zeit das Overlay habe und in Echtzeit schauen kann, wie es läuft. Gleichzeitig wird dann FRAPS im Hintergrund laufen mit deaktiviertem Overlay, sodass man bei Bedarf eine richtige Messung machen kann.
Denn gemessen hat FRAPS ja auch in jedem Spiel, einzig die Info, ob jetzt wirklich gestartet wurde, fehlt mir dann.

Daher könnte man auch je nach Spiel wechseln, alles wo FRAPS funktioniert nutzt man dieses Overlay, und wenn es irgendwo nicht geht, einfach per Hotkey das FRAPS Overlay ausblenden und das Afterburner einblenden.

für Vulkan und eventuell DX12 kann ich ja auf OCAT ausweichen.

Das lustige ist, dass OCAT auch bei No Mans Sky mit OpenGL nicht funktioniert hat. Komisch, weil es ja eigentlich von AMD kommt, da hätte ich gedacht dass es gerade mit OpenGL funktioniert. Aber hier funktioniert FRAPS auch tadellos.



Hast du für das Einfügen der OCAT Datei in dein FRAPS Tool eigentlich auch ein Skript erstellt, oder hast du das händisch eingetragen?

 

[Baal Netbeck]

Das lustige ist, dass OCAT auch bei No Mans Sky mit OpenGL nicht funktioniert hat

Steht aber auch nicht in der Kompatibilitätsliste...da steht für OCAT nur DX11, DX12 und Vulkan.

Ich habe Vulkan mit Destiny 2 ausprobiert, da hätte ich jetzt zum ersten mal ein Spiel wo ich wirklich OCAT brauche.

Ich denke ich werde wohl noch ein zweite Variante von meinem Programm programmieren, die dann OCAT richtig einlesen kann. So schwer sollte es ja nicht sein.
Das Problem, wenn man sich coden zu 90% selbst beibringt, sind die Antworten in Foren....da wird eigentlich nie eine Lösung zu dem Problem geschrieben, sondern Leute machen "Andeutungen" wie man es lösen könnte, die ich zu 90% nicht verstehe und mein Liebling ist "warum nutzt du Arrays...nimm doch Vektoren".
"Mit XY würde das viel eleganter gehen"...usw.

 

[.Sentinel.]

und mein Liebling ist "warum nutzt du Arrays...nimm doch Vektoren".

Arrays sind Starr und lösen z.B. bei fehlerhaften Referenzierungen nen Crash aus, wohingegen Du bei den Vectors out of bound Checks tätigen kannst, die bei fehlerhaften oder nicht existierenden Indizes Behandlungsroutinen triggern kann. Zeitgleich kann man Vektoren sowohl dynamisch aufblasen, als auch wieder on the fly verkleinern.

Du machst Dein Programm also durch Nutzung robuster, dynamischer und zeitgleich speichereffizienter.

 

[Taxxor]

Ich denke ich werde wohl noch ein zweite Variante von meinem Programm programmieren, die dann OCAT richtig einlesen kann. So schwer sollte es ja nicht sein.

Ich bin gespannt^^
Ich hab vom programmieren so gar keine Ahnung, aber dein bestehendes müsste man eigentlich nur minimal anpassen, es dürfte sogar weniger aufwendig werden, denn du brauchst ja nur Framenummer und dazugehörige Frametime.
Die Umrechnung von der FRAPS Datei in die realen Frametimes kannst du dann komplett weglassen, weil diese ja so schon bei OCAT ausgegeben wird.

Die Framenummer ist zwar in der OCAT Datei nicht vorhanden, aber sie ist ja nur die Zeilennummer +1(wegen der Überschriften)

 

[Baal Netbeck]

Die Framenummern habe ich vorher gar nicht eingelesen.
Die waren ja einfach die Zeilennummer in meinem array.
Im Grunde ist die Arbeit gleich. Ich könnte die Spalte mit der Zeit in Sekunden in Frametimes umrechnen, wie ich es mit den Zeiten auf Fraps gemacht habe oder die Frametimes zu Zeit in Sekunden aufsummieren oder beide Zeilen einlesen und sofort nutzen.

Was ich nutze, da bin ich noch nicht ganz sicher.
OCAT fängt ja mit dem ersten Zeitpunkt nicht bei 0 an. Aber auch nicht mit der Zeit, die der erste Frame braucht.
In Fraps war der erste Frame bei Zeit 0...dann habe ich immer die Differenz zum nächsten als Frametime genommen, was am Ende also ein Wert wenige war.
Mit OCAT kann ich theoretisch den ersten Frame auch nutzen, aber die Summe der Frametimes wird nicht 100% mit der Länge der Messung übereinstimmen.

Mein Problem vorher war es, dass der Einlesebefehl den ich verwendet habe, in jeder Zeile das nach dem ersten Komma eingelesen hat.
Ich weiß nicht, wie ich ihn dazu bringe erst nach den x-ten Komma einzulesen....aber das wird schon irgendwo im Internet stehen.

 

[Taxxor]

Ob jetzt ein Frame mehr oder weniger in die Berechnung mit einfließt, ist bei 3-10K Frames für eine durschschnittliche Messung ja auch nicht so ausschlaggebend.

 

[p4z1f1st]

Darf ich mal was blödes fragen?

Verstehe ich die Angaben bei CapFrameX der ganzen Perzentil-Angaben beim Analysis-Tab richtig, dass das Frametimes in FPS-Umrechnungen sind?

Oder nochmal primitiver gefragt:

Wenn ich 99% percentile auswähle bekomme ich die Werte, die z.B. Computerbase bei sich in den Grafikkarten-Tests in den Diagrammen als "99th Percentile (Frametimes in FPS)" angibt?

 

[Baal Netbeck]

Darf ich mal was blödes fragen?

Immer doch

Verstehe ich die Angaben bei CapFrameX der ganzen Perzentil-Angaben beim Analysis-Tab richtig, dass das Frametimes in FPS-Umrechnungen sind?

Ja ....FPS haben die Einheit 1/s .....und geben an, wie viele frames im Schnitt, pro Sekunde gerendert wurden.

Frametimes gibt man in ms an....aber dann ist es schwer zu vergleichen und die Leute sind an FPS gewöhnt...können sich etwas darunter vorstellen.

Daher rechnet man die um....einfach 1000/frametime ergibt die gleiche Einheit wie FPS.

Wenn man kleinlich ist, kann man einen Streit vom Zaun brechen, ob das dann "in FPS" genannt werden darf....es sind ja keine FPS, sondern percentile....aber ich hoffe du verstehst was gemeint ist.

Man hätte statt 99th percentile in FPS von z.B. 50 1/s.....auch 99th percentile in ms von 20 schreiben können......aber dann sind bei den FPS größere Zahlen besser und bei den percentile kleinere Zahlen.....das verwirrt.....dann könnte man die FPS als durchschnittliche frametimes in ms angeben.....aber das ist vermutlich auch nicht gewollt.

Wenn ich 99% percentile auswähle bekomme ich die Werte, die z.B. Computerbase bei sich in den Grafikkarten-Tests in den Diagrammen als "99th Percentile (Frametimes in FPS)" angibt?

So sollte es sein.....minimale Unterschiede kann es geben weil die percentile teilweise etwas anders bestimmt werden.

Ich nehme die Definition, die ich in der Uni gelernt habe....OCAT mag es leicht anders berechnen.....und CapFrameX macht es noch etwas anders....soweit ich weiß werden da nicht strickte frametimes genommen sondern irgendwie die Nachkommastelle mit einbezogen...und führt dann zwischen zwei frametimes eine Regression durch....kann man besser finden....kann man kritisch sehen weil es keine übliche Definition ist.

....am Ende kannst du aber davon ausgehen, dass das alles vergleichbar ist.....99th percentile gibt die Grenze zwischen den schlechtesten 1% der frametimes und den anderen 99% an.

Die 1% Low frametimes hingegen mitteln dieses schlechteste eine %.....

Beides sehr ähnlich....
Percentile ignorieren die allerschlimmsten frametimes....gab es innerhalb der Messung z.B. einzelne Ruckler, dann werden die ignoriert....die Low Werte beinhalten diese weil sie den Durchschnitt bilden.....hat beides Vor und Nachteile.

 

[p4z1f1st]

Super, danke für die Erklärung!

Ich muss aber zugeben, dass ich mir nicht sicher bin die Definition des Percentiles ganz verstanden zu haben.

In dem Tooltip von CX steht "X% percentile: X% of all values are lower than this"

Heißt das (bei 99% percentile), dass 99% aller Werte NIEDRIGER sind als der angegebene Wert?
Beispiel an einer 30sec langen Sequenz aufgenommen in Doom (2016):

P99 sind 154,3 "Frametimes in FPS" (wenn wir es jetzt mal so nennen wollen) - d.h. 99% aller Werte sind UNTER 154,3 gewesen, korrekt?

P1 mit 134,9 sagt mir wiederum, dass nur noch 1% aller Werte unter 134,9 waren - sprich, es war zu 99% immer MINDESTENS 135 "FPS".

Die "% low" muss sagen verstehe ich nicht.

Ich frage mal so: Ich möchte ermitteln, was für einen Einfluss mein RAM-OC auf die NIEDRIGEN Frameraten der Spiele hat.
Soll ich hierfür mein Augenmerk mehr auf P1 setzen oder auf die %low-Werte?

(Sorry, falls ich vermeidlich blöde Fragen stelle... )

 

[Baal Netbeck]

Heißt das (bei 99% percentile), dass 99% aller Werte NIEDRIGER sind als der angegebene Wert?
Beispiel an einer 30sec langen Sequenz aufgenommen in Doom (2016):

Um niedriger und höher zu vermeiden, habe ich absichtlich von besser und schlechter gesprochen.

Bei mir sind 99% der frametimes besser als dieser Wert..... Aber gebe ich den in ms an, dann sind 99% niedriger..... Gebe ich den in 1/s an, sind 99% höher.

.....das kommt also darauf an, wie man es auslegt....tauscht man die Bezeichnung, wenn man von ms in 1/s Umrechnet?

Ich glaube CB macht das genauso..... Aber CapFrameX scheint sich da umentschieden zu haben.

P99 sind 154,3 "Frametimes in FPS" (wenn wir es jetzt mal so nennen wollen) - d.h. 99% aller Werte sind UNTER 154,3 gewesen, korrekt?

So wie CapFrameX es hier angibt....ja.

P1 mit 134,9 sagt mir wiederum, dass nur noch 1% aller Werte unter 134,9 waren - sprich, es war zu 99% immer MINDESTENS 135 "FPS".

Ja ...aber wie gesagt.... Die Bezeichnungen ändern sich je nach Autor.

Können aber aus dem Kontext erschlossen werden......du siehst ja welcher Wert besser oder schlechter ist.

Die "% low" muss sagen verstehe ich nicht.

Das sind keine Grenzwerte... Das sind Mittelwerte.

Stell dir vor du hast deine Messing aus all dem frametimes.... Sortierst die der Größe nach und nimmst für 1% die Anzahl der frametimes Mal 0,01.

Bei z.B. 2534 frametimes, ergibt das 25,34.
Je nach Art der Berechnung entscheidest du dich für den 25. den 26. oder etwas zwischen dem 25. und 26. Frametime.

Der Wert in ms oder umgerechnet in 1/s ist dein Grenzwert.....das percentil.....die low Werte nehmen nicht diesen Grenzwert, sonder alle(z.b. 25 )frametimes und bilden deren Mittelwert.

Ich möchte ermitteln, was für einen Einfluss mein RAM-OC auf die NIEDRIGEN Frameraten der Spiele hat.
Soll ich hierfür mein Augenmerk mehr auf P1 setzen oder auf die %low-Werte?

...kommt darauf an, ob du wissen möchtest, ob mögliche einzelne Ruckler weniger stark ausfallen, oder ob du nur die niedrigen frameraten sehen möchtest.

Die Low sind eine Mischung.....die percentile ignorieren die einzelnen Ruckler und sind damit einfacher zu messen.

Wenn du wissen möchtest, wie dir der RAM in Situationen hilft, wo die FPS stark absinken, dann schau auf die P1 aus CapFrameX.

Wenn du von einzelnen Ruckler geplagt bist und wissen möchtest ob dir hier RAM hilft, dann schau auf die 0.1% Low frametimes.

 

[p4z1f1st]

Nochmal ich @Baal Netbeck :

Ich bin gerade am wild herum messen, um herauszufinden, ob bzw. bis zu welchem RAM-Takt mein RAM-OC was an der Spieleperformance ändert.

Da es ja immer wieder heißt, dass speziell RAM-OC, wenn, dann größtenteils in den Minimum-FPS Vorteile bringt bin ich daher mehr und mehr am grübeln, ob ich nicht nur auf die P1-Wert und P1 low-Wert achten und der Rest mir relativ egal sein kann.

Habe ich da einen Denkfehler oder sehe ich das grundsätzlich richtig - auch generell fällt es mir immer schwerer die Sinnigkeit anderer FPS-Werte zu sehen (speziell die "klassischen" Werte wie Avg., Max- und Min-FPS...).
Wenn ich weiß, dass 99% aller meiner Frames MINDESTENS den P1-Wert haben, dann weiß ich ja wie das Game läuft.
Ob ich mal für 2-3 einzelne Frames dann den z.B. dreifachen Wert davon habe, juckt mich nicht...

Und ich habe eben im Analysis-Fenster den Option "Remove Outliers" entdeckt.
Der Tooltip beschreibt es irgendwie, als würde da was "simuliert".
Ich dachte ja im ersten Moment, dass das die EXTREMEN Ausreißer rausnimmt - weiß einer, was genau diese Option macht?

 

[Baal Netbeck]

Da es ja immer wieder heißt, dass speziell RAM-OC, wenn, dann größtenteils in den Minimum-FPS Vorteile bringt bin ich daher mehr und mehr am grübeln, ob ich nicht nur auf die P1-Wert und P1 low-Wert achten und der Rest mir relativ egal sein kann.

Meiner Erfahrung nach, ändert sich bei einem CPU Limit, beides....AVG FPS und die schlechten frametimes.... Außer, die frametimes Peaks kommen von nachladeruckler und sind über das Laufwerk dominiert.

Was aber öfter passiert, ist das die Szene teilweise GPU limitiert ist.... Oder zumindest nah dran.....dann ändert sich an den durchschnittlichen FPS nicht viel, weil diese von GPU Limit dominiert sind und es sieht so aus, als würden nur die frametimes profitieren.

Auf die Percentile oder 1%low frametimes zu achten ist aus meiner Sicht ein gutes Maß für das Spielgefühl... Aber bedenke, das diese auch sehr viel schwerer zu messen sind!
Du wirst dir jede Konfiguration mehrfach messen müssen und Mitteln..... Ansonsten sind die Ergebnisse eher Zufall als Ergebnis deines RAM OC.

Habe ich da einen Denkfehler oder sehe ich das grundsätzlich richtig - auch generell fällt es mir immer schwerer die Sinnigkeit anderer FPS-Werte zu sehen (speziell die "klassischen" Werte wie Avg., Max- und Min-FPS...).
Wenn ich weiß, dass 99% aller meiner Frames MINDESTENS den P1-Wert haben, dann weiß ich ja wie das Game läuft.
Ob ich mal für 2-3 einzelne Frames dann den z.B. dreifachen Wert davon habe, juckt mich nicht...

Die AVG FPS sind halt zuverlässig zu messen.... Das hat schon seine Berechtigung... Und am ihnen sehr ich auch ganz gut ein Maß für den Input lag.... In vielen spielen sind mir 60 FPS zu träge....um die 70-80 FPS oder mehr, dürfen es schon sein, denn da spüre ich noch eine deutliche Verbesserung.....ab 100 ist es mir dann aber egal.... Ich spiele nicht professionell online Shooter oder sowas.

2-3 frametimes, die den dreifachen Wert in ms oder in 1/s haben? Das ist schwer zu Benchmarken..... Aber wenn man zuverlässige Daten hat, dann interessieren mich zumindest die Peaks nach oben in den frametimes (ms).
Denn die spürt man ja als kleines oder großes Stottern.
Wenn man die nicht in der Auswertung möchte sind die P1 percentile ein guter Anhaltspunkt...
Die ignorieren ja 1% der frametimes und damit auch diese Peaks.

Ich dachte ja im ersten Moment, dass das die EXTREMEN Ausreißer rausnimmt - weiß einer, was genau diese Option macht?

Ich habe da wohl zu lange nicht mehr an der Diskussion teilgenommen.... Aber wenn es macht was die Beschreibung sagt, dann wird es wohl einige der frametime Peaks aus der Messung nehmen.... Wie viele und bis zu welchem Grad kann ich natürlich auch nur raten.

Aber ich könnte mir vorstellen dass es bei deiner Messung gar nichts ändert, da du keine externen Peaks hast.

So eine Funktion könnte ich mir sehr vorteilhaft vorstellen, wenn du z.B. eine lange Messung machst während du spielst.... Und bei jedem respawn gibt es einen riesen Peak, der aber nicht das Gameplay repräsentiert......wenn man die über diese Funktion rausnehmen könnte, könnte man die frametimes des eigentlichen Gameplays weiterhin analysieren.

 

[p4z1f1st]

Dann würde ich wohl meine Betrachtung der P1-FPS und P1-low-FPS um die AVG-FPS erweitern

Danke für die ausführlichen Antworten!