CapFrameX (CX) - Frametime Capture und Analyse Tool

[gaussmath]

Ja, die Werte sind Murks. Ich habe jetzt sogar noch zusätzlich "Power Usage in PCM" für die unterschiedlichen Domains gecheckt. Das macht überhaupt keinen Sinn, wenn man bedenkt, dass Delta = Board - GPU bis zu 40 Watt und mehr ausmachen kann.

Dass die Werte vertauscht sein könnten, ist es auch nicht, siehe meine mehrmalige Abfrage der Werte auch unter Last.


Ich muss Nvidia erstmal kontaktieren. Solche Fantasiewerte baue ich nicht in die Software ein.

 

[gaussmath]

Igor hat auch noch was dazu geschrieben. Hardwareseitig sind die Sensoren gar nicht dafür ausgelegt. Das Vorhaben müssen wir wohl oder übel begraben. Ist schade, nützt aber nichts.

Ich hoffe, dass AMD irgendwann mal auch auf die Board-Power geht.

 

[KaterTom]

Okay, dann bleibt mehr Zeit für andere optimierungen. Ich hätte gerne noch den Takt der CPU Kerne in den Sensor Statistics. Gerade beim Ryzen interessant!

 

[gaussmath]

Ich hätte gerne noch den Takt der CPU Kerne in den Sensor Statistics. Gerade beim Ryzen interessant!

Wir haben zwei y-Achsen in dem Graphen. Eine Achse ist für Frametimes/FPS und die rechte Achse ist für %-Werte. Dann bräuchten wir ja noch eine 3. Achse, um den Takt auftragen zu können. Hmmm... ^^

 

[KaterTom]

Was denn für Achsen? Ich meine die Zahlen im Sensor Tab auf der Analysis Seite. Da wo CPU Auslastung, GPU Auslastung uund Temperaturen stehen. Also ich möchte Zahlen, keine Kurven.

 

[gaussmath]

Dir reichen Zahlen, also Min, Max und Average? Will man nicht den Verlauf des Taktes sehen?

 

[KaterTom]

Ja, mir reichen Zahlen. Wie hoch boosten die einzelnen Kerne maximal unter Last und welcher Takt liegt die meiste Zeit an?

Und sorry, dass ich manchmal so spät antworte, das sieht unhöflich aus, aber ich bin sozusagen die ganze Woche unterwegs und kann nicht jederzeit schreiben.

 

[gaussmath]

So, ich habe die Tage die Sensoranbindung für Nvidia Karten komplett überarbeitet. Ich habe nun alles aus der NvAPI rausgequetscht, was wirklich interessant ist. Hier mal als Beispiel alle Stats für die GPU und den Rest deaktiviert.

PL = Power Limit
TL = Temperatur Limit
VL = Voltage Limit

... als Erläuterung.

 

[gaussmath]

@KaterTom: Ich habe das jetzt mal implementiert mit dem Takt. Eine eindeutige Sache ist es allerdings nicht. Nimmt man jetzt den mittleren Takt oder den minimalen/maximalen? Ich habe mich für den Max Boost/Takt entschieden. Anbei ein Beispiel mit meinem i9 mit festem Takt. Das Takt kann mit dem eingestellten PL in Gaming Workloads gehalten werden, deshalb gibts keinen Unterschied zwischen Min/Max/Average.

 

[KaterTom]

Danke! Selbst ausprobieren kann ich das erst am Wochenende.

 

[sentinel1]

Hier mal ein Test mit G-Sync:

https://capframex.com/api/SessionCollections/677194d7-5977-40ee-9ba9-74a6e53e0cf6

Ich denke mal, dass es gut aussieht, natürlich bremst die CPU enorm, dafür kann ich aber quasi lüfterlos spielen, der GPU-Lüfter dreht erst ab 81°C von 0 auf 49 Prozent hoch.

 

[gaussmath]

Ich denke mal, dass es gut aussieht, natürlich bremst die CPU enorm, dafür kann ich aber quasi lüfterlos spielen, der GPU-Lüfter dreht erst ab 81°C von 0 auf 49 Prozent hoch.

Rund 70 FPS beim P0.2 würde ich nicht unbedingt gut finden in CS:GO. Vielleicht doch besser mal den Kühler anwerfen... ^^

 

[sentinel1]

Mit Lüfter war es nicht besser, es ist halt ein CPU - Spiel.

https://capframex.com/api/SessionCollections/c2ddf449-5769-4da2-97e4-f5acbdfd7743

 

[McZonk]

Ich beschäftige mich gerade in v. 1.5.1 eingehend mit der Run-Aggregation. Ich lasse dabei 3 Wdh.-Läufe mit jeweils 20 Sekunden Laufzeit zusammenfassen und lege dabei immer auch alle Einzelläufe im Tool ab ("save aggregated runs only" ist deaktiviert).

Was mir in dem Kontext aufgefallen ist: Lauf Nr. 1 + 2 (0 - 20 Sek.) differenzieren von der Laufzeit von Lauf Nr. 3 (40-60 s). Der aggregierte Lauf hat eigentlich wie erwartet 60 Sek. Laufzeit (3x 20 Sek). Ist die variierende Laufzeit bei den Einzelläufen aber so gewollt?

​

 

[gaussmath]

Mahlzeit Zonk,

die Aggregationsmethode ist tatsächlich tief durchdacht und diskutiert worden im Team. Das sind Vorteile:

• durch Verkettung der Frametimes werden diese unverfälscht dargestellt
• gemittelte Frametimes würden ohne diesen Ansatz hinsichtlich Peaks/Ausreißern geglättet dargestellt werden -> Informationverlust
• die Berechnung des Mittelwertes ist math. korrekt (Mittelwert der Mittelwerte ungleich Mittelwert der aggregierten Frametimes)
• Perzentile werden konsistenter bezgl. Ausreißern behandelt, P1 von 40 60 60 ist nahezu 60

Die Antwort ist also: ja. Das ist voll beabsichtigt. Das Prinzip lässt sich auch schön so zusammenfassen: Die Frametimes werden so darstellt, als würdest du die selbe Szene in unmittelbarer Folge dreimal hintereinander ablaufen.

Grüße, gm

 

[McZonk]

Hi Gauss,

danke für dein schnelles Feedback. Soweit so verstanden ( zumindest was das aggregierte Result anbelangt).

Aber ich glaube mein Aua ist noch nicht klar rübergekommen:

Run1 (Einzelergebnis) hat 0...20 Sek. Laufzeit auf der x-Achse
Run2 (Einzelergebnis) hat 0...20 Sek. Laufzeit auf der x-Achse
Run3 (Einzelergebnis) hat 40...60 Sek. Laufzeit auf der x-Achse
-----------------------------------------------------------------------------
Ges. (Aggregiert) hat 0...60 Sek. Laufzeit auf der x-Achse.

Mir ging es maßgeblich um das Rot.

 

[gaussmath]

Autsch, das ist ein Bug! Sorry für die lange Leitung. Aber war doch mal interessant ein paar Hintergründe und so... Taucht der Bug immer auf? Ist das reproduzierbar?

 

[McZonk]

Alles gut, ich steh auf technische und statistische Hintergründe! Da ich es auch noch nie losgelassen habe an dieser Stelle nochmal ein ganz großes Lob für Eure Arbeit. Da lupfe ich echt die Kappe!

Hab gerade noch einen Witcher3-Lauf probeweise nachgeschoben gehabt - Sieht reproduzierbar aus.

 

[gaussmath]

Jut, Bug identifiziert, Fix incoming... Danke fürs Reporten!

 

[gaussmath]

Was machst du für Sachen Zonk? Ich kann den Bug nicht reproduzieren. Wahrscheinlich hat Taxxor oder Nafi das schon behoben?! Teste mal bitte diese Beta (v1.5.2): Index of /release__1.5.2/23.05.2020