CapFrameX - Capture und Analyse Tool

[ZeroStrat]

Version 1.2.1.5 Beta:

• Auswählbarer Sound Mode direkt auf der Capture Seite
• Logger für diverse Delays

 

[Taxxor]

@ZeroStrat habe extra The Division 2 genommen, wo ich 80% CPU Auslastung habe. Der allererste Sound hat gute 2 Sekunden gedauert, alle anderen wieder eine halbe bis eine.
Aber laut den Logs sieht alles gut aus und auch mein Aufnahmedelay ist nicht allzu hoch(hätte gedacht mit meiner CPU und so einer Auslastung wäre es viel höher als bei dir)

 

[ZeroStrat]

Achso, ich messe das Loading von der Festplatte. Das Play geschieht dann asynchron und kann bliebig versetzt stattfinden. Leider kann ich das nicht messen. In meiner Messung ist übrigens sogar das mediaPlayer.Play() enthalten!!

@Taxxor Meinst du, dass es notwendig ist, den Delay bis zum ersten Element des PresentMon Streams noch weiter zu optimieren?

 

[Taxxor]

@Taxxor Meinst du, dass es notwendig ist, den Delay bis zum ersten Element des PresentMon Streams noch weiter zu optimieren?

Also wenn ich das bisher richtig verstanden habe, dann ist es ja sowieso immer noch der Fall, dass die Frametime, die als erstes um Punkt X übertragen wird, durch das asynchrone übertragen von Presentmon sowieso möglicherweise eine Frametime aus X-(n)s sein kann. Dieser Umstand hilft in dem Fall ja sogar, indem er das Delay ein Stück weit ausgleicht.

Aufgrund der Delays oben aus dem Screenshot würde ich jetzt mal sagen, es müssten schon ausgerechnet genau innerhalb dieser 300ms Versatz Frametimes liegen, die komplett vom average abweichen, um einen Einfluss auf die Werte zu haben. Und wenn der Versatz 300ms beträgt, können auch gar nicht so viele Ausreißer darin PLatz finden, d.h. selbst wenn es Frames sind, die viel höher als der average sind, wären es nur 2-3 Stück für die ganze Aufnahme.
Außerdem hat man, wenn man mit mehreren Personen vergleicht, alleine schon dadurch dass nicht jeder an exakt der gleichen Stelle den Hotkey drückt, oder nicht exakt an der gleichen Stelle steht, weit mehr Differenzen, als durch die 300ms Versatz.


Allerdings hab ich gerade in Plague Inc(lässt sich halt am schnellsten starten^^) nochmal ein paar Messungen gemacht, da geht die Verzögerung einmal bis 1439ms und auch sonst eher im 700-800er Bereich.
Es wäre schon gut, wenn man es relativ konstant auf maximal 200-300ms bekommt.

Ansonsten, wenn du den Delay nicht runter bekommst, müsstest du vielleicht die Aussage

Wegen ein paar Millisekunden setzte ich keinen aufwendigen Archiv + Timestamp Ansatz um.

nochmal überdenken, damit wäre der Delay doch im Prinzip völlig egal.

Ergänzung (19. Mai 2019)

Gerade noch mal 3x Frostpunkt gemessen
860, 979 und 312ms

Das witzige ist, wir wissen ja nicht mal, ob das bei den anderen Tools nicht auch der Fall ist. Hättest du jetzt den Logger nicht eingebaut, wäre es weder uns noch irgendjemand anderem aufgefallen.

 

[ZeroStrat]

Ja, diese Werte, auch auf meinem System, überzeugen mich, den Archivansatz zu implementieren. Dann wird sich der Release wohl noch um 1-2 Tage verschieben.

 

[Taxxor]

Wie muss ich mir das denn vorstellen?
Du erstellst ein Archiv, in das die Daten vom Outputstream kontinuierlich mit Timestamp reingeschoben werden.

Das Archiv ist z.B. 5s "lang", d.h. es sind immer die Frametimes der letzten 5s enthalten. Sozugagen genau die gleichen Daten, wie die Echtzeit, nur 5s versetzt.

Mit dem Hotkey greifst du dann nicht mehr auf den Outputstream direkt, sondern auf das Archiv zu, wobei der Startpunkt über den Timestamp des Hotkeys abgeglichen wird.

Wäre das schon "alles"? In dem Fall müsstest du noch einen absichtlichen Delay für den Zugriff aufs Archiv einbauen, da es ja passieren kann, dass durch die asynchrone Übertragung zum Zeitpunkt des Hotkey Events die Frametime mit dem passenden Timestamp noch gar nicht im Archiv ist.
Der Delay, der sowieso entsteht ist ja nicht stabil, wenn man also einen 2s Delay hinzufügt, ist man auf alle Fälle save, dass die Zeile mit dem passenden Timestamp auch im Archiv ist.

Der Einzige Versatz der dann noch bleibt, ist ein Delay vom Beenden der Aufnahme bis zum komplettieren des Datensatzes, weil ja eine kurze Zeit weiter aus dem Archiv geschrieben wird. Aber es wird ja niemand innerhalb von 2-3 Sekunden nach der Aufnahme auf den Datensatz zugreifen wollen, geschweige denn rein logistisch dazu imstande sein^^

Dann wird sich der Release wohl noch um 1-2 Tage verschieben.

Sonntag Abend ist sowieso ein blöder Release Zeitpunkt^^

 

[ZeroStrat]

Das ist eigentlich ganz einfach. Angenommen, es exisiert ein Archiv der letzten n Sekunden. Ich führe wieder ein festes Zeitkorsett + ein Sicherheitsoffset nach hinten hin ein. Dann setze ich einen Zeitstempel, wenn der Hotkey gedrückt wird. Die ersten Elemente, die aus dem PresentMon Stream kommen, gleiche ich gegen den Zeitstempel ab. Jetzt kommt der "Kniff": fehlt etwas, fülle ich es mit Daten aus dem Archiv auf. Habe ich nach hinten zu viel, schneide ich es ab.

 

[Taxxor]

fehlt etwas, fülle ich es mit Daten aus dem Archiv auf. Habe ich nach hinten zu viel, schneide ich es ab.

Also für mich als Laie klingt da meine Überlegung, einfach alles aus dem Archiv zu nehmen, sogar noch einfacher^^ Da müsste nichts abgeschnitten oder aufgefüllt werden und die einzige Änderung im Verhalten von CX ist der Ort, an den es geht um die Daten abzugreifen.
Und eben mit Sicherheits Delay für den Zugriff, falls die Daten erst etwas später im Archiv gelandet sind.

Oder funktioniert das Abgreifen aus diesem Archiv nicht in Echtzeit oder erzeugt mehr Last?

 

[ZeroStrat]

Der Vorteil dabei, das ganze zu trennen, ist, dass man Konflikte durch gleichzeitige Zugriffe verhindert. Während ich nämlich an dem Ausgangsstream hänge, kann das Archiv "ruhen." Ich kann Daten aus dem Archiv holen, ohne dass dort gleichzeitg welche eingetragen werden.

 

[Taxxor]

Die ersten Elemente, die aus dem PresentMon Stream kommen, gleiche ich gegen den Zeitstempel ab.

Haben denn diese Elemente selbst einen Timestamp, wann sie erstellt wurden? Oder musst du den Zeitpunkt nehmen, an dem die Elemente ankommen? Dann wäre der Versatz durch die asynchrone Übertragung ja weiterhin vorhanden, auch wenn dieser sehr viel kleiner sein dürfte, als das was momentan an Delay für den Zugriff da ist.

 

[ZeroStrat]

Leider bietet PresentMon keine Timestamps. Hab schon überlegt, Jefferson nochmal anzuhauen deswegen.

 

[Taxxor]

Erst mal den Archivansatz umsetzen, das verringert den Delay schon mal deutlich.

Ergänzung (19. Mai 2019)

Sagen wir der Delay von CX beträgt 800ms und genau zum Zeitpunkt des ersten Zugriffs auf den Output Stream ist die erste Datei bereits 200ms älter.
Aktuell beträgt der Versatz dadurch dann 600ms nach hinten(zu spät dran), mit dem Archivumsatz sind es nur 200ms nach vorne(zu früh dran).
Und wie gesagt, Versatz ist in der Größenordnung nicht so schlimm, viel schlimmer wäre es, wenn einfach 200ms fehlen. Bis zu 1,5 Sekunden, wie die eine Messung von mir, ist aber auch als Versatz schlicht zuviel^^


Ich hab noch mal ein paar Seiten zurück geblättert, als noch nach fester Zeit gestoppt wurde, da sieht man den Versatz, der dadurch entsteht ja perfekt:
In 29 von 42 Messungen war der Versatz kleiner als 30ms und von den verbleibenden 13 waren er nur 6mal größer als 200ms, der Rest lag zwischen 200 und 500.

Und da war ja auch noch Versatz durch CX mit drin, den du ja im Nachgang weiter minimiert hast, du sagtest ja selbst

Die Schwankungen des Datenstroms von PresentMon sind unter Verwendung einer sauberen Verwaltung verschwindet gering.

Ich denke also nicht, dass man sich nach dem Archivansatz dann noch weiter drum kümmern müsste.

Wenn du es unbedingt super genau haben möchtest, kannst du Jefferson aber gerne anhauen.
Wenn du Timestamps bekommen kannst, bräuchtest du ja nur eine Sache ändern, und zwar mit dem Timestamp des Elements vergleichen statt mit der Zeit, wann dieses angekommen ist.
Das wäre ja später ganz fix nachträglich zu ändern.

 

[Taxxor]

@ZeroStrat
Dein Logger kann ja erkennen, wann das erste Element angekommen ist, könntest du eventuell auch erkennen, wann du dich in den Data Stream eingeklinkt hast? Denn dann wäre die Sache recht "einfach"

Nehmen wir an der Delay bis zum Einklinken läge bei 800ms.
Jetzt musst du nur genau ab diesem Zeitpunkt die letzten 800ms an Frametimes aus dem Archiv raus nehmen und an den Anfang setzen, denn genau das ist der Versatz, mit dem du auf die Echtzeit zugegriffen hast.

Wenn das erste Element nun 100ms nach dem Einklinken kommt und es im Laufe der Aufnahme nicht von selbst wieder synchron wird, wird das durch den Sicherheitsoffset am Ende aufgefangen.
Dein Startpunkt liegt aber auf jeden Fall immer genau da wo er laut Hotkey sein sollte.
Eventuelle Asynchronitäten bei den Elementen vor diesem Startpunkt interessieren nicht, da du diese Elemente ja aufgrund ihrer Frametime Summe rausholst, es sind also definitiv die 800ms vor dem Einklinken und somit ist der erste Frame exakt der Zeitpunkt wo du den Hotkey gedrückt hast.

 

[ZeroStrat]

Ja genau so. Und ich mache zusätzlich noch einen Abgleich beim Übergang vom Archiv zur Live-Subscription, damit kein einziges Frame verloren geht.

Man braucht halt bei Widrigkeiten einfach nur gute Ideen. ^^

 

[ZeroStrat]

@Taxxor Du hattest doch Vorschläge für die Tooltips ausgearbeitet?! Sorry, dass ich das nicht beachtet hatte. Waren halt viele Punkte. Könntest du das nochmal zusammentragen?

 

[Taxxor]

@ZeroStrat Für die Capture Seite?

Da hatt ich mehr feste Texte statt Tooltips angesprochen

0= no limit unterhalb des Eingabefelds für die Aufnahmezeit
combinable with Ctrl/Shift/Alt unterhalb des Eingabefelds für den Hotkey

Du kannst das aber natürlich auch gerne als Tooltip an die Maus heften.

Ich hatte bisher noch nicht wieder den Fall dass 2 Prozesse gleichzeitig in der Liste waren, aber ich nehme an, du hast das bereits im Statustext mit eingebunden, dass man dann einen auswählen soll?

Und eben die Umbenennung der Liste in "Running processes", damit sofort klar ist, dass das eine Live Liste ist und keine, in die man was reinziehen muss.

 

[ZeroStrat]

OK, super. Ich werd's wohl als Tooltips verpacken. Ich find's eigentlich gut, wenn die Oberfläche so schlank wie möglich ist.

 

[cm87]

Hallo @ZeroStrat

Ich bin gerade dabei ein RAM Kit Review zu schreiben. 2400MHz bis 3666Mhz.
Kann ich die Beta dazu schon verwenden?

Liebe Grüße

 

[ZeroStrat]

@cm87 Ja, kannst du. Du hast ab Drücken des Hotkeys im schlimmsten Fall einen Versatz nach hinten hin von 0.5-1 Sekunde. Wenn du Messungen mit einer Dauer von mehr als 20 Sekunden machst, wird das am Average nichts ändern und auch nicht am 1% Quantil. OCAT streut auch mit ca. 1 Sekunde teilweise, was keinen bisher gestört hat. ^^

Ich bin dabei, es noch genauer zu machen. Aber wenn man ehrlich ist, sind das Luxusoptimierungen.

Wenn du Fragen hast, sag Bescheid. Ich werde noch ein YT-Tutorial machen.

 

[cm87]

Perfetto, dann werde ich bei den Spielebenchmarks auf deine Beta zurückgreifen
Die Dauer wird sich bei 20 Sekunden belaufen.