Ab Mittwoch den 8. September 2010, 19:00 Uhr unserer Zeit, wird Linden Lab den Zugriff aller Emerald-Viewer auf das Second Life Grid sperren. Dies war bereits seit einiger Zeit absehbar und ist kein Beinbruch, da für alle Emerald-Liebhaber mit dem Phoenix Viewer ein würdiger Nachfolger bereit steht, der sogar im TPVD gelistet ist.
Linden Lab ließ es sich nicht nehmen, jeden Benutzer davon sogar per Email in Kenntnis zu setzen. Naja, es ist das Ende eines Projekts, das durchaus seine Spuren hinterlassen hat, aber von Leuten betrieben wurde, die ihrer Verantwortung teilweise nur bedingt dauerhaft gerecht wurden.
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 Befehlesping. 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!
