Powenetics v2: The Future of simple to use but exact GPU/CPU/System Performance Measurement

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.

Antwort 6 Likes

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 ;)

Antwort 1 Like

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".

Antwort Gefällt mir

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.

Antwort Gefällt mir

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.

Antwort Gefällt mir

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.

Antwort Gefällt mir

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. :)

Antwort Gefällt mir

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.

Antwort Gefällt mir

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 :)

Antwort Gefällt mir

@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.

Antwort Gefällt mir

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.

Antwort Gefällt mir

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:

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.

Antwort Gefällt mir

Sehr schön, hieran sieht man dass du sauber gesynct hast. ^^

Antwort Gefällt mir

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

Schon mal den Delay zwischen GPU, Spannungswandlern und Netzteil gemessen? Viel Spaß damit :)

Antwort Gefällt mir

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.

Antwort Gefällt mir

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.

Antwort Gefällt mir