Inputlag gemessen, seltsame Ergebnisse, wie verstehen?

    hallo, ich habe mir mal einen alten crt organisiert um den input lag von einem tfts zu messen, da mit die maus etwas schwammig vorkommt.


    ich habe also den nvidia clonmode angeworfen und eine stopwatch lauefn lassen und diverse fotos geschossen.


    danach habe ich die bilder ausgewertet und die differenz aufgeschrieben.


    verzögerung des tfts im vergleich zm crt:


    foto1: 47 ms
    foto2: 47 ms
    foto3: 0 ms
    foto4: 47 ms
    foto5: 0 ms
    foto6: 0 ms
    foto7: 46 ms
    foto8: 62 ms
    foto9: 47 ms
    foto10: 0 ms



    um auszuschliessen, dass der lag durch den clonmode kommt habe ich in einem zweiten versuch auch die anschlüsse getauscht, kein unterschied.



    ich finde es seltsam, dass es teilweise kein delay zu geben scheint?!
    nach dem, wie ich overdrive verstehe, müsste mindestens das minimum grösser als 0 ms sein. ich finde es auch komisch, dass das delay des overdrives so große sprünge aufweißt (0 - 62 ms).


    vielleicht kann mir jemand mit seinem wissen etwas auf die sprünge helfen.


    danke!


    edit: ich hatte mit einem relativ klaren ergebnis gerechnet, z.b. ~33 ms verzögerung = 2 bilder verzögerung oder 47 ms = 3 bilder verzögerung. bei den grössen sprüngen fällst es mir allerdings schwer eine aussage zu treffen - wie schlecht schätzt ihr das verhalten ein, eizo liegt meines wissens bei ~2 bildern verzögerung.

    Einmal editiert, zuletzt von Freis ()

    Habe ich öfters schon gelesen, daß die gemessenen Werte schwanken, sowohl in der c't oder auch z.B. beim L220x gibts im Netz (nicht bei prad) einen thread, wo eine gewisse Bandbreite des Lags gemessen wird.
    Ich denke entscheidend ist eher, ob du mit dem Lag (Maus / Spiele) leben kannst oder nicht...

    die werte sind so leider nicht objektiv.


    Solche bekommst du nur, wenn du nur einen Ausgang benutzt und diesen dann auf beide Monitore aufteilst.

    schade, dass das messen nicht so einfach zu sein scheint. subjektiv empfinde ich ein "nachziehen", ich bin aber selbstkritisch genug, um das in frage zu stellen. ich weiss, dass das panel ein s-pva ist, die ja zum input lag neigen, daher hätte ich das gerne durch einen objetiven test für mich bestätigt bzw. gewusst ob es eben einfach im "normalen" overdrive bedingtem bereich ist.

    Freis:


    Welches TFT-Modell genau hast du denn mit welchem CRT-Modell genau mit welcher Auflösung verglichen???


    ...und noch viel wichtiger:


    Welche Stopwatch-Software hast du da verwendet ???


    Einige Stoppuhr-Programme sind nämlich völlig unbrauchbar für den Latenztest im Klonmodus, da sie nicht jedes 100stel der 100stel-Anzeige tatsächlich anzeigen, sondern nur wenige bestimmte 100stel-Zahlenwerte dazwischen (immer die selben) - so etwa bei der frei downloadbaren Stoppuhr-Software von Flatpanels-DK der Fall. Das PRG kannst du getrost in die Tonne kloppen. :D



    Gruß

    danke wurstdie!, sehr guter tip mit der stopwatch, das würde sinn machen!



    TFT-Modell: (für eine bekannte, beide haben wir das gefühl die maus zieht nach) yuraku (panel sa-ltm240m2-l01 - s-pva)


    CRT-Modell: LG studioworks E900B


    Stopwatch-Software:



    kannst du mir eine empfehlen die funktioniert?

    Einmal editiert, zuletzt von Freis ()

    Freis:


    Zunächst mal muss berücksichtigt werden, daß der Delay je nach gewählter Auflösung bei einigen TFTs unterschiedlich ausfallen kann. Wir haben bei den PRAD-Tests die Erfahrung gemacht, daß einige Monitore bei nicht-nativen Auflösungen zu einer stärkeren Darstellungslatenz 'neigen'.


    Drum sollte der Latenztest im Klonmodus stets mit der nativen Auflösung des TFTs durchgeführt werden. Beim testen eines 24"ers mit 1920x1200 ist also auch ein entsprechend hochauflösender CRT von Nöten, da im Klonmodus die beiden Monitore üblicherweise mit identischer Auflösung und Bildwechselfrequenz arbeiten.


    Ich habe während meiner Zeit als PRAD-Redakteur z. B. einen IBM C220P 22" Röhrenmonitor benutzt - ein sehr gutes Gerät.


    Als Stoppuhr kam die 'Virtual Stopwatch' von Spring-Creek Software zum Einsatz. Ich selbst habe die Vollversion erworben. Es gibt allerdings auch eine kostenlose Version mit allen Funktionen der Vollversion (Virtual Stopwatch Presentation). Bei dieser Gratisversion muss der Anwender lediglich mit der Einschränkung leben, daß das PRG die gewählten Einstellungen nicht dauerhaft speichert - bei jedem Neustart der Software müssen alle Einstellungen wieder von Neuem vorgenommen werden.


    Bei der Virtual Stopwatch kann die Refresh-Rate der Digitalanzeige exakt eingestellt werden (z. B. auf 60 oder 75 Bilder pro Sekunde - synchron zur jeweils eingestellten Bildwiederholfrequenz). Außerdem können auch 1000stel angezeigt werden.



    Bei den PRAD-Tests kommt allerdings auch eine wesentlich professionellere Software zum Einsatz (PixPerAn V2 beta). Im Gegensatz zur üblichen Stoppuhr-Anzeige, wird hier synchron zur Bildwiederholfrequenz die Desktophintergrundfarbe gewechselt (schwarz-weiß-schwarz-weiß....). Vorteilhafterweise werden hierbei die Schaltflanken der einzelnen Framewechsel direkt sichtbar - noch exakter geht es nicht.


    Die PixPerAn V2 beta Software steht allerdings ausschließlich den PRAD-Redakteuren zur Verfügung. Bei der frei downloadbaren normalen PixPerAn-Version ist dieser Latenztest nicht enthalten.



    Gruß

    so, neuigkeiten. ich habe den test mit der virtual stopwatch wiederholt. einstellungen (gleiche auflösung usw. - die 1920x1200 schafft der crt bei 60 hz) war auch schon beim vorherigen test so, wie du beschrieben hast.


    ich poste einfach mal die differenzen.


    tft verzögert zum crt:


    22
    23
    15
    32
    33
    32
    35
    31
    33
    39
    32
    48
    22
    21
    31
    32


    es sieht also ganz nach ca. zwei bildern verzögerung durch overdrive aus, was wohl für VA normal ist (siehe eizo und co).

    Zum Thema Input Lag möchte ich folgende Informationen beisteuern:


    - Mit den gängigen Stoppuhr-Tests ist es prinzipbedingt nicht möglich, genauer als in ganzen Frames zu "messen". Sprich: Bei 60 Hz Vertikalfrequenz kann man nur Vielfache von 16,6 ms (also 1/60 Sekunde) ermitteln.


    - Falls trotzdem andere Werte als Vielfache von 16,6 ms herauskommen, dürfte das an der Stoppuhr-Software liegen, die den Bildspeicher mit einer nicht mit 60 Hz synchronen Frequenz updatet. (mit 1000 Hz wird wohl keine Software arbeiten...) Krumme Werte sind bei der Stoppuhr-Methode eigentlich fast vorprogrammiert. Schon daher halte ich die Methode für nicht besonders genau. Wenn ein Stoppuhr-Programm mit einer sehr langsamen Update-Rate arbeitet, wird es vollkommen unbrauchbar. Das kann durchaus passieren... Da können Schwankungen im Bereich von mehrern Frames nur allein durch das Programm auftreten.


    Bevor ich also große Tests mithilfe einer Stoppuhr-Software mache, wäre es eher ratsam, die Software selbst zu testen. Zum Beispiel einfach mit einer möglichst schnellen Fotoserie. Die Differenzen angezeigten Werte sollten möglichst genaue Vielfache von 16.6 sein. Wenn die Abweichungen zu groß sind, ist das schon mal ein schlechtes Zeichen.


    Naja, das Problem wurde aber offensichtlich auch schon erkannt ;)


    Die Werte der Virtual Stopwatch finde ich jetzt allerdings auch nicht unbedingt überzeugend ;)


    - Nichtsdestotrotz: Es ist tatsächlich so daß viele TFT-Monitore einen schwankenden Input-Lag haben. Prinzipbedingt schwankt dieser bei vielen Monitoren schon aufgrund der zur Vertikalfrequenz asynchron laufenden internen Bildverarbeitung um 16.6 ms. Größere Schwankungen waren mir bis jetzt nicht bekannt, aber ich halte auch da vieles für möglich. Ich hatte schließlich auch mal einen Monitor da der intern nur 30 Bilder/Sekunde verarbeitete, was natürlich zu einem recht trägen Reaktionsverhalten und einer sehr unbefriedigenden Bewegungsdarstellung führte.


    Viele Grüße
    Wilfried