AMD erklärt den Precision Boost Overdrive der neuen Ryzen-Prozessoren

Genau das ist eben nicht der Fall die Frametime ist völlig unabhängig von den FPS
SIeht man schön im CS:GO Benchmark Thread, mit CapFrameX, ich hab 2ms obwohl man die sonst im MSI AB im Overlay nur mit xxxFPS mal kurzzeitig sieht.
Ich möchte dich bitten, CapFrameX nicht für deinen Unsinn als Erklärung vorzuschieben. Unsere Software basiert auf PresentMon und arbeitet korrekt. FPS und Frametimes sind eng miteinander verbunden. Wurde alles schon erwähnt in diesem Thread.

Ich hoffe dir ist klar, das "Frametime" exakt der Kehrwert von "FPS" ist? Also Frametime = 1/FPS.
Es kommt tatsächlich drauf an. Man kann zum einen reine Kehrwerte betrachten, was man z.B. dann macht, wenn man Perzentile (Low FPS) berechnet. Dann hat man aber noch Realtime Metriken, die z.B. auf dem Overlay angezeigt werden. Diese Metriken werden mit festen Abständen gesampelt/aktualisiert. Wenn man das mit einem zeitbasierten Moving Average (kumuliert) macht, hat man "wirklich" die Anzahl der Bilder pro Sekunde. Historisch gesehen hat man so früher die Min FPS berechnet. Man hat dann bei N Sekunden Aufnahme N Mittelwerte mit einer Länge von 1 Sekunde und nimmt davon das Minimum. Dieser Ansatz wirkt stark glättend in Bezug auf Spikes/Ausreißer.
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
...er sich vielleicht genötigt sieht Dir mal CapFrameX richtig zu erklären
Im umgekehrten Fall bin ich dabei, sonst nein danke. ^^
Man misst Zeiten - also Frametimes - und nicht Bilder. Und errechnet aus Frametimes die FPS. Denn die FPS sind die kumulierte Anzahl von Frames auf 1000ms.
Nicht notwendigerweise. Genauso wie man keine Stunde messen muss, um die Geschwindigkeit in km/h angeben zu können, kann man das auch bei FPS machen. FPS = 1000/ft ist dann quasi so was wie die Momentan-FPS.

Aber der andere Punkt war gut zu erwähnen. Sobald man kumuliert, kann man die Frametimes nicht mehr aus den FPS bestimmen/zurückrechnen.

------------------------------------------------------------------------------------------------------------------------------------------

Noch zum Thema Input Lag, in modernen Engines entspricht der Application Lag (ohne Peripherie und Display) ungefähr dem zweifachen der Frametime. Es gibt auch noch andere Ansätze, die Pipelines aufzubauen, um das stark zu verkürzen, aber das kommt in der Praxis eher selten vor.
 
Zuletzt bearbeitet:
Ich verstehe die Spitzfindigkeit absolut, aber rein mathematisch ist die Aussage doch Quatsch... Wenn a = 1/b ist, dann ist b = 1/a. Zum Rest volle Zustimmung, insbesondere zum Framebuffer. Den hatte ich beim Schreiben im Hinterkopf, wollte die Sache aber nicht verkomplizieren.
Entschuldige, es sollte nicht spitzfindig rüber kommen. :wink:

Du hast natürlich recht, was die Mathematik angeht. Ich wollte allerdings auf die Zusammensetzung des Frames hinaus. Du kannst immer aus der Framezeit die Frames pro Sekunde errechnen. Aber nie aus den Frames pro Sekunde rückwärts die Frametimes. Weil diese nicht zwingend homogen sein müssen. Es wird also mehr Infos benötigen, damit man das rückwärts errechnet bekommt oder es kommt nur näherungsweise hin. Deswegen ist dieser Umstand, so unsinnig er mathematisch auch ist, sinnig zu unterscheiden. Stimmen tuts natürlich bei der Betrachtung der Ausgabe. Dem Monitor ist es egal ob die Frames homogen kommen oder nicht. Der stellt dar was im Framebuffer liegt und wenn sich das eben gerade mal nicht ändert, weil zu inhomogen in der Frametime, wird das alte/gleiche Frame wie davor nochmal dargestellt. Als SLI (ex) User kann ich dir allerdings sagen, FPS sind in manchen Spielen nix wert :fresse:
 
Mir ist der Unterschied absolut klar ;) Die FPS sind per Definition immer ein Durchschnitsswert (eben pro Sekunde), während die Frametime natürlich für jeden einzelnen Frame angegeben wird. Deshalb fand/finde ich die Artikel mit reinen FPS Werten total sinnfrei. Effektiv läuft ein Spiel dann flüssig, wenn die min. fps hoch sind oder mit anderen Worten möglichst alle Frames eine kleine Frametime haben und es keine Ausreisser gibt. Genau dafür gibts ja die Perzentile, die mittlerweile immer häufiger angegeben werden.
Dem Monitor ist es egal ob die Frames homogen kommen oder nicht.
Jau, klar.
 
PBO AMD Specifications
105W TDP
PPT 142W, TDC 95A, EDC 140A
95W TDP
PPT 128W, TDC 80A, EDC 125A
65W TDP
PPT 88W, TDC 60A, EDC 90A
45W TDP
PPT 60W, TDC 45A, EDC 65A

MSI B450-A Pro
Auto und Enabled = Board Limits
PPT 1000, TDC 114, EDC 168
So von wegen "Auto" und CMOS Clear sind dann die AMD-Vorgaben.
Wie ich darauf komme, ganz einfach, Win10 frische Installation und dann tat der AMD Ryzen Master dann doch noch mal wieder seinen Job, ausgelesen und notiert...

Was die Frames angeht, was in der Simulation nicht eher passiert kann man auch nicht eher sehen. (Alles Abklatsch von Echtzeitsimulationen zu viel wichtigeren/hören Zwecken für die Zukunft der Menschheit)
Dazu muss man nur mal die Mathematik verstehen warum die virtuellen Welten überhaupt erst existieren.
Also ich habe garkein Problem bei 60Hz/FPS die Menschenmögliche Reaktionszeit von 180ms zu erreichen.
Was in der virtuellen Welt in Echtzeit nicht passiert, kann man auch nicht eher sehen, es sei denn das ganze läuft nicht in Echtzeit, denn isses halt oft zu schnell.
Edit
selbst Schüler schaffen nur schwer 180ms, wenn der Rechner also ohne Limits bei CPU/GPU ne vernünftige Frametime macht ist man als Mensch der Flaschenhals (Und das bei 60Hz/FPS)

Pfützen unter Lara in den neueren Tomb Raider Teilen, weil se reinlatscht und die Wasserwellen eskalieren, ein Agent Blaskowicz der einfach viel zu schnell gegen ne Wand rennt.... (Wolfenstein The New Order sowie The Old Blood)
Der Bildverlauf auf den Augen kann natürlich durchaus angenehmer sein, da gibt es nichts dagegen zu sagen.

Aber eine Gamesoftware läuft immer nur dann gut wenn:
CX_2022-06-09_00-16-59_Comparison.png
Grün = das so aussieht prozentual
rot = eben nicht nur 70 bis 90%.....

Strom fliesst im übrigen mit Lichtgeschwindigkeit und im da eine Verzögerungs zu erzeugen die relevant wäre, nun wenn ihr alle Kabel habe die 210.000 km lang sind... (299 792 458 m / s)
Max-Planck-Institut

Gruss Dennis
Beitrag automatisch zusammengeführt:

Einfach mal selber ausprobieren

Hier einfach mal checken wieviel fps die Bude mit dem Browser gerade bringt, jenachdem wieviel HZ man den Monitor einstellt

Also ich hab da keine Mühen so übrliche Werte wie 180ms rauszuhauen.
Und wenn man kürzere herausgambelt, Gratulation biste beste "Camper" in alles Ego-Shootern wie CS:GO...

Gruss Dennis
 
Zuletzt bearbeitet:
Aus deiner Quelle:
In einem Kupferkabel mit einem Querschnitt von 1 Quadratmillimeter und einem Strom von 1 Ampere legen die Elektronen in einer Stunde gerade einmal 26,5 cm zurück.

Während sich der antreibende Potentialunterschied fast mit Lichtgeschwindigkeit (knapp 300000 km pro Sekunde) durch den Leiter ausbreitet
....
Fakt ist, haste mit der Maus auf der Windows-Oberfläche keine spürbare Verzögerung, haste es auch nicht in Games und wenn da was lagged ist es ein CPU-Limit oder eben die GPU.
Da lagged kein InputSignal, du hast ganz andere Probleme, von "InputLag" sprechen also Leute die erstmal garkeine Ahnung was da gerade das Problem ist und das wars auch schon.

Den Unterschied zwischen Asio und Wasapi wirst du @Home auch niemals auseinanderhalten können, im Studio zu gewissen Zwecken, dann merkt man es halt aber schonn

Gruss
Beitrag automatisch zusammengeführt:

Wenn die Bude dazu Fähig ist dein Reaktionszeit zu "Messen" können die Signale nur schneller sein bzw. schnell genug und da braucht auch niemand anfangen mit 200ms, mit irgendeinem Signal von der Maus durch den Rechner bis zum Bildschirm braucht insgesamt rein garnichts 200ms sonst wäre die Kiste garicht in der Lage 180ms messbar zu machen.
Simple logik
Exakt das machste aber mit dem Human Benchmark ganz locker mit 60Hz und somit 60FPS

Edit:
noch ein simples Beispiel, 50Hz Brummspannung, is ziemlich schnell auf der Audioleitung nicht wahr, deswegen nervts halt auch wenn man das auf analog-Audio drauf hat, wenn man das dann halt auch noch verstärkt mit nem Verstärker...
Dieselbe Technik, dieselbe Mathematik, elektrischer Strom, nur eben nicht Wechselspannung sondern halt gleichstrom

Das Peak-Meter mit FooBar2000, da ist ebenso keine Verzögerung "bemerkbar" digital raus, durch den Verstärker und denn die Wiedergabe über die Boxen wo man üblicherweise ebenso Kupferkabel hat... die Chassis machen 50 rein/raus Bewegungen um die Mittelstellung bei ner Brummspannung und das "gefühlt" zeitrichtig mit dem Peak-Meter....ein Wunder der Natur...
 
Zuletzt bearbeitet:
Hier der Beweis mit dem Peak-Meter, unwiederlegbar,

Die Smartphonekamera deckt es in der Tat ganz leicht auf, wenn man selber aber analytisch hört ist es eben nicht so
Edit:
und das was es aufdeckt sind 2ms Asio...
Unbenannt.jpg

Die Kamera ist zu lahm die hat Inputlag vom schietsmartphone :ROFLMAO:
Edit:
Ne ma spass beiseite, die app macht müll aufm dem smartphone beim wiedergeben, am Rechner passt es wiederum..., gibt bestimmt bald wieder n Update über den Google-Playstore :d

Gruss Dennis
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh