News System VGA

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

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 sind oder man meinte, es vielleicht auch anders bzw. besser zu können. Wer weiß das schon?

Ich hatte schon lange vor, ein neues Powenetics-System zu bauen, das noch vielseitiger, einfacher einzurichten und mit einer viel schnelleren Abfragerate ausgestattet sein würde. Die Produktionskosten standen an letzter Stelle auf meiner Liste, da dieses System nicht für den Durchschnittsnutzer, sondern für sehr enthusiastische Nutzer oder Rezensenten gedacht ist, also ging ich am Ende, technisch gesehen, all-in.

Die ersten Entwürfe wurden geliefert, und wir begannen langsam mit dem Prozess. Die verrückte Zeit, die wir durchlebten, schränkte meine IC-Optionen ein, und wir fanden am Ende nur zwei ICs, um überhaupt ein paar Boards zu bauen. Trotz aller Widrigkeiten und Hindernisse erreichten wir die gewünschte Datenabfragerate von 1000 Samples pro Sekunde von ALLEN Sensoren, sowohl für Spannung als auch für Strom. Und Powenetics v2 hat 12 dieser Sensoren, die ATX12V und ATX12VO Netzteile unterstützen! Es gibt auch zwei 12+4 Pin PCIe Anschlüsse auf dem Board für die kommenden GPUs.

Nun zum technischen Teil: Ich wollte den High-End-IC INA228AIDGSR verwenden, aber es war nicht auf Lager! Also verwenden die ersten beiden Boards den PAC195X, der einen 16-Bit-ADC hat, im Gegensatz zum oben erwähnten 20-Bit-ADC. Das Gehirn der Karte ist eine 32-Bit-MCU, PIC32MZ, die bis zu 48 Eingänge unterstützt!

Das Wichtigste ist, dass das PMD auch von einem PCI-Extender begleitet wird, so dass es die Leistung, die der PCIe-Steckplatz liefert, mühelos messen kann. Beim ursprünglichen Powenetics mussten wir einige einzigartige und sehr teure PCIe-Erweiterungskarten kaufen, und ich wollte nicht, dass dies beim neuen System der Fall ist.

Wie ich bereits erwähnt habe, waren mir die Produktionskosten egal und ich wollte das Beste, was ich bauen konnte. Man muss also immer beachten, dass es sich um ein Laborgerät und nicht um ein „Spielzeug“ handelt. In Anbetracht der aktuellen Situation und sobald wir genügend Teile finden, um mehr zu produzieren, wird der Preis des Powenetics v2 ca, 500 Euro/Dollar betragen, ohne Mehrwertsteuer und Versand. Für diesen Betrag erhält mane das gesamte System, einschließlich aller Kabel, des PCIe-Extenders und der Software, und wir sind bereits in Gesprächen mit dem Gründer von CapFrameX, um diese fantastische App unterstützen zu lassen.

Wir wissen nicht, wann wir weitere Teile finden werden, und wir müssen das System durch unsere Evaluierungsboards optimieren und gründlich prüfen. Aber sobald wir so weit sind, werden wir damit beginnen, sie in Stückzahlen zu bauen, und wir werden das Problem der genauen Leistungsmessung in Systemen auf elegante Art und Weise lösen!

Quelle: hwbusters (Gastbeitrag von Aris)

Kommentar

Lade neue Kommentare

Zer0Strat

Veteran

151 Kommentare 116 Likes

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

Igor Wallossek

Format©

7,597 Kommentare 12,651 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

Zer0Strat

Veteran

151 Kommentare 116 Likes

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

F
FrozenPie

Neuling

4 Kommentare 0 Likes

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

Antwort Gefällt mir

Klicke zum Ausklappem
Zer0Strat

Veteran

151 Kommentare 116 Likes

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

F
FrozenPie

Neuling

4 Kommentare 0 Likes

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

Zer0Strat

Veteran

151 Kommentare 116 Likes

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

Igor Wallossek

Format©

7,597 Kommentare 12,651 Likes

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

Zer0Strat

Veteran

151 Kommentare 116 Likes

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

Igor Wallossek

Format©

7,597 Kommentare 12,651 Likes

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

Klicke zum Ausklappem
Zer0Strat

Veteran

151 Kommentare 116 Likes

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

View image at the forums

Antwort Gefällt mir

Klicke zum Ausklappem
Igor Wallossek

Format©

7,597 Kommentare 12,651 Likes

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

View image at the forums

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.

Antwort Gefällt mir

Klicke zum Ausklappem
Zer0Strat

Veteran

151 Kommentare 116 Likes

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

Klicke zum Ausklappem
Igor Wallossek

Format©

7,597 Kommentare 12,651 Likes

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

Antwort Gefällt mir

Klicke zum Ausklappem
Igor Wallossek

Format©

7,597 Kommentare 12,651 Likes

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:

View image at the forums

View image at the forums

View image at the forums

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

Klicke zum Ausklappem

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

Dr. Aristeidis Mpitziopoulos

Chief Test Engineer at Cybenetics LTD

Ph.D. in Wireless Sensor Networks
Bachelor in Computer Science and Electronics
Telecommunications Engineer Degree

Werbung

Werbung