Taxxor
Fleet Admiral
- Registriert
- Mai 2011
- Beiträge
- 19.209
Ja das Problem ist dass dadurch ja die Einträge der Liste neu erstellt werden, weil sich die verfügbaren Sensoren geändert haben.
Der Index der ausgewählten Einträge passt dann halt nicht mehr und so bleibt bisher nur ne Standard config zu nehmen.
Ich hab mir auch eine der drei Configs so zusammengestellt, dass dort wirklich nur die fps und der Capture Timer angezeigt werden, so hab ich im normalen spiel nur die FPS und die Status Zeile in der die Zeit läuft wird nur Sichtbar wenn ich aufnehme.
Die Config würde beim Wechsel der Hardware wohl auch verloren gehen, man bräuchte ein Popup Menü mit Auswahl Checkboxen für die häufigsten Dinge, wo man dann z.B. sagen kann:
"Capture Status"
"FPS & Frametimes"
"CPU Core Clocks"
"CPU Core Loads"
"CPU Total Load"
"CPU Total Power"
"GPU Clock"
"GPU Load"
"GPU Power"
und dann werden je nachdem welche Checkboxen man wählt alle Einträge ausgewählt die darauf zutreffen.
Wählt man CPU Loads aus, dann werden z.B. in meinem Fall alle 16 Einträge ausgewählt, die die Loads für die Cores angeben. So spart man sich 15 Klicks^^
@ZeroStrat Wir sollten dann einen "clear all" Button oben links reinmachen, womit man sämtliche Einträge abwählt und dann daneben diese Popup Box wo man dann diese Gruppierungen anklicken kann, die dann ausgewählt werden.
Als Standard sollten wir dann auch einfach gar keine Sensoren auswählen, sondern nur unseren Capture Status und die FPS/Frametimes.
Der Index der ausgewählten Einträge passt dann halt nicht mehr und so bleibt bisher nur ne Standard config zu nehmen.
Ich hab mir auch eine der drei Configs so zusammengestellt, dass dort wirklich nur die fps und der Capture Timer angezeigt werden, so hab ich im normalen spiel nur die FPS und die Status Zeile in der die Zeit läuft wird nur Sichtbar wenn ich aufnehme.
Die Config würde beim Wechsel der Hardware wohl auch verloren gehen, man bräuchte ein Popup Menü mit Auswahl Checkboxen für die häufigsten Dinge, wo man dann z.B. sagen kann:
"Capture Status"
"FPS & Frametimes"
"CPU Core Clocks"
"CPU Core Loads"
"CPU Total Load"
"CPU Total Power"
"GPU Clock"
"GPU Load"
"GPU Power"
und dann werden je nachdem welche Checkboxen man wählt alle Einträge ausgewählt die darauf zutreffen.
Wählt man CPU Loads aus, dann werden z.B. in meinem Fall alle 16 Einträge ausgewählt, die die Loads für die Cores angeben. So spart man sich 15 Klicks^^
Ergänzung ()
@ZeroStrat Wir sollten dann einen "clear all" Button oben links reinmachen, womit man sämtliche Einträge abwählt und dann daneben diese Popup Box wo man dann diese Gruppierungen anklicken kann, die dann ausgewählt werden.
Als Standard sollten wir dann auch einfach gar keine Sensoren auswählen, sondern nur unseren Capture Status und die FPS/Frametimes.
Zuletzt bearbeitet:
Z
ZeroStrat
Gast
Da sag nochmal einer, 24 Threads braucht keiner. ^^
Z
ZeroStrat
Gast
Ja klar, was hast du denn gedacht? 
Z
ZeroStrat
Gast
Wir arbeiten zur Zeit an einer aufgeschlüsselten Power Topologie für Nvidia Grafikkarten. Dabei geht es darum, den Verbrauch für den Chip und den Gesamtverbrauch getrennt aufzuführen. Um sicher zu gehen, dass das auch bei älteren Karten und kleineren Turings funktioniert, habe ich eine kleine Testapp erstellt, die das ganze ausliest.
Bitte führt die NvAPISample.exe einmal per Konsole (cmd) aus und teilt mir mit, was ausgegeben wird. Danke für eure Unterstützung.
Bitte führt die NvAPISample.exe einmal per Konsole (cmd) aus und teilt mir mit, was ausgegeben wird. Danke für eure Unterstützung.
Zuletzt bearbeitet von einem Moderator:
Z
ZeroStrat
Gast
Das Vorhaben wird leider nicht den erwünschten Erfolg bringen. Die Software (NvAPI) bietet zwar eine Aufschlüsselung der Power Topologie, allerdings ist die Sensoranbindung hardwareseitig gar nicht dafür ausgelegt, siehe die Ausführungen von @FormatC/Igor.
Z
ZeroStrat
Gast
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.
PL = Power Limit
TL = Temperatur Limit
VL = Voltage Limit
... als Erläuterung.
Z
ZeroStrat
Gast
Visualisierung des Power Limits.
Andere Farbe (Triadic Color), damit man es von GPU Load besser abgrenzen kann.Strange Brigade ZA4 mit Vulkan und AC on lastet die GPU übrigens permanent aus.
Andere Farbe (Triadic Color), damit man es von GPU Load besser abgrenzen kann.
Zuletzt bearbeitet von einem Moderator:
Z
ZeroStrat
Gast
@Baal Netbeck Ich würde gerne mal mit dir eine fachliche Diskussion führen. Es geht um die x% Low (Average) Metriken.
Falls du Lust und Zeit hast, was ist deine Meinung dazu?
Ich verweise als spätere Diskussionsgrundlage gleich auch mal auf einen Test von GamersNexus, damit man die Wirkung dieser Metriken an einem Beispiel verdeutlichen kann. Ich erkenne hier einige Probleme, die durch die Nachteile dieser Metriken verursacht werden.
Falls du Lust und Zeit hast, was ist deine Meinung dazu?
Ich verweise als spätere Diskussionsgrundlage gleich auch mal auf einen Test von GamersNexus, damit man die Wirkung dieser Metriken an einem Beispiel verdeutlichen kann. Ich erkenne hier einige Probleme, die durch die Nachteile dieser Metriken verursacht werden.
Baal Netbeck
Fleet Admiral
- Registriert
- Apr. 2008
- Beiträge
- 11.941
Gerne...hier im Thread oder als private Kommunikation?ZeroStrat schrieb:
Z
ZeroStrat
Gast
Gerne hier im Thread, dann können andere sich beteiligen. Hau raus, was du denkst, keine Scheu. ^^
Baal Netbeck
Fleet Admiral
- Registriert
- Apr. 2008
- Beiträge
- 11.941
Nee. 
Also ich habe den Twitter Beitrag gelesen:
" The probability that an x% low (1% low, 0.1% low) metric contains outliers is 100%. The probability that a lower percentile is distorted by outliers is significantly smaller. Because of this, the use of x% low metrics is not recommended. "
Die Aussage, dass die Xlow zu 100% Ausreißer beinhalten ist richtig....auch , dass die Percentile diese seltener beinhalten abenfalls.
Aber ich bin anderer Meinung, wenn es darum geht die XLow zu empfehlen oder nicht zu empfehlen.
Es kommt halt darauf an, was du repräsentiert haben möchtest.
Ich denke der Gamers Nexus Artikel ist ein gutes Beispiel, für einen Fall, wo die XLow ihre Stärke zeigen.
Hier enzstehen einzelnen Frametimepeaks, wenn die Engine bei zu wenigen Threads und zu hohen FPS sich verschluckt.
Die Peaks sind kein ungewollter zufälliger Ausreißer sonden ein(hoffentlich) reproduzierbares Ergebnis der Untersuchung.
Wenn man die Percentile ausgewertet hätte, waren diese heftigen Ruckler nicht in den Daten repräsentiert gewesen.
Was sind für dich die Nachteile?
Also ich habe den Twitter Beitrag gelesen:
" The probability that an x% low (1% low, 0.1% low) metric contains outliers is 100%. The probability that a lower percentile is distorted by outliers is significantly smaller. Because of this, the use of x% low metrics is not recommended. "
Die Aussage, dass die Xlow zu 100% Ausreißer beinhalten ist richtig....auch , dass die Percentile diese seltener beinhalten abenfalls.
Aber ich bin anderer Meinung, wenn es darum geht die XLow zu empfehlen oder nicht zu empfehlen.
Es kommt halt darauf an, was du repräsentiert haben möchtest.
Ergänzung ()
Ich denke der Gamers Nexus Artikel ist ein gutes Beispiel, für einen Fall, wo die XLow ihre Stärke zeigen.
Hier enzstehen einzelnen Frametimepeaks, wenn die Engine bei zu wenigen Threads und zu hohen FPS sich verschluckt.
Die Peaks sind kein ungewollter zufälliger Ausreißer sonden ein(hoffentlich) reproduzierbares Ergebnis der Untersuchung.
Wenn man die Percentile ausgewertet hätte, waren diese heftigen Ruckler nicht in den Daten repräsentiert gewesen.
Ergänzung ()
Wie siehst du das denn?ZeroStrat schrieb:
Was sind für dich die Nachteile?
Zuletzt bearbeitet:
Z
ZeroStrat
Gast
Danke schon mal für deine Ausführungen. Ich werde später noch ein wenig weiter ausholen. Erstmal ein paar andere Sachen erledigen. ^^
Zuletzt bearbeitet von einem Moderator:
Z
ZeroStrat
Gast
@Baal Netbeck Hab auch noch mal ein wenig bei einem Spaziergang in der Sonne die Gedanken kreisen lassen. Die Sache ist tatsächlich komplexer als man denkt. Nehmen wir mal zwei Kontexte/Perspektiven an, aus denen heraus wir das betrachten.
1. Man misst die Frametimes das eigenen Systems. Vergleiche mit anderen Systemen sind dabei uninteressant. Der Ist-Zustand mit allen Macken ist der Gegenstand des Interesses. Ausreißer/Spikes im Frametime Graphen können ein völlig normales Verhalten sein. Man will das gesamte "Spektrum" in den Messungen beobachten können, um eventuelle Probleme mit diversen Komponenten analysieren zu können. In diesem Fall sollen die x% Low Metriken alles abbilden, was tatsächlich passiert, auch wenn's richtig "häßlich" ist.
2. Man will die (tatsächliche) Leistung einer Komponente ermitteln, weil man ein Ranking aufstellen will. Wir haben also das klassische Testszenario. Ausreißer sollen die Leistungswerte idealerweise nicht verfälschen. Wir machen die Annahme, dass ein moderner PC ein dermaßen komplexes System ist, dass wir von stochastischen Einflüssen ausgehen müssen.
Es gibt zwei unterschiedliche Ausreißertypen. Hier mal Beispiele von 3 aggregierten Runs. Ein Run hat 20 Sekunden.
A. Nichtreproduzierbare Ausreißer im Frametimegraphen, Beispiel (nur Run 1 ist betroffen): https://capframex.com/sessioncollections/990c0868-1f78-4459-8d74-a4efcd1c3089
B. Reproduzierbare Ausreißer im Frametimegraphen, Beispiel (alle Runs sind betroffen): https://capframex.com/api/SessionCollections/dcccfc8c-d5b8-48d8-b75f-817479249a6c
Betrachten wir Fall B, können wir wegen der Reproduzierbarkeit davon ausgehen, dass das Verhalten entweder von Hardware oder von der Software kommt. In jedem Fall wäre x% Low konsistent.
Fall A versalzt einem aber die Suppe. Wir haben Inkonsistenz. Im Sinne der Gesamtkonsistenz dürfen wir Fall A und B in ein und dem selben Test keinesfalls kombinieren, andernfalls wird das gesamte Set inkonsistent.
Die logische Konsequenz ist, dass die x% Low Metriken aus Konsistenzgründen nicht verwendet werden dürfen, um ein Ranking zu erstellen. In der Praxis wird man letztlich immer A und B vorliegen haben.
Irgendwelche Denkfehler?
1. Man misst die Frametimes das eigenen Systems. Vergleiche mit anderen Systemen sind dabei uninteressant. Der Ist-Zustand mit allen Macken ist der Gegenstand des Interesses. Ausreißer/Spikes im Frametime Graphen können ein völlig normales Verhalten sein. Man will das gesamte "Spektrum" in den Messungen beobachten können, um eventuelle Probleme mit diversen Komponenten analysieren zu können. In diesem Fall sollen die x% Low Metriken alles abbilden, was tatsächlich passiert, auch wenn's richtig "häßlich" ist.
2. Man will die (tatsächliche) Leistung einer Komponente ermitteln, weil man ein Ranking aufstellen will. Wir haben also das klassische Testszenario. Ausreißer sollen die Leistungswerte idealerweise nicht verfälschen. Wir machen die Annahme, dass ein moderner PC ein dermaßen komplexes System ist, dass wir von stochastischen Einflüssen ausgehen müssen.
Es gibt zwei unterschiedliche Ausreißertypen. Hier mal Beispiele von 3 aggregierten Runs. Ein Run hat 20 Sekunden.
A. Nichtreproduzierbare Ausreißer im Frametimegraphen, Beispiel (nur Run 1 ist betroffen): https://capframex.com/sessioncollections/990c0868-1f78-4459-8d74-a4efcd1c3089
B. Reproduzierbare Ausreißer im Frametimegraphen, Beispiel (alle Runs sind betroffen): https://capframex.com/api/SessionCollections/dcccfc8c-d5b8-48d8-b75f-817479249a6c
Betrachten wir Fall B, können wir wegen der Reproduzierbarkeit davon ausgehen, dass das Verhalten entweder von Hardware oder von der Software kommt. In jedem Fall wäre x% Low konsistent.
Fall A versalzt einem aber die Suppe. Wir haben Inkonsistenz. Im Sinne der Gesamtkonsistenz dürfen wir Fall A und B in ein und dem selben Test keinesfalls kombinieren, andernfalls wird das gesamte Set inkonsistent.
Die logische Konsequenz ist, dass die x% Low Metriken aus Konsistenzgründen nicht verwendet werden dürfen, um ein Ranking zu erstellen. In der Praxis wird man letztlich immer A und B vorliegen haben.
Irgendwelche Denkfehler?
Baal Netbeck
Fleet Admiral
- Registriert
- Apr. 2008
- Beiträge
- 11.941
Stimme ich zu.ZeroStrat schrieb:
ZeroStrat schrieb:
ZeroStrat schrieb:
ZeroStrat schrieb:
Gegenargument....wenn einer der Runs so einen Frametimepeak aufweist, dann war die Testszene/Umgebung nicht gut gewählt....oder die Messung dürfte nicht benutzt werden.ZeroStrat schrieb:
Manuell Runs auszusortieren bringt einen persöhnlichen Bias in das Ergebnis, den man wenn möglich vermeiden sollte.
Daher bin ich dazu übergegangen mehr Messungen zu machen und mein Programm automatisch Messungen auszusortieren zu lassen.
Mache ich 4 Messungen, wird nur der Mittelwert von drei der Messungen benutzt....die mit den schlechtesten 0.1%low Frametimes, wird ignoriert.
Bei 5 Messungen ignoriere ich den Run mit den besten avg FPS.... Den hier kann ein höherer Boost Takt oder ein Fehler des Testers(z B. Kamera zu hoch positioniert), das Ergebnis verfälschen.... Und dann natürlich noch der schlechteste 0.1%XLow von den verbliebenen 4.
Das gleiche bei 6 Runs, und bei 7 ... bei 8 Runs ignoriere ich die 2 schlechtesten XLow.... Und natürlich den besten avg FPS wie vorher.
Optimalerweise wiederholt man die Messungen an einem zweiten Tag um diese zu verifizieren.... Zumindest wenn man Zweifel an dem Ergebnis hat.
Macht man nur 3, hat man natürlich wenig Spielraum.
Sofern die Szene gut gewählt wurde.... Und das sollte sie sein, wenn man nicht nur für sich selbst einen Überblick möchte, sondern eine Veröffentlichung plant....sollte man sich mit möglichen Ausreißern beschäftigt haben.
Treten sie nur sehr selten auf, oder sind unabhängig durch einen Hintergrundprozess entstanden, sollte meine Methode sie rausfiltern.
Ist eine ganze Messreihe durch einen längeren Hintergrundprozess versaut, muss man auf die Nachmessung am anderen Tag hoffen.
Treten sie regelmäßig auf (fall B), sollte man sie meiner Meinung nach auch im Ergebnis sehen.... Die percentile könnten sie ignorieren.
Treten sie statistisch verteilt, aber reproduzierbar häufig auf, muss man eventuell die Dauer jeder einzelnen Messung verlängern um zuverlässig eine handvoll von ihnen zu erfassen... Die besonders unglücklichen Messungen sortiert dann wieder das Programm aus.
Und selbst wenn das alles nicht hilft.... Und weiterhin eine der Hardware konfigurationen aus reinem Pech heraus benachteiligt wird....weil da totzdem eine der ausgewerteten messungen einen Peak aufweist....dann sieht man das zumindest am Fehler.
Das ist der Grund warum ich skeptisch gegenüber dem Zusammenfassen der gemachten Messungen bin.
Man kann keinen Fehler bilden.
Habe ich hingegen Fall A und ich werte die drei Runs individuell aus....bilde den Mittelwert und die Standardabweichung der XLows, dann wird der Fehler extrem groß werden.....dann muss man entweder nochmal messen, oder zumindest sieht jemand in der Veröffentlichung, welche Werte reproduzierbar waren, und welche fragwürdig.....gesetzt den Fall man zeigt Fehlerbalken.
So macht gamers Nexus das ... Sie machen erst 4 Messungen und bilden die Standardabweichung.... Und wenn die schlecht ist, dann fügen sie mehr Messungen hinzu, bis sie zufrieden sind.... Oder eben nicht.... Aber dann hat man wenigstens den Fehlerbalken.
Irgendeinen Tod muss man sterben... Viel Zeitaufwand für bessere Werte... Oder größere Fehlerbalken..... Oder das Eingeständnis, dass man es trotz viel Zeitaufwand nicht reproduzierbar messen konnte..... Dann ist man wieder bei meinen ersten Argument, dass die Gegebenheiten nicht gut genug waren.....entweder man verbesset sie mit einem besseren Ablauf oder man zeigt das entsprechende Spiel nicht.
Baal Netbeck
Fleet Admiral
- Registriert
- Apr. 2008
- Beiträge
- 11.941
Zum Beispiel.Esenel schrieb:
Ähnliche Themen
