Schlagwort-Archive: Verzögerung

Willkommen zu meinem nächsten Beitrag direkt aus meinem Fundus merkwürdiger Java-Lösungen für nicht ganz so alltägliche Programmierprobleme. Normalerweise würde ich meine kreativen Fehltritte sicher NIE veröffentlichen, aber dieses Mal mache ich noch eine Ausnahme, da ich glaube, es könnte den einen oder anderen auf die richtige Spur bringen, wenn er nicht weiter weiß.

Kürzlich war ich dabei, einen kleinen Indexer für dies und das zu schreiben, der einmal am Tag zu einer bestimmten Tageszeit Datensätze aus einer Datenbank zieht. Wofür genau spielt hier natürlich keine Rolle. Jedenfalls wollte ich dafür einen TimerTask verwenden, und der wird beispielsweise mit einem Delay (Verzögerung in Millisekunden bis zum ersten Start), und einem Intervall (Verzögerung in Millisekunden für alle darauffolgenden Starts) gefüttert. Randbedingung war, dass der Indexer einmal am Tag um dieselbe Uhrzeit läuft. Diese Uhrzeit soll man hinterlegen können. Den TimerTask-Kram habe ich weggelassen, und den eigentlichen Indexer-Code auch, um das Beispiel möglichst auf das Essentielle zu reduzieren.

Mein Problem war nämlich, dass ich auf Anhieb nicht wusste, wie ich herausfinden könnte, wann der nächstmögliche Zeitpunkt für eine festgelegte Uhrzeit ist, also ob beispielsweise 14:30 Uhr noch am selben Tag ist, oder erst am darauffolgenden Tag. Wieviele Millisekunden muss ich als Verzögerung des initialen Starts angeben, damit der Indexer zur nächsten Gelegenheit um eine bestimmte Uhrzeit losläuft?

Nach einer Weile habe ich mir die obige Lösung für mein simples Problem auserdacht. Die Methode timeToNextIndexTask() gibt einen int-Array zurück, der die Zeit in Stunden und Minuten beinhaltet. Das lässt sich ohne Schwierigkeiten in Millisekunden umrechnen.

Aber wie das so ist, fällt einem schon kurze Zeit später auf, wie sinnlos man sich den Kopf darüber zerbrochen hat, und dass diese Lösung zwar funktioniert, aber eigentlich viel zu aufwändig und der Code ziemlich wackelig ist. Meine Frage lässt sich mit zwei GregorianCalendar-Objekten sehr einfach beantworten:

Kurzgesagt, man legt einen GregorianCalender für den aktuellen Zeitpunkt an, und verstellt einfach die Uhrzeit, behält das Datum jedoch bei. Nun muss man lediglich mit Hilfe der Methode after() bzw. before() vergleichen, ob das verstellte Calendar-Objekt in der Vergangenheit oder in der Zukunft liegt. Falls es in der Vergangenheit liegt, muss man einen Tag dazuzählen, und schon hat man seinen gewünschten Zeitpunkt.

Junge pickelgesichtige minecraft-zockende Gamer verstehen nur wenig von ihrem eigenen … nunja … „Fachgebiet“. Das musste ich jedenfalls vor kurzem feststellen. Was ich zuerst für einen traurigen Einzelfall hielt und ignorierte, begegnete mir in den letzten Wochen so häufig, dass ich die Angelegenheit genauer analysieren musste. Ich habe die Probe gemacht und einige Meinungen zu dem Thema eingeholt. Man berichtete mir von ähnlichen Beobachtungen, was meine These bestätigte. Es scheint fast so als würde es bei dieser neuen Generation von Gamern überall laggen – vor allen Dingen im Gehirn.

Junge razermaus-schwingende headset-tragende Gamer sind zu blöd zwischen ruckeliger Grafik und einem Lag zu unterscheiden. Aber wir uncoolen Oldschooler kennen den Unterschied zum Glück noch, und müssen die Begriffe daher nicht wie Opfer hilflos durcheinanderwerfen. Daher keine Sorge: Mit Hilfe meiner fettkrassen Lehrstunde werden diese armen Seelen vielleicht nicht dumm sterben müssen. Also zumindest nicht ganz so sehr wie zuvor.

Beginnen wir mit einer einfachen Definition der beiden Fachbegriffe. Da ist zunächst der (oder das) sogenannte Lag. Ein Lag entsteht durch einen Engpass bei der Datenübertragung in einem Netzwerk. Er zeigt sich etwa als zeitliche Verzögerung zwischen Aktion des Spielers auf der Tastatur und entsprechender Reaktion der Spielfigur auf dem Bildschirm eines Spieleclients. Wahlweise könnte er auch als Input-Lag gemeint sein, wenn beispielsweise die Mausbewegung spürbar nachzieht. Beides habe ich in diesem Zusammenhang kennengelernt. So ein Lag bewegt sich in einem Bereich von wenigen hundert Millisekunden bis mehreren Sekunden. Ein Lag lässt sich dadurch an einem hohen Ping messen.

Kennen junge Gamer übrigens auch nicht: Netzwerkkarte, BNC-Stecker und T-Stück

Ruckelnde Grafik entsteht vorwiegend wenn die Hardware, die für das Rendern des Bildes zuständig ist, die benötigten Grafikoperationen nicht ausreichend schnell durchführen kann, bis das Bild gezeichnet werden soll. Es entsteht ein zeitlicher Rückstand, der nur kompensiert werden kann, wenn darauf folgende Bilder übersprungen werden (Framedrop). Das Bild ruckelt oder „stottert“. Die Bewegungen sind nicht flüssig, sondern abgehackt, wie ein Daumenkino. Manche sprechen im Extremfall auch von „Diashow“. Der Effekt wird verstärkt oder abgeschwächt, je nachdem wieviele Objekte auf dem Bild gerade zu sehen sind. Ruckelnde Grafik äußert sich in einer niedrigen Framerate, also alles zwischen 0 fps und 25 fps.

Bei einem Lag ist die entscheidende Komponente das Netzwerk und die Netzwerkhardware, etwa wenn im Hintergrund zuviele Downloads/Uploads laufen, und die restliche Bandbreite nicht mehr für die Datenübertragung im Spiel ausreicht. Dagegen ist es bei ruckelnder Grafik die CPU oder die Grafikkarte, beispielsweise weil die Auflösung zu hoch eingestellt ist und so die Kapazität der Hardware übersteigt.

Wir merken uns: Lag – hoher Ping. Ruckelnde Grafik – niedrige FPS. Lag – Spielfiguren reagieren verzögert auf Eingaben oder teleportieren plötzlich wie Zauberer in der Spielwelt herum. Ruckelnde Grafik – Diashow-Effekt, Animation der Spielgrafik ist abgehackt und nicht flüssig.

Wir folgern daraus: „Lag“ ist der falsche Begriff für das was diese Konsumenten DRM-verseuchter Spielekost meinen. Eigentlich meinen sie etwas, das man als „Ruckeln/Ruckler“, „Framedrop“, „low FPS“ oder „scheiß Framerate“ bezeichnen könnte. Es gibt sicher noch bessere Begriffe. Man denke nur mal an die Probleme mit den „Mikrorucklern“ bei einer SLI/Crossfire-Konfiguration von Grafikkarten, die man vor einigen Jahren noch von NVidia und ATI kannte. Niemand wäre auf die Idee gekommen, das Problem „Mikrolag“ zu nennen. Es sind eben keine Lags. Ein Lag ist was anderes.

Das Spiel ruckelt und der unaufgeklärte Gamer flucht: „Wieso laggt das denn so?“. Solche Szenen gehören mit diesem großartigen Artikel hoffentlich bald der Vergangenheit an. Ich bin zuversichtlich, die Welt damit ein bisschen besser und ein bisschen schlauer gemacht zu haben. In der nächsten Folge erkläre ich dann, warum HTML keine Programmiersprache ist. Achja: Dieser Artikel kann Spuren von Satire und Islamkritik enthalten!