Grafikkarten Grundlagenartikel Praxis Testberichte VGA

Gaming-Benchmarks: FPS, Perzentile, Frame Time, Varianzen, Leistungsaufnahme und Effizienz einfach erklärt

Da ich immer wieder gefragt werde, welche Programme ich für die Erfassung und Auswertung meiner Benchmarkdaten nutze und ich auch großen Wert auf die Transparenz lege, habe ich mich jetzt noch einmal hingesetzt und einen Artikel, den ich 2016, also bereits vor 5 Jahren für Tom’s Hardware verfasst habe, noch einmal komplett neu geschrieben. Denn es hat sich nicht nur bei der Genauigkeit viel zum Guten gewendet, sondern es sind auch viele neue Funktionen hinzugekommen. Allerdings nutze ich diese neueren Versionen zusammen mit Tom’s Guide Frankreich exklusiv, da Tom’s Hardware USA nicht an einer weiteren Kooperation mit mir interessiert war und noch auf die alten Templates und eine zum damaligen Stand auch fehlerhafte Software setzt. Das nur mal als Randbemerkung, denn die Zeit läuft ja weiter und Lizenzen auch aus.

Die allumfassende Erhebung aller relevanter Daten während eines Benchmarks ist die Grundvoraussetzung für einen objektiven und auch inhaltlich korrekten Artikel. Deshalb werde ich heute auch nicht nur zeigen, was ich wie ermittle und auch später grafisch für den Leser auswerte, sondern nebenher auch noch die wichtigsten Begriffe wie Perzentile oder Varianzen erklären, denn vieles wird immer wieder nachgefragt und ich werde mich auch leichter tun, diesen Artikel hier in den relevanten Reviews immer wieder mit zu verlinken. Denn einerseits kommen ja immer wieder neue Leser hinzu und andererseits wird man mit der Zeit auch vergesslich.

Low-Level Datenerfassung für DirectX11, DirectX12 und Vulkan mit NVIDIA FrameView

Für das eigentliche Benchmarken nutze ich NVIDIA FrameView, ein auf PresentMon basiertes LowLevel-Erfassungstool für die aktuellen Frame Times im Spiel, das auch noch Systemdaten abgreifen und alles mehr oder weniger in Echtzeit und synchron protokollieren kann. Im Gegensatz zu CapFrameX kann FrameView nicht nur die Protokolldaten schreiben, sondern ergänzt diese auch um Systemdaten analog zu HWInfo und die Leistungsaufnahmemessung aus PCAT (siehe nächster Absatz). Das eher rudimentäre Tool ist Freeware und kann bei NVIDIA heruntergeladen werden.

Ein grafische Auswertung wie CapFrameX bietet das eher rudimentäre FrameView zwar nicht, allerdings werte ich die für mich deutlich informativeren Protokolldateien ja eh selbst noch aus. Der Normalanwender kann mit CapFrameX hingegen sicher mehr anfangen, da er ja die ermittelten Daten selbst nicht weiter auswerten kann oder muss und dort bereits diverse Metriken als grafische Ausgabe geboten kommt. Will man hingegen exakt für alle Karten mit einer einheitlichen Time-Line arbeiten, egal wie viele Frames innerhalb eines Benchmark-Runs wirklich gerendert wurden, führt das für einen grafischen Vergleich z.B. in Excel nicht wirklich weiter.

Das Problem ist ja auch, dass alle Anwendungen zur Leistungsüberwachung wiederum Systemressourcen verbrauchen, was sich auf die aufgezeichneten Ergebnisse auswirkt. Deshalb nutze ich mit Absicht nur FrameView bzw. eine stark optimierte Version von PresentMon, weil diese Programme zwar auf den ersten Blick mit weniger Funktionen aufwarten (die ich aber so eh nicht benötige), im Umkehrschluss aber deutlich schlanker sind und damit auch messbar weniger Ressourcen benötigen.

Das, was FrameView später in die Protokolldatei ausgibt, enthält alle nützlichen Informationen, die man zur Erstellung eigener Metriken so braucht. Rendered Frame Rate setzt z.B. auf den Zeitstempel am Anfang der Grafikpipeline. Diese Metrik steht für die Glattheit der Animation, die an die GPU geliefert wird. Für die Frame-Time-Auswertungen nutze ich hingegen die Displayed-Frame-Rate, wo dann der Zeitstempel am Ende der Grafikpipeline ausgewertet wird und aussagt, was der Benutzer tatsächlich auf dem Bildschirm wann angezeigt bekommt. Das optinale Overlay brauche ich zwar nicht für die eigentliche Auswertung, aber es ist trotzdem bereits im Spiel ein praktischer Indikator, ob wirklich alles rund läuft.

Auch das Benchmarksystem ist kein Geheimnis, wobei es aus Gründen der Bequemlichkeit und Plausibilität sogar zweimal existiert. Nur die Räumlichkeiten sind andere und ich kann im Bedarfsfall sogar parallel arbeiten, denn beide Systeme wurden auch auf deckungsgleiche Ergebnisse hin geprüft.

Test System and Equipment
Hardware:
AMD Ryzen 9 5900X @4.7 GHz
MSI MEG X570 Godlike / X570 Ace
2x 16 GB DDR4 3800, CL16
Be Quiet! Dar Power Pro 1200W
Cooling:
Alphacool Eisblock XPX Pro
Alphacool Eiswolf (modified)
Alphacool Subzero
Case:
Raijintek Paean
Monitor: BenQ PD3220U
Power Consumption:
Oscilloscope-based system:
Non-contact direct current measurement on PCIe slot (riser card)
Non-contact direct current measurement at the external PCIe power supply
Direct voltage measurement at the respective connectors and at the power supply unit
2x Rohde & Schwarz HMO 3054, 500 MHz multichannel oscilloscope with memory function
4x Rohde & Schwarz HZO50, current clamp adapter (1 mA to 30 A, 100 KHz, DC)
4x Rohde & Schwarz HZ355, probe (10:1, 500 MHz)
1x Rohde & Schwarz HMC 8012, HiRes digital multimeter with memory function

MCU-based shunt measuring (own build, Powenetics software)
Up to 10 channels (max. 100 values per second)
Special riser card with shunts for the PCIe x16 Slot (PEG)

NVIDIA PCAT and FrameView 1.1

Thermal Imager:
1x Optris PI640 + 2x Xi400 Thermal Imagers
Pix Connect Software
Type K Class 1 thermal sensors (up to 4 channels)
Acoustics:
NTI Audio M2211 (with calibration file)
Steinberg UR12 (with phantom power for the microphones)
Creative X7, Smaart v.7
Own anechoic chamber, 3.5 x 1.8 x 2.2 m (LxTxH)
Axial measurements, perpendicular to the centre of the sound source(s), measuring distance 50 cm
Noise emission in dBA (slow) as RTA measurement
Frequency spectrum as graphic
OS: Windows 10 Pro (all updates, current certified drivers)

 

Lade neue Kommentare

Blubbie

Urgestein

701 Kommentare 217 Likes

Genau wegen solchen fundierten und gut erklärten Grundlagen Artikeln ist Igor's Seite absolute Spitzenklasse!
Weiter so!
(y):coffee:

Antwort 8 Likes

RX480

Veteran

290 Kommentare 174 Likes

Das klingt total interessant, an welchen Stellen FrameView misst.

Da gabs letztens Diskussionen bei CB, ob net CFX totalen Mist misst.

Antwort Gefällt mir

LurkingInShadows

Veteran

452 Kommentare 131 Likes

@Igor Wallossek :
Frage zu den Mikrorucklern; du schreibst ab 8ms wirds merkbar, ab 16 sehr deutlich; aber ist das nicht Monitorabhängig?

Also solange Varianz (ms) < (1000/Hz)/2 (ms) ists nicht merkbar? Da kommt auch deine Aussage hin, allerdings nur bei einem 60 Hz Monitor.

Antwort Gefällt mir

Igor Wallossek

Format©

5,773 Kommentare 8,943 Likes

Die ganzen Sync-Verfahren lasse ich mal außen vor, weil ich sie ja eh nicht aktivieren darf. Und ich beziehe mich hier weniger auf Monitore, sondern physiologische Grenzen und das, was der mernsch selbst wahrnehmen kann.

Antwort Gefällt mir

M
Martin Gut

Urgestein

3,861 Kommentare 1,348 Likes

Ja und nein. Bei 240 Hz merkt man es viel weniger als bei 60 Hz wenn mal ein Bild ausfällt. Unterschiede von mehr als 16 ms sind bei 60 wie auch bei 240 Hz spürbar. Unterschiede von 2 oder 4 ms sind bei 60 Hz meist gar nicht sichtbar. Bei 240 Hz sind sie wohl sichtbar, aber so kurz dass man es auch kaum wahr nimmt.

Antwort 1 Like

RX480

Veteran

290 Kommentare 174 Likes

Das Auge sieht ja net den absoluten Wert, merkt hingegen die Schwankung.(x)
D.h. in der Praxis hilft ein Cappen per Fps-Limit, um die Schwankung max Fps zu minFps zu verringern,
was zusätzlich noch dem Inputlag hilft.

(x) worst Case = beim Frameverlauf wenn auf einen Berg direkt ein Tal folgt = größte Differenz
(natürlich kann Buffern das etwas abmildern; ... interessant ist dann wirklich Wie und Wo die Frametimes gemessen werden)

Antwort 1 Like

LurkingInShadows

Veteran

452 Kommentare 131 Likes

Solange aber dieser worst case bei der halben Bildfrequenz liegt kann ein Monitor das NIE darstellen => wird nie merkbar

zB.: 60 Hz ergibt 16 2/3 ms Bildanzeigeintervall, wenn die GPU mehr Zeit braucht wird das letzte Bild nochmals für ein komplettes weiteres Intervall dargestellt, oder?
=> <16 2/3 sollte sich ausgehen, kann aber mit lag daneben gehen, 8 1/3 geht sich sicher aus.

Bei 240 Hz müssten alle Zeiten geviertelt sein, um den selben Effekt zu erreichen, also 4 1/6 ms Intervall; 2 1/12ms zum sichergehen.

Meine Frage oben bezog sich dann mit monitorabhängig darauf, dass 8 ms Varianz einem 60Hz Monitor schurzegal sind, bei einem 240 Hz Monitor aber zur erneuten Darstellung des Frames führen => Ruckler

Ob der sichtbar/spürbar wäre weiß ich nicht, wenn ja müssten die Nutzer der beiden Monitore in der Grafik verschiedene Grün-Rottöne als Messlatte nehmen um flüssiges Spielen zu garantieren.

Antwort Gefällt mir

Klicke zum Ausklappem
RX480

Veteran

290 Kommentare 174 Likes

240Hz ist vllt. gleich ein zu großer Sprung für nen Vgl., idealer wäre 144Hz, weil sehr verbreitet, bzw. bei 4k auch [email protected] gebräuchlich.
(96Hz waren die Modelle mit Bandbreitenlimit)

Antwort Gefällt mir

M
Martin Gut

Urgestein

3,861 Kommentare 1,348 Likes

Die Varianz ist nicht die Frametime. Für deine Überlegungen mit der Anzeige auf dem Bildschirm sind die Frametimes entscheidend. So wie du es beschreibst, läuft es, wenn man V-Sync an hat und die FPS auf die Bildschirmfrequenz limitiert.

Die Varianz ist (wenn ich Igors Beschreibung richtig verstehe) der Unterschied zwischen aufeinander folgenden Renderzeiten (Frametimes). Ein Frame hatte beispielsweise eine Frametime von 10 ms, der nächste 19 ms. Das gäbe dann eine Varianz von 9 ms. Das zeigt, wie unregelmässig das Game läuft. Die Varianz lässt sich aber nicht mit den Zeitintervallen der Bildschirmfrequenz vergleichen.

Bitte korrigiert mich wenn ich es falsch interpretiert habe.

Antwort 1 Like

Igor Wallossek

Format©

5,773 Kommentare 8,943 Likes

Du liegst völlig richtig, es ist die Differenz zwischen zwei aufeinanderfolgenden Frame Times. Bei sehr hohen FPS-Zahlen sind kurze Drops oder Spikes auch nichts, was die Elektronic so schnell wegbügelt.

Antwort Gefällt mir

Danke für die Spende



Du fandest, der Beitrag war interessant und möchtest uns unterstützen? Klasse!

Hier erfährst Du, wie: Hier spenden.

Hier kannst Du per PayPal spenden.

About the author

Igor Wallossek

Chefredakteur und Namensgeber von igor'sLAB als inhaltlichem Nachfolger von Tom's Hardware Deutschland, deren Lizenz im Juni 2019 zurückgegeben wurde, um den qualitativen Ansprüchen der Webinhalte und Herausforderungen der neuen Medien wie z.B. YouTube mit einem eigenen Kanal besser gerecht werden zu können.

Computer-Nerd seit 1983, Audio-Freak seit 1979 und seit über 50 Jahren so ziemlich offen für alles, was einen Stecker oder einen Akku hat.

Folge Igor auf:
YouTube   Facebook    Instagram Twitter

Werbung

Werbung