Powenetics v2: Die Zukunft der einfachen GPU/CPU/Systemleistungsmessung

Redaktion

Artikel-Butler
Mitarbeiter
Mitglied seit
Aug 6, 2018
Beiträge
1.751
Bewertungspunkte
8.481
Punkte
1
Standort
Redaktion
Ich habe das erste Board für Leistungsmessungen lange vor der Veröffentlichung von Nvidias PCAT gebaut. Nvidia hatte etwa ein Jahr vor der Veröffentlichung von PCAT auch ein Powenetics-System gekauft, um es zu studieren. Und man hat mich dort irgendwie aus den Augen verloren, also schätze ich, dass die Dinge für sie nicht wie erwartet gelaufen (read full article...)
 
Hab mit Aris schon über die Details diskutiert. Ich freu mich drauf, die Anbindung der Telemetriedaten in CX zu integrieren. Ich werde ein eigenes "PMD" Tab erstellen, was Echtzeitmonitoring erlaubt, ähnlich zu PCAT und dann gibt's natürlich die Daten noch auf dem Game Overlay und mit den Frametimes synchronisiert in unseren Json Files abgelegt.
 
Ich weiß, wir reden ja fast täglich miteinander :)

Fürs Echtzeit-Monitoring wünschte ich mir aber schlanke CSV Dateien, denn wenn Aris bis zu 1 ms ausliest, dann hätte ich das auch gern in einem üblichen Datenformat. JSON ist tonnenweise Overhead, den im Monitoring keiner braucht. Also ich würde es dann z.B. nicht benutzen, weil es viel zu aufgebläht ist. Gut für Lesezeichen, aber nichts für 64k und mehr Datenzeilen ;)
 
CSV haben wir eh bereits als Zusatzoption, nur muss man sich dann überlegen, wie man damit umgeht, dass man stets mehr PMD Samples als alles andere hat, insbesondere auf die Frametimes bezogen. Auch so was wie GPU Usage kann man nicht mit 1ms vom Treiber abfragen.

Dadurch, dass Json kein festes, tabellarisches Format hat, kann man Daten flexibel abspeichern und dann über Zeitstempel grafisch mappen oder gegebenenfalls mit Interpolation "auffüllen".
 
Zuletzt bearbeitet :
@Zer0Strat
Diesbezüglich mal eine Frage aus der Berufs-Ecke Performance-Monitoring:
Wäre für die Ablage anstatt JSON oder CSV (diese Formate nutzt man eigentlich nur, wenn man die Daten auch für Menschen direkt in den Dateien lesbar ablegen will) nicht ein binäres Format wie z.B. Apache Parquet besser geeignet?
Parquet ist ein spaltenorienties binäres Dateiformat, dessen Aufbau als Daten auf der Platte gleich dem Format im Arbeitsspeicher ist (dadurch auch eigentlich ideal für Dinge wie Performance-Daten), weshalb es extrem schnell beim lesen und schreiben ist, wobei auch direkt im Format intgerierte Kompression mit mehreren Formaten möglich ist. Ich bevorzuge ZSTD, da damit unsere 3GB CSV mit 30 Mio. Zeilen Messdaten auf 400-500MB komprimiert werden können, was als netten Nebeneffekt auch ein noch schnellere Lesen/Schreiben als unkomprimiert ermöglicht auf einer NVMe SSD, da man weniger am I/O hängt, natürlich auf Kosten etwas höherer CPU- und RAM-Last.
Für beides gibt es Implementierungen bzw. Bibliotheken und Schnittstellen für verschiedene Programmiersprachen, wobei ich persönlich die Bibliothek "pola-rs" in Rust und Python nutze.
 
Zuletzt bearbeitet :
Diesbezüglich mal eine Frage aus der Berufs-Ecke Performance-Monitoring[...]
Klar, binary Formate sind immer besser, wenn es um I/O-Performance geht. Die Sache ist allerdings, dass die Realtime-Performance in CapFrameX nicht an der I/O-Performance hängt. Wir halten die Daten im Arbeitsspeicher. Erst wenn der Anwender bestimmte Events triggert, werden die Daten in Dateien gespeichert. Formate wie Json oder CSV haben zudem den Vorteil, dass Dritte die Daten ohne "wilde API-Schlachten" importieren können.
 
Zuletzt bearbeitet :
Klar, binary Formate sind immer besser, wenn es um I/O-Performance geht. Die Sache ist allerdings, dass die Realtime-Performance in CapFrameX nicht an der I/O-Performance hängt. Wir halten die Daten im Arbeitsspeicher. Erst wenn der Anwender bestimmte Events triggert, werden die Daten in Dateien gespeichert. Formate wie Json oder CSV haben haben zudem den Vorteil, dass Dritte die Daten ohne "wilde API-Schlachten" importieren können.
Okay, das ist natürlich ein Argument :)
Dachte nur im Bezug darauf, wenn man viele Daten mit einer Sampling-Rate von 1000 pro Sekunde direkt auf die Festplatte schreiben möchte um nicht den Arbeitsspeicher in kürzester Zeit zu füllen, dass ein binäres Format dann vielleicht Sinn machen würde und man CSV/JSON dann nur noch explizit für den Datenexport anbietet. Das abspeichern von (komprimierten) binären Daten würde dann auch den verbrauchten Plattenplatz und damit die (Langzeit-)Archivierung vereinfachen bzw. auch das generelle Laden/Speichern von großer Datenmengen von/auf der Fesplatte beschleunigen.
 
Gut, man muss sich das schon überlegen, ob man am Ende nicht doch ein Binary Format nimmt. Dabei geht's dann eher um das Lesen der Dateien.

Angenommen, man zeichnet 10 Minuten mit 1000 Samples/Sekunde auf, dann erhält man 4 byte * 12 Channels (max) * 1000 * 60 * 10 = 28800000 byte = 28,8MB an Daten. Hat man 10-20 Dateien im Ordner, kann das Laden dauern, weil alles geparst werden muss.
 
Binary muss man doch nicht groß parsen. Wenn ich mit einer intelligent gestalteten Struct arbeite, kann ich den ganzen Block mit einem Happs in den Speicher schieben. Das ist reichlich elegant und zudem extrem fix.

Beim Monitoring in CapFrameX kommts doch auf die Frames an, nicht pauschal auf Aris' 1ms Daten. Man generiert die True RMS Kumulation immer nur dann, wenn ein Frame abgepeichert wird, das mache ich ja auch nicht anders. Ich lasse solange laufen, bis wieder eine Grafikzeile fällig wird und errechne dann den Mittelwert der bis dahin aufgelaufenen Leistungsaufnahme und setze das danach wieder zurück. Interpolieren ist Käse. :)
 
Ich meinte auch Parsen von Json Files. Filter usw. braucht man fürs Overlay und vielleicht auch für die Graphen, wenn die Samples pro Anzeigeintervall zu viel werden. Mal schauen, aber ich würde schon gerne die Rohdaten abspeichern, damit man alle Peaks hat. Frametimes kommen ja sehr unregelmäßig, das würde ich einfach über Timestamps (QueryPerformanceCounter) syncen. Hatte Intel damals gebeten, das in PresentMon zu integrieren. Würde ich auf jeden Fall dafür nutzen.
 
Für die normale Protokollierung hat Aris ja seine eigene Software, hier ging es m.E. eigentlich darum, dass Aris nicht noch anfangen muss, auch noch PresentMon zu implementieren. Für die Zielgruppe der Benchmarker sind kumulierte TRMS Werte doch völlig ausreichend und die fiesen Spikes (3x lt PCIe 5 Erweiterung) hast Du auch in der einen ms nicht drin. Lass doch die Aris-Werte in einen Stack laufen und rufe das immer dann ab, wenn Du eh einen Frame schreibst. JSON fände ich schade, weil ich dann wieder eine eigene Software schreiben muss. Oder einen Parser, was quasi aufs Gleiche rauskommt. Alle schreiben CSV files, ob nun HWInfo, Powenetics oder PCAT (oder meinetwegen auch ein paar Spiele). Da muss man nicht das Rad neu erfinden und so eine Overheadwalze auf die Leute loslassen. Optional CSV wäre ungemein praktisch. Und ist in wenigen Minuten geschrieben/implementiert) :)

CSV muss ich nicht mal parsen. Das kann man in einem Stück einlesen, am Umbruch splitten und dann am Delimiter. Alles im RAM. Geht schön fix und einfach :)
 
@Igor Wallossek Hab das gestern konzeptionell überflogen. Es wird auf jeden Fall beides geben. Json mit Rohdaten und CSV mit PMD-Daten auf Frametimes gemappt (kumuliert). Das ganze ist über die App-Settings steuerbar. Die Optionen gibt es sogar bereits.

Mit einem reinen Kumulierungsansatz hat man übrigens nicht den allgemeinen Fall abgedeckt. Frametimes können sogar mit einer höheren Rate gepusht werden als Samples vom PMD kommen, siehe Bild unten mit über 5000 FPS. Dann muss man interpolieren. Ich muss erstmal einen Algorithmus entwickeln, der gleichzeitig interpolieren und kumulieren kann. ^^ Wird übrigens nicht in Echtzeit passieren über einen Stack oder so, weil die Frametimes von PresentMon zwar regelmäßig getrackt (ETW), aber unregelmäßig gepusht werden. Man kann das sogar als wellenförmig bezeichnen. Ist aber kein Thema, da das PMD Tab nur Telemetriedaten in Echtzeit visualisieren wird. Mapping gegen Frametimes über QPCTime läd man dann offline.

1655802126254.png
 
Zuletzt bearbeitet :
Naja, sagen wir es mal so:
Die Zielgruppe des 500-Euro-Equipments von Aris ist nicht ganz die der OSD-Fetischisten. Also bevor Du die PMD-Daten-Armada ins OSD presst, ist ein sinnvollen Speichern in einer einzigen CSV-Datei sicher zielführender und einfacher Umzusetzen. Bei zwei Dateien mit Zeitstempel wäre man ja wieder genau dort, wo Aris jetzt auch schon ist. Ich arbeite bei den Scope-Messungen und meinem selbst gebauten PMD ja ähnlich und mir geht das Timestamp-Gefrickel mittlerweile echt auf den Sack. ;)

1655804595579.png

Die meisten brauchen z.B. die ganzen Metriken nicht, nur Dateien mit den Frame Times und den paar PMD Values in einer Zeile zum Weiterverarbeiten. Du kennst ja meine Charts und da kann und will ich auch nicht wechseln, weil ich weit detaillierter auswerte und vor allem auf eine gemeinsamen Time-Line für alle Karten für die optische Ausgabe zugreifen kann. Mit unseren Templates arbeiten mittlerweile einige große Redaktionen weltweit, denen aber FrameView und PCAT nicht mehr reichen und die sich auch das Tool von Aris leisten können und wollen ;)

Aber ehe sich jetzt Aris das PresentMon-Zeug in seine Software implementiert, ist die Lösung über CapFrameX mit Sicherheit simpler und schneller umzusetzen.
 
Die Zielgruppe des 500-Euro-Equipments von Aris ist nicht ganz die der OSD-Fetischisten. Also bevor Du die PMD-Daten-Armada ins OSD presst, ist ein sinnvollen Speichern in einer einzigen CSV-Datei sicher zielführender und einfacher Umzusetzen.
Haha, beim OSD war ich ja noch gar nicht. 😁 Ich bin erst bei der Visualisierung auf dem PMD Tab, ähnlich wie das bei PCAT läuft. Line-Graphs, Sliding Windows usw...

Aber wie gesagt, es wird die Option geben: PresentMon Frametime-Daten und PMD-Daten zeilenweise gemappt in einer einzigen CSV Datei. Aber man kommt um QPCTime-Stamps Schlachten nicht herum. Du musst am Ende zwei Datenströme synchronisieren, die völlig unterschiedlich gesampelt werden und dazu noch unregelmäßig (Frametimes).

Wenn man das entkoppelt, ist es leichter. Du synchronisierst einfach die Startzeiten und dann kannst du das in einem Graphen plotten, fertig. Wie dicht die Punkte dann liegen, ist völlig egal. Das ermöglicht dann die Json Datei.
 
Zuletzt bearbeitet :
Die Graphen sind ja nur Optik und eigentlich komplett überbewertet. Ich mache zwar auch Charts mit Kurven, aber sind wir mal ehrlich: bei 900 Pixeln für so einen Plot (mein Template für die Webseite nutzt nur 980 Pixel für die Contentbreite) bleibt von der Genauigkeit absolut nichts übrig. ;)

Bei der Übergabe vom Interpreter zu den Templates übertrage ich spalten- und zeilenweise sowohl die Roh-Daten, als auch bereits die vorab aufbereiteten interpolierten/extrapolierten Kurven mit reinem Show-Wert (Excel ist für sowas zu langsam). Für mich stehen aber andere Auswertungen im Vordergrund, wie die Varianzen und die Frame Times als Balkendiagram mit echter statistischer Auswertung. Da die zeitliche Länge des jeweiligen Benchmarks bekannt ist, muss ich auch keine Timestamps synchronisieren. Hier reichen identische Anfang-Ende-Betrachtungen, wenn es zur Leistungsaufnahme und deren Auswertung über die Zeit geht. Deshalb kann ich sowohl die Daten aus FrameView mit gleicher Länge wie die Frames, als auch die aus den Scope-Messungen nutzen (auch schon mal mehrere Hunderttausend vs. z.B. 30k für den Benchmark). Ich mache dann für den Endwert TrueRMS über den Zeitraum, der Plot ist eine simple Vereinfachung und eh ohne echte Aussagekraft.

Ich kann zudem alle Benchmark-Templates in einem Verzeichnins zur automatischen Kumulation heranziehen und bekomme dann Auflösungs-bereinigt z.B. 15 Spiele gemittelt auf Knopfdruck als Gesamtergebnis in die Balken-Diagramme. Müsste man das von Hand machen, dann Gute Nacht :D
 
Das läuft bei uns dreistufig vom Interpreter (als Arbeitstier und Aufbereiter) über die Einzelspiele samt Metriken (autmatisch gefüllte Excel Templates mit dynamisch angepassten Makros) bis hin zur automatischen Kumulation aller Spiele und Auflösungen (auch Excel, ferngesteuert) samt Charts-Export und Upload:

1655873598664.png


1655873615065.png


1655873630542.png

Mein Wunschtraum (und Plan) sind interaktive Grafiken für die Webseite, die sich per Knopfdruck auch generieren und hochladen lassen. Leider fehlt immer wieder die Zeit, um das auch mal endlich fertig zu bekommen, ohne die lästigen Google-Tools zu nutzen.
 
So etwas nennt sich in der Elektrotechnik schlicht und einfach Flanke. Verlängert man den FPS-Drop exakt nach oben, ist es genau der Anfang vom Leistungsabfall, bei der Leistung ist es genau umgekehrt. Das wird NIE zu 100% senkrecht sein, dann müsstest Du schon die Caps auslöten. Aber es ist klar, dass alles andere Mist ist und nur Deins zählt. Würde es anders aussehen, als das hier, würde ich mir schon eher Gedanken machen. Würde sich das aufgrund zu geringer Auflösung nämlich komplett decken, dann wäre es so ungenau, dass die Flanken gleich ganz verschwinden.

So wird das nichts, ich bin jetzt raus hier. :D

1655901899268.png

Schon mal den Delay zwischen GPU, Spannungswandlern und Netzteil gemessen? Viel Spaß damit :)
 
Selbst wenn du die Kapazitäten auslötest, wird es in der Realität niemals senkrecht werden, da dies unendlichem Leistungsumsatz entsprechen würde. Irgendwo sitzen immer parasitäre Impedanzen, Leitungen z. B. Aber schon durch das zeitliche Sampling bekommt man ja eine gewisse endliche Steigung.
 
Zuletzt bearbeitet :
Aber es ist klar, dass alles andere Mist ist und nur Deins zählt. Würde es anders aussehen, als das hier, würde ich mir schon eher Gedanken machen. Würde sich das aufgrund zu geringer Auflösung nämlich komplett decken, dann wäre es so ungenau, dass die Flanken gleich ganz verschwinden.
Hab das gerade mit Igor per Skype geklärt, mein Beitrag war positiv gemeint und ist dementsprechend fehlinterpretiert worden.

Ich bin ehrlich gesagt verwundert, dass das der Fall ist. Ich bin immer sehr direkt und würde Kritik daher nicht ironisch formulieren. Es wäre wünschenswert, etwaige Vorurteile gegenüber meiner Person zu überdenken. Mehr ist dazu nicht zu sagen.
 
Oben Unten