Über den Lag, dessen Ursachen und dessen Bekämpfung in Second Life

Eines der Hauptgesprächsthemen und Hauptärgernisse in Second Life überhaupt ist der mehr oder minder ständig anwesende Lag. Es gibt kaum ein Thema, um das sich so viele Mythen und Legenden ranken wie dieses, wo es selbst technisch versierten Mitmenschen schwer fällt, alleine die Fakten zu betrachten und viele regelmäßig stolz mit ihrem Halbwissen meinen glänzen zu müssen. Also stellen wir uns die scheinbar einfache Frage: was ist Lag genau und was kann man dagegen machen?

Lag wortwörtlich betrachtet

Lag kommt aus dem Englischen und bedeutet wörtlich ins Deutsche übersetzt so viel wie Verzögerung, Rückstand oder Nachhinken. Es geht also darum, dass etwas nicht so schnell verarbeitet wird, wie es verarbeitet werden sollte und sich daher spürbar langsamer als normal anfühlt. Der Begriff „Lag“ kommt dabei ursprünglich aus dem Bereich der Netzwerke und bezeichnet dort eine besonders hohe Latenzzeit, streng genommen kann er auch nur da entstehen. In Second Life wird er aber auch häufig für Effekte gebraucht, für die alleine der Viewer verantwortlich ist. Pedanten klamüsern diese Begrifflichkeiten dann gerne auseinander, im Rahmen dieses Artikels aber verwenden wir der Einfachheit halber und weil es sich bereits so eingebürgert hat den Begriff „Lag“ für Beides.

Lag zuerst rein physikalisch auf der Netzwerkebene betrachtet

Schauen wir uns zuerst einmal die Netzwerkebene und deren physikalische Grundlagen an. Die Physik spielt dabei eine wichtigere Rolle, als man zuerst annehmen mag.

Die wichtigste physikalische Konstante für alle Verbindungen zu Second Life ist dabei die Lichtgeschwindigkeit c, die vereinfacht ausgedrückt bei ca. 300.000 km/s liegt. Angenommen, es sitzt nun jemand in Frankfurt/Main, er baut eine Verbindung zu Second Life auf und landet im Rechenzentrum in San Franzisco. Die Entfernung Luftlinie nach San Francisco beträgt dabei etwa 9140 km, gehen wir mal von 10.000 km aus, da die Kabel sicher länger sein dürften als die reine Luftlinie.

Wie lange braucht es nun, bis eine Eingabe im günstigsten Fall von Hamburg nach San Francisco gelangt ist? Einfach, man rechne: 10.000 km / 300.000 km/s = 0,033 s. So weit der Wert der Theorie, da auf dem Weg noch mehrere Router liegen, die dem Ganzen zusätzliche Latenz hinzufügen, dürfte ein realistischer Wert irgendwo bei 0,04 bis 0,05 Sekunden liegen. Damit ist also die Information angekommen, wird im Simulator verarbeitet und geht danach wieder auf den Rückweg. Das bedeutet, in der Praxis haben wir bestenfalls irgendwelche um die 0,1 Sekunden oder 100 Millisekunden.

Diese Zeit misst man mit Hilfe des Befehles ping. Wenn es auf dem Weg zu Second Life irgendwo im Netzwerk einen Stau geben sollte, dann macht sich das folgerichtig in höheren Zeiten als normalerweise erwartet bemerkbar.

Auftritt: Server Side Lag und Client Side Lag

Soweit der kleine, netzwerktechnische Exkurs und was Lag im eigentlichen Sinne ist. In Second Life selber wird zwischen zwei Arten von Lag unterschieden, nämlich dem

• Server Side Lag sowie dem
• Client Side Lag.

Also einerseits der Lag der aus diversen Gründen auf dem Server entsteht und dem Lag, der sich alleine auf dem eigenen Computer bemerkbar macht. Gegen Server Side Lag kann man dabei nur bedingt etwas tun, während man den Client Side Lag natürlich weitgehend in den Griff bekommen kann. Schauen wir uns also mal beide Bereiche genauer an!

Die Anatomie des Server Side Lags

Second Life vermittelt uns das Bild einer virtuellen Welt. Damit dies wirklich gut funktionieren kann, muss uns der Client mindestens 25 voneinander unterscheidbare Bilder in der Sekunde anzeigen können, die uns der Simulator aus den USA in einem fortwährenden Datenstrom liefert. Das ist der biologischen Funktionsweise unseres Sehapparats geschuldet. Anders ausgedrückt bedeutet dies, dass der Simulator maximal 0,04 Sekunden Zeit hat für den Benutzer eine Szene komplett zu berechnen, damit wir Second Life als wirklich flüssig wahrnehmen können. Braucht er für die Berechnung dieser einzelnen Bilder deutlich länger, dann gerät der sonst flüssig wahrnehmbare Strom ins Stottern und wir empfinden das als Lag. Normal läuft eine leere Sim serverseitig maximal mit 45 Bildern pro Sekunde, d.h. die Berechnung eines Bilds darf dabei maximal sogar nur 0,022 Sekunden dauern.

Nun ist der Simulator ein viel beschäftigter Geselle und erledigt viele, wichtige Aufgaben gleichzeitig. Dabei überträgt er eine Vielzahl an Informationen an die zu ihm verbundenen Avatare. Der Simulator bearbeitet alle Bewegungen innerhalb der Region, er ist zuständig für die Übertragung des im Sichtfeld des jeweiligen Avatars befindlichen Prims samt den dazugehörigen speicherintensiven Texturen (was zuerst nicht sichtbar ist, wird einfach erst später übertragen), weiterhin muss er die Physik aller Avatare und physikalisch aktiven Objekte berechnen sowie alle in der Region befindlichen Skripte abarbeiten.

Nun kann es sein, dass in einem oder mehreren Bereichen gleichzeitig der Simulator „zu viel“ zu tun hat und ein Backlog entsteht. Mögliche Gründe sind zum Beispiel zu viele physikalische Objekte in der Region, sehr viele Avatare, zu schnell wechselnde Texturen (z.B. durch Skripte) und eine zu hohe Skriptlast. Nicht jeder diese Tätigkeit wird vom Simulator übrigens mit der gleichen Priorität erledigt, Skripte werden z.B. mit einer deutlich geringeren Priorität dabei abgearbeitet als das Bewegungstracking, Bewegungsübertragung und die Physik. Das wichtigste beschränkende Merkmal am Server ist natürlich neben dessen Netzanbindung (meinetwegen 100 Mbit/s) dessen Rechenleistung, also der Prozessor sowie der zur Verfügung stehende Hauptspeicher.

Wie geht nun all das zusammen? Einige Beispiele:

• wenn ein Avatar in eine Region teleportiert, dann lädt dieser alle Prims und Texturen, die sich in seinem Sichtfeld befinden. Wenn ein Avatar alleine ankommt, macht das kaum was aus, wenn aber 20 Avatare fast gleichzeitig ankommen und der Simulator gleichzeitig 20x diese Informationen übertragen muss, dann kann sich das in einer spürbaren Verzögerung bemerkbar machen. Limitierend ist hierbei die Netzwerkanbindung des Servers.
• Wenn zu viele physikalische Objekte in der Region aktiv sind, kann es sein, dass die Berechnung der Bewegung all dieser Objekte länger dauert als für eine Wiedergabe in Echtzeit ideal wäre. Die Region fühlt sich langsamer an, bis das manchmal regelrechte Hänger spürbar sind.
• Ein weiterer, wichtiger Punkt sind Skripte. Diese zerfallen wiederum in zwei Kategorien, nämlich einmal alle am Avatar befindlichen Skripte und alle in der Region aktiven Skripte. Die in der Region aktiven Skripte sind meist in der Mehrzahl, wenn es zu viele aktive Skripte gibt, dann kann es sein, dass die Region alleine so viel Hauptspeicher braucht, dass der Server anfängt, den virtuellen Speicher der Festplatte zu nutzen. Merke: langsam. Estate Owner und bisher nur die wirklich haben dafür die Werkzeuge in der Hand, die rechenintensivsten Skripte herauszfinden und ggf. dagegen vorzugehen. Gerade auf Rollenspielsims ist das ein Prozess der ständigen Optimierung.
  Was natürlich jeder selber in der Hand hat sind die Skripte, die am eigenen Avatar laufen. Vor allem HUDs, die Radare und dergleichen darstellen, benötigen ordentlich Rechenleistung. Früher gab es daher dabei die Empfehlung, man solle diese doch bitte abnehmen, da sie Lag produzieren würden.
  Heute ist das nicht mehr der Fall, da der Simulator der Skriptabarbeitung maximal ein gewisses, hartes Zeitfenster zur Verfügung stellt. Wenn alle Skripte nicht innerhalb dieses Fensters abgearbeitet wurden, dann führt er den Rest in der nächsten Zeitscheibe aus. Das Ergebnis dabei ist gefühlter Lag. Dennoch ist es nicht falsch, solche Radare abzunehmen, da die Ausführung der entsprechenden Befehle einiges an Rechenzeit erfordert. Eine andere Sache, die ebenfalls ständig aktiv sind, sind natürlich AOs. Manche Clients wie z.B. Imprudence, Phoenix oder Emerald unterstützen das schon lange clientseitig, wenn man die Chance hat, so etwas zu nutzen, sollte man es tun.
  Ein weiterer Punkt bei Skripten ist: jedem Skript steht ein gewisser, maximaler Hauptspeicher zur Verfügung. Wenn nun jemand in eine Sim teleportiert mit älteren Primhaar aus sagen wir 300 Prims und in diesem befinden sich 300 aktive Resizerskripte,  dann benötigt alleine das Haar schlimmstenfalls 300*64 KB = 19 MB an Speicher. Wichtig ist daher bei Primattachments, sofern diese Resizerskripte alter Bauart enthalten (es gibt inzwischen neue, da braucht es nur ein Skript für ein komplettes Linkset): einmal anpassen und dann löschen.
• Übrigens Skripte: wenn ein Avatar in einer Sim ankommt, dann lädt der Simulator in einem Rutsch all dessen aktive Skripte und führt sie ab dann aus. Wegen eines Fehlers (?) in der Sprache Mono, in der LSL inzwischen implementiert worden ist, kann es dann schlimmstensfalls sein, dass der Simulator schon mal einige Gedenksekunden einlegt und die Framerate kurz in den Keller geht. Das spüren dann unabhängig vom Standort alle Avatare in der Sim. Ebenso kann es sein, wenn man versucht wohin zu teleportieren und der Teleport funktioniert nicht wirklich, dass es dann klappt, wenn man die wichtigsten geskripteten Objekte auszieht.

Die Anatomie des Client Side Lags

Soweit der serverseitige Lag, nun betrachten wir genauer den clientseitigen Lag. Das wichtigste zum Anfang: auf den Rechner und die Internetverbindung kommt es an! Wenn der Rechner zu schwach auf der Brust ist, dann hilft die schnellste Verbindung nichts. Also: es muss eine einigermassen moderne CPU samt genügend Hauptspeicher (2 GB sollten es sein) inklusive flotter Grafikkarte und Internetleitung (500 kbit/s oder mehr) sein. Second Life ist nun einmal ein grafikintensives Unterfangen und wer da an der Grafikkarte spart, wird nie seines Lebens glücklich werden.

Was kann nun dafür sorgen, dass der Client sich stotternd anfühlt? Einiges:

• Texturen. Texturen in Second Life werden im rechenintesiven JPEG2000-Format gespeichert, und deren schnelle Darstellung auf dem Bildschirm benötigt einiges an Rechenzeit. Kommt der Rechner dabei nicht mehr nach, kann es zu spürbaren Verzögerungen geben. Ebenso beim Laden der Texturen, diese müssen natürlich durch die Internetanbindung kommen, je schneller, desto besser. Da sich im Extremfall aber bis zu 80 Rechner im selben Simulator befinden, hat man das nur bedingt in der eigenen Hand.
• Eine zu geringe Internetanbindung, unter einer gewissen Geschwindigkeit macht eben Second Life einfach keinen Spass.
• Zu wenig Hauptspeicher (mindestens 1 GB sollte es zwingend sein, richtig Spaß macht es erst ab 2 GB) und eine zu lahme CPU tragen auch dazu bei.
• Das Laden von zu vielen Texturen auf einmal kann ebenfalls zu clientseitiger Verzögerung führen.
• Zu viele Partikel oder rotierende Objekte.

Häufig wird auch gesagt, dass es gut wäre, die eigene Avatar Rendering Coast (kurz ARC) zu minimieren. Dies zeugt nur von einem falschen Verständnis dieser Kennziffer. Die ARC ist ein Maß, dass einzig und alleine darüber Aussage gibt, wieviel Arbeit die Grafikkarte mit dem Rendern des jeweiligen Avatars hat, über die Serverlast sagt sie nichts aus. Natürlich, je höher desto mehr Arbeit, aber es sie trifft keine Aussage über das Verhalten der eigenen Grafikkarte. Bei Primhaaren zum Beispiel ist es so, dass diese vielleicht aus 200 Prims bestehen, aber nur zwei Texturen. Trotzdem treibendiese die ARC ganz schön nach oben. Wenn sich jemand über eine zu hohe ARC aufregt, könnte man dem genauso gut raten, sich eine bessere Grafikkarte zuzulegen. Meistens aber kommt diese Botschaft nicht an, daher ignoriert man es am Besten.

Was aber kann man nun neben einer guten Hardwareausstattung tun, um clientseitigen Lag zu minimieren?

• Man kann die Bandbrreite auf einen passenden Wert einstellen. Wenn man z.B. nur DSL 1000 hat macht es wenig Sinn, dort 1500 kbit/s einzustellen, dadurch geht zu viel verloren. In der Praxis hat sich bei vielen ein Wert zwischen 500-1000 bewährt.
• Man sollte die Sichtweite reduzieren. In Shops und bei Veranstaltungen empfiehlt sich ein Wert von 64 m, normal irgend etwas im Bereich von 64-96m.
• Man sollte die Internetverbindung natürlich nicht übermässig noch mit anderen Sachen, wie z.B. Filesharing, belasten.
• Wenn die Grafikkarte eher schwachbrüstig ist, dann hilft es auch, die Qualität der Grafikeinstellung zu minimieren.
• Wenn der Prozessor des Rechners mehrere Kerne hat, sollte man „Run Multiple Threads“ einschalten, damit Second Life auch wirklich alle und nicht nur einen nutzt. Das macht sich stark spürbar.

Fazit
Lag in Second Life und dessen Entstehung ist eine erstaunlich komplexe Geschichte. Es ranken sich viele Mythen und Legenden darüber, und die Meisten glänzen bestenfalls dabei mit fundiertem Halbwissen. Um den Lag zu minimieren gibt es eine Vielzahl an Möglichkeiten, nicht alle aber liegen davon in der eigenen Hand. Wenn die Kombination insgesamt passt, dann ist es möglich, ein weitgehend lagfreies Second Life Erlebnis zu bekommen.