Folgerung aus den Beobachtungen
Die vertikale Synchronisation ist heute am einfachsten in Direct3D basierten Anwendungen über den Treiber der Grafikkarte zu steuern. Reproduzierbar und mit eindeutigem Effekt. Daher viel nach Betrachtung einiger bereits weit verbreiteter Stoppuhren schnell der Entschluss eine neue Anwendung zu schreiben, die auf die hardwarebeschleunigte Ausgabe mittels Direct3D zurückgreift, damit Frameraten über 1000 fps erreicht werden können, wie im zuletzt gezeigten Bild zu sehen. Bei 1000 fps wird jedes Einzelbild für eine Millisekunde angezeigt – das ist also die Mindestvoraussetzung für eine solche Stoppuhr.
Da der Bildaufbau an sich offensichtlich zeitversetzt erfolgt, und das nicht zwingend zum Nachteil des TFTs, ist zudem zu überlegen, ob eine Stoppuhr auf „gleicher Höhe“ des Bildes die sinnvollste Darstellung ist, oder viel eher die Positionen der zuletzt aktualisierten Zeilen miteinander verglichen werden sollten. Ohne V-Sync und ohne Input Lag entspräche das wohl als ehestes dem Wert, der zeitgleich zu den Monitoren übermittelt wurde. Im Screenshot auf der vorherigen Seite, würde das die Latenz von 10 ms auf 5 ms verringern.
Zeitnahme
Der nächste Problempunkt ist die Zeitnahme in der Software, also die Referenz für die verstrichene Zeit. Verwendet man die „Systemticks“, also einen Counter des Betriebssystems, der kontinuierlich einzelne Millisekunden oder gar 0,1 ms zählt, dann hat man zwar eine absolut betrachtet recht genaue Zeitangabe, allerdings wird dieser Wert nur in groben Intervallen vom Betriebssystem ausgegeben, egal wie oft das Programm diesen Wert auch abfragen mag.
Auf verschiedenen Systemen mit Windows XP, Vista und Server 2008 konnten hier fixe Werte von ca. 10 ms und ca. 16 ms festgehalten werden. Zur Kontrolle der tatsächlichen Auflösung dieses Counters gibt es von Microsoft ein passendes Tool aus der Sysinternals Suite, welches ClockRes heißt.
Läuft also eine solche Stoppuhranwendung mit mehreren hundert oder gar tausend Aktualisierungen pro Sekunde, so sind bei der Darstellung von vielen dieser Uhren untereinander immer nur in den genannten Schrittgrößen Veränderungen zu erkennen. Die Zeitausgabe ist trotz der hohen Abfragerate und Bildfrequenz also ungenau.
Somit wäre es nicht möglich zu sagen, ob die erste angezeigte Zeit oben am Bildschirmrand eines neuen Bildes nun „Exakt“ oder vielleicht doch schon 15,6 ms alt ist. Eine Stoppuhr, die auf diesem Timer basiert ist also für einen Test des Input Lags, bei dem auf einzelne Millisekunden geachtet werden soll, ungeeignet, da ein systematischer Fehler von gut 16 ms auftreten kann, der auch durch keine Mittelung über viele Messwerte reduziert werden könnte.
Die Lösung für dieses Problem
Hierfür musste ein sogenannter high-precision Counter verwendet werden, der in der Lage ist Millisekunden präzise und einzeln auszugeben. Der verwendete Counter geht über diese gewünschte Präzision weit hinaus und könnte auch mehrere Nachkommastellen von Millisekunden problemlos auflösen, was jedoch unnötig ist.
Zudem müssen eventuell berechnete Zahlen, wie z.B. eine Framerate, in Variablen gefasst werden, die die Werte nicht verfälschen. Selbst der Variablentyp „Double“ kann hier Abweichungen provozieren, weswegen in dem erstellten Programm soweit wie nötig der Typ „Decimal“ angewandt wurde.
Das Programm selbst wurde in C# erstellt und für DirectX 9 (Version vom März 2009) unter Windows XP 32bit optimiert. Hier sind auf einem 2,6GHz Dual Opteron mit einer GeForce 8800GTS512 Frameraten zwischen 2500 und 6000 fps möglich. Die Anwendung arbeitet single-threaded und wird durch die CPU limitiert.
Das Programm wurde inzwischen auch auf Windows Vista, sowohl 32 Bit als auch 64 Bit, portiert. Bei einer untertakteten GeForce4 Ti4200 auf einem Athlon XP 1700+ sind immer noch 700 fps möglich, was zumindest noch eine zeitliche Auflösung von 2 ms ermöglicht.
Zusätzlich kann durch die Einblendung der Framerate kontrolliert werden, wie häufig die Stoppuhr aktualisiert wird. Ob V-Sync an oder aus ist, kann somit auf den ersten Blick festgestellt werden. Im Vergleich zu den zuvor genannten klassischen Stoppuhren ist dies eine enorme Verbesserung.
Auswirkungen der Softwareprobleme
Addiert man die möglichen Latenzen der unterschiedlichen Fehlerquellen, also den maximalen Wert einer ungenauen Zeitnehmung über die „System Ticks“ von rund 16 ms und die Zeit, die durch eine an die Bildwiederholrate gekoppelte Aktualisierung auftritt von ebenfalls rund 16 ms, so erhält man bereits einen möglichen systematischen Fehler von bis zu 32 ms. Da es, wie in den Screenshots zuvor gezeigt, stets Werte gibt, die um ±16 ms abweichen können, wird allein über den Zufall entschieden, wann die Kamera welche Bilder aufnimmt.
Passt die Rate der Serienbildfunktion zufällig so zur Bilddarstellung, dass vermehrt ein Bereich von einem alten Bild auf dem CRT und einem neuen Bild auf dem TFT miteinander verglichen wird, so wird der Input Lag zu niedrig angegeben. Ist es genau umgekehrt der Fall, so wird der Input Lag zu hoch angegeben. Mischen sich die Werte zwischen gleichen Bildern und dem Vergleich alt gegen neu, so landet man nach einer Mittelung natürlich auf Zwischenwerten.
Was man damit jedoch gemessen hat, hat nicht unbedingt etwas mit der Latenz des zu testenden Monitors zu tun, sondern stellt eine Kombination aus verschiedenen Schwächen der Messmethode dar, die sich im Zufallsprinzip gegenseitig addieren oder auch aufheben können. Leider kann man über eine Mittelung diese Fehler nicht eliminieren, da dies nur bei zufälligen Streuprozessen der Fall ist. Hier handelt es sich meistens um additive Fehler, die zu systematischen Fehlern in den Ergebnissen führen.
In vielen bisherigen Messreihen, denen die alte Foto-Methode zu Grunde liegt, treten somit auch Werte auf, die in einem Beriech von über 32 ms schwanken, häufig zwischen 0 und über 32 ms. Ein paar Beispiele:
| Monitor | Minimal gemessener Input-Lag Wert | Maximal gemessener Input-Lag Wert |
| BenQ V2400W | 0 | 33 |
| NEC P221W | 0 | 37 |
| Lenovo L2440pwC | 0 | 38 |
| ViewSonic VP2650wb | 0 | 38 |
| HP LP2475w | 11 | 54 |
Vergleich der maximal und minimal ermittelten Latenzen einiger Monitore
Zusätzlich zu den theoretisch möglichen Verzögerungen der Software addieren sich natürlich noch eventuell tatsächlich vorhandene Verzögerungen durch den wahren Input Lag der Geräte.
Außerdem gibt es noch die ausstehende Begründung, warum der Bildaufbau an zwei Ausgängen der Grafikkarte überhaupt asynchron abläuft, da doch schließlich eine „Vertikale Synchronisation“ vermuten lässt, dass die Bilder auch synchron ausgegeben werden. Selbst im Idealfall, also dem ausschließlichen Vergleich neuer Bildinhalte ohne V-Sync, ist somit zumindest die Differenz der jeweiligen Position des Bildaufbaus nicht berücksichtigt, wenn lediglich eine Stoppuhr dargestellt wird. Der Fehler allein durch diesen Effekt kann bis zu 16 ms betragen und auch nicht durch eine ideale Programmierung und zügige Darstellung verhindert werden.
Die Messungen
Der Input Lag eines CRTs
Zunächst muss erst einmal betrachtet werden, ob die oben im Beispiel zu sehende negative Zeit zur Bestimmung des Input Lags durch eine Verzögerung im CRT verursacht wurde oder nicht.
Der hierfür benötigte Aufbau ist relativ simpel: Man untersuche das zugespielte analoge Bildsignal, indem man es mit einem Y-Adapter vor dem Monitor abgreift und nehme den Bildanfang als zeitliche Referenz.
Zum Vergleich muss man nun über einen Fotoempfänger den Zeitpunkt festhalten, zu dem der Elektronenstrahl den ersten Pixel des Monitors abrastert und diese beiden Zeitpunkte miteinander vergleichen. Die Differenz ergibt den Input Lag des CRTs, Latenzen der Messgeräte und Signallaufzeiten werden einzeln betrachtet.
Automatisierte Delay-Messung
Das Oszilloskop von Tektronix erlaubt im Measurement-Setup die Einrichtung einer automatischen Delay-Messung, die den zeitlichen Abstand zwischen zwei Flanken auf verschiedenen Eingängen misst.
Das Oszilloskop kann hier mit der maximalen Genauigkeit seines AD-Wandlers arbeiten, was in diesem Fall weit über die Darstellungsgenauigkeit hinaus geht. Außerdem ermittelt es den Mittelwert sowie den statistischen Fehler der Messungen.
Das vertikale Synchronisationssignal, welches bei analoger Signalzuspielung sowohl unter Verwendung eines D-Sub HD15- als auch eines DVI-I-Steckers über einen eigenen Kontakt dem Monitor zugespielt wird, ist gegen Masse leicht zu Messen. Der Sonderfall Sync-On-Green wird in diesem Artikel nicht weiter behandelt.
