So arbeite ich mit LDAT
Das LDAT-System umfasst, wie bereits erwähnt) einen externen Lichtsensor, der sicher an der Vorderseite des Monitors befestigt wird. Das geschieht mit einem praktischen, elastischen Band. Dazu kommt noch die modifizierte Maus von Seite Eins. Die Oberseite des LDAT-Sensors hat zwei Pins für Verbindung mit der modifizierten Maus, durch die das Klick-Ereignis erfasst wird und eine Status-LED, die die Farbe wechselt, um die aktuelle Betriebsart anzuzeigen. Die Rückseite des LDAT-Sensors Gerät enthält einen Luminanz-Sensor, der die Änderung der Helligkeit auf dem Bildschirm misst.
Die Platzierung des LDAT-Geräts auf dem Bildschirm ist recht einfach. So positioniert man den Luminanz-Sensor über einem Bereich des Bildschirms, der eine Änderung der Luminanz oder eine Bewegung (Animation) anzeigt, sobald die linke Maustaste gedrückt wird (z.B. Mündungsfeuer). LDAT vergleicht dann die Zeitdifferenz zwischen dem genauen Zeitpunkt des Mausklicks und dem Moment, in dem sich das Licht auf dem Bildschirm ändert. Die LDAT-Software zeigt Ihre Latenzmessungen in Echtzeit an und kann mehrere Messungen durchführen und mitteln, wobei ein Histogramm mit einer Gaußschen-Kurve angezeigt wird. Manche Dinge, wie Klickfolgen lassen sich übrigens automatisiert auslösen. Hier wandert das Signal vom LDAT-Controller wieder zur Maus.
Messungen mit LDAT
Natürlich wird man nicht primär in normalen RPGs auf die allerletzte Millisekunde schauen, sondern eher in schnellen Shootern. Ein Battle Royale mit dicken Latenzen? Da helfen noch nicht einmal teure In-App-Käufe, da krankt es eigentlich immer nur am System. Das Schöne an LDAT ist ja, dass es mit jeder Hardware funktioniert, egal welche CPU oder welche GPU. Den ersten Schritt, den man immer gehen sollte, ist das Anschließen der Maus am High-Speed-USB, der bei AMD-Systemen möglichst an der CPU hängen sollte. Dazu kommt das Schließen nicht benögtigter Anwendungen im Hintergrund und das Abziehen aktiver USB-Geräte, die sich im Polling mit dazwischen quetschen könnten.
Bei Nvidia-Grafikkarten gibt es in den Treiber-Settings zudem auch die Möglichkeit, die Software-Latenzen zu verringen. Hier sollte man also im Bedarfsfall „Ultra“ aktivieren, wenn die eigene Grafikkarte nicht die allerschnellste ist (ab einer GeForce RTX 2070 Super abwärts). Das kann was bringen (muss aber nicht bei ganz schnellen Karten). Darüber hinaus kann man natürlich auch am Monitor alle Bildverschlimmbesserungen oder Scaling-Methoden vermeiden und beim Monitor selbst auf ein Gerät mit hoher Bildwiederholrate (ab 144 Hz, besser 240 Hz) und niedriger Response-Time zurückgreifen, was aber nur dann einen Sinn ergibt, wenn man diese Frame-Raten auch erreicht.
Das erste Bild zeigt eine Messung mit einer GeForce RTX 2080 Ti und einem DirectX11-basierten Simulationsprogramm als Vollbild. Die Klick-zu-Pixel-Latenz beträgt im Schnitt 20,8 ms, wobei der beste Wert bei 11.4 ms lag. Die Standardabweichung (stdev) beträgt 12,8 ms. Das Messergebnis wird allerdings auch von einem immer mal wiederkehrenden Ausreißer beeinträchtigt, der wohl auch an meinem Programm liegt, das nicht mit allerhöchster Priorität läuft, sonst läge das Mittel deutlich niedriger. Damit kann man allerdings recht gut leben.
Erinnert Ihr euch noch daran, was ich zum Fenstermodus schrieb, als ich auf der vorigen Seite die einzelnen Latenz-Blöcke aufgeführt habe? Wenn ich so ein Testprogramm als Fenster ausführe, dann ändert sich das Verhalten schlagartig! Hier habe ich einfach mal schnell selbst Hand angelegt, einen Viewport geschaffen und ein Rechteck, bestehend aus zwei Dreiecken direkt vor die Kamera in des Frameset der sehr einfachen Szene gehängt. Klickt man, wird das Rechteck weiß, ansonsten ist es schwarz. Im exklusiven Vollbild liegen dann die Werte wieder im Bereich dessen, was ich auch oben messen konnte. Da hier die Grafiklast zu vernachlässigen ist, sind diese Latenzen auch bei einer Radeon RX 5500XT sehr ähnlich.
Das Nächste, was ich gemessen habe, ist ein richtiges Spiel, dafür aber mit einer eher langsamen Grafikkarte in Form der GeForce RTX 2060 (ohne Super). Nun ist Far Cry New Dawn zwar nicht neu, dafür aber in Bezug auf die Hardware eher anspruchslos und ich wollte zudem sehen, was mit einem Spiel passieren kann, das nicht in NVIDIAs Empfehlungen explizit mit auftaucht. Die LDAT-Software kann eleganter Weise auch mehrere Messungen zusammenfassen, so dass ich hier bei mittleren Qualitätseinstellungen und in Full-HD gemessen habe. G-Sync war zudem aktiviert. Wie sehen zwei Bereiche, einmal mit der Treiber-Einstellung „Ultra“ und einmal ohne die Latenz-Verbesserung des Treibers. Der Unterschied ist also gut sichtbar!
Und falls mal wieder jemand den Schuss nicht gehört hat, dann kann es auch an der Latenz liegen. Die Audiomessung zeigt, dass die Tonausgabe in diesem Spiel eher einer Wundertüte gleicht. Ich habe dazu den Grafikausgang über die Grafikkarte gewählt und den Monitorausgang an LDAT angeschlossen. Die Messungen mit den geringen Latenzen habe ich im Freien gemacht, die Ergebnisse mit den mittleren und höheren Werten stammen aus einem geschlossenen Gebäude. Man erkennt also schon einmal sehr gut, dass die ganze Soundspielerei an der Echtzeit oft recht weit vorbeidriftet und man schon tot ist, bevor man sich selbst hört.
Zusammenfassung und Fazit
Die heutige Vorstellung ist natürlich nur ein kleiner Auszug dessen, was man mit LDAT so alles anstellen kann, wenn man Zeit, Lust und einen Plan hat. Das Ganze trägt natürlich noch den Touch einer exklusiven Kleinserie, könnte aber durchaus auf den Markt kommen. Funktionieren tut es jedenfalls und es lief auch alles schon recht stabil. Wie und wann ich es dann in die Metriken einbaue, muss ich sehen, aber es eröffnet wirklich interessante Möglichkeiten für die Messungen der größten Latenz-Blöcke im bekannten Schema.
Kommentieren