Die Statistikleiste von 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.

15 Gedanke zu “Über den Lag, dessen Ursachen und dessen Bekämpfung in Second Life”
  1. Danke! Zwar habe ich schon Deinen Tipp von gestern befolgt und den Artikel gelesen, doch hier ist es doch deutlich zusammengefasster. Ich habe zwar 2GB RAM, eine Grafikkarte die im oberen Drittel der Skala herumgeistert(e) (ist auch schon zwei Jahre alt) und eine 16k-Leitung – aber trotzdem muss ich für den Kampf die Grafik auf niedrig stellen, damit ich nicht rettungslos hinter meinen Gegner haue. Tharkan empfiehlt mir auch immer, während des Trainings die AO auszumachen – bringt das denn was? Laut Deinem Exkurs würde ich ja zu „nein“ tendieren – aber sicher bin ich nicht. Ich spiele mit dem Viewer 2 – kannst Du mir einen ökonomischeren empfehlen, der mir vielleicht mehr FPS ermöglicht?

    1. Also eine 16K-Leitung alleine hilft auch nicht weiter, wenn der Rechner nicht mehr mit dem Entpacken der Texturen nachkommt oder neben dir 40 weitere Avatare auf der Sim sind, die ordentlich Texturen nuckeln.

      Wichtig ist, dass man bei Mehrkernsystemen wirklich “Run Multiple Threads” aktiviert hat, das bringt eine Menge und vorher mal einfach ein wenig die Gegend in Ruhe rezzen lässt. Die AO während des Trainings auszumachen bringt weniger etwas für einen alleine, da eine AO normal nicht die starke Skriptlast erzeugt. Da liegt auch viel in der Grauzone, Mythen und Legenden eben. Allerdings müssen die Animationen der AO auch erstmal von allen in deinem Sichtfeld ebenfalls geladen werden, insofern bringt das für diese eine Erleichterung.

      Der Viewer 2 ist von den FPS her schon sehr gut, ansonsten ist vielleicht Phonix einen Blick wert. Ansonsten es ist bei SL durchaus normal, dass die Framerate einbricht, wenn sich im eigenen Sichtfeld viele Avatare tummeln sollten, wichtig ist eben, dass sie sich mindestens weiter im Bereich 30-40 FPS bewegt.

      1. Naja – ich kann froh sein, wenn ich in Lydius auf 20 komme – wenn mehr als zwei Leute da sind, sind selbst 20 utopisch! 40 hatte ich definitiv noch nie. Mehrere Kerne hab ich meines Wissens nicht, aber ich frag mal Lola, da das ihr alter, abgelegter Rechner ist.

        1. Es ist doch einfach: nenne mir die Eckdaten deines Systems (CPU, Hauptspeicher, Grafikkarte, Betriebssystem) und dann wissen wir, wozu er fähig ist oder auch nicht. Eine einfache Möglichkeit ist auch noch: die Bildschirmauflösung massiv reduzieren und Second Life im Vollbild ausführen.

  2. danke Bart ist wirklich interessant.

    manchmal erinnert mich die Lag Geschichte an die angst vor Hexen, insbesondere Sachen die man Persönlich nicht mag machen ja immer am meisten Lag ^^

  3. Hi Meister
    Ich stehe vor einem Umzug und meine Leitung wird stat 16k nur noch 2,8k hergeben
    Rechner ist Dual Core – werde ich Spass haben Herr Doktor?

    1. Ich denke doch, das läuft so schnell genug und wenn es erst einmal im Cache ist, noch schneller. In den aktuelleren Viewern wurde zudem ein Bug behoben, so dass der Object Cache (einfach eine Datei, die pro Sim auf der Platte speichert, wo sich mit welcher Textur welches Prim befindet) endlich richtig funktioniert. Damit ist nach dem erstmaligen Rezzen bei Wiederbesuch eine Sim, die im Cache ist, fast schlagartig aufgebaut.
      Nur weil man 16Mbit/s DSL hat, heißt das noch lange nicht, dass man auch 16Mbit/s von Linden Lab geliefert bekommt. Außerdem ist im Viewer ein dynamischer Bandbreitenbegrenzer eingebaut, der automatisiert ständig aktiv ist und die Bandbreite laufend justiert. Das Problem selbst teilweise bei 3 Mbit/s ist heutzutage mehr, dass je nach Nutzung der Sim der Simulator inzwischen dank HTTP-Übertragung die Texturen mit einer derartigen Geschwindigkeit durch die Leitung schaufelt, dass der Rechner mit dem Dekodieren und Anzeigen so flott gar nicht mehr nachkommen kann. Und bei Dekodieren gilt eben: zwei Kerne schaffen mehr als einer, vier Kerne gleichzeitig mehr als zwei.

  4. Na das klingt doch gut…dann such ich mal den Schalter für DUALCORE = YES!

    PS-toller Beitrag – ichhabe ihn in unserem Forum gelinkt und hoffe du hast ncihts dagegen? FCalls doch – einfach nachher IM

  5. Hi Bart,
    interessantes Thema und gut erklärt von Dir.
    Habs auf der HairFair auch wieder gemerkt. Einer pampt den anderen an und spammt den Chat damit zu wegen des hohen ARC. Es ging aber dort auch nichts. Es war meine dritte HairFair und diesesmal fand ich es besonders schlimm. Der Lag trifft einen ja öfter mal und in den letzten Monaten fingen dann noch diverse Sim Besitzer an Zooby Pets zu verbieten oder auf 1 Pet zu beschränken. Die machen angeblich sooooviel Lag. Bei einem Estate Vermieter gabs in den Verträgen sogar eine Script Beschränkung. Die war auf 78 Scripte beschränkt. Wobei der nicht so ganz angeführt hat wie das aussehen soll. Sein aufgestelltes Haus und die Pflanzen auf dem Land hatten alleine schon etwa 40. Megaprims werden auch oft nicht erlaubt. Macht das denn wirklich alles so einen bösen Lag? Wenn ja wirds aber langsam sehr schwer noch ein Plätzchen zu finden wo man sich gemütlich einrichten und heimisch fühlen kann.
    Deshalb find ich Deinen Artikel sehr hilfreich und werd ihn auch mal verbreiten, wenn wieder jemand dummes Zeug quatscht.

    LG Bosabi

    1. Also… bei den Skripten kommt es auch darauf an, wieviel Rechenzeit sie brauchen. Kurz gesagt, vom Speicherverbrauch her sicher nicht, denn der maximale Speicherverbrauch pro Skript ist genormt und für alle Skripte gleich. Allerdings wenn die Dinger sehr viel Rechenzeit benötigen und davon gehe ich bei einem Zooby-Pet aus, dann kann es schon sein, dass die Ausführung aller Skripte dadurch eben auch gefühlt „langsamer“ wird. Ein typischer Fall, wo das auch in den Verboten drinstand, war Sion Chickens gewesen. Andere Sims wiederum meiden Hippo/Apez.Biz-Vendoren, diese gelten auch als rechenintensiv.

      Das Megaprims Lag verursachen ist inzwischen auch im Bereich „Mythen und Legenden“ anzusiedeln. Früher mit Havok 1 als Physik Engine haben sie das angeblich getan, aber wir sind inzwischen viel weiter bei Havok 7 und Megaprims sind problemlos einsetzbar.

  6. Mich würde ja mal lieber das gegenteil interessieren. Nicht wie Vermeide ich Lag denn das weis ich selber und ich trage auch nur lächerliche 19 Scripte an mir rum Mich würde viel mehr interessieren wie kann ich Absichtlich Lag Erzeugen. Nicht nur für mich sondern auch für andere. Sorry mag doof klingen aber s gibt eben so manche Locations in sl gegen die Lindenlab nichts macht und da muss man eben selber hand anlegen

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert