ARTIKEL

14. August 2010: Der Ingenieur spricht: ein Kommentar zu Karls Stiefvaters Lag-Analyse 

Unser aller Ingenieur bezieht sich in diesem Beitrag auf die Aussage von Karl Stiefvater zur Begründung des aktuellen Lags in SL. Am Schluß des Artikel kündigt er ein großes Life-Experiment an: SecondLife vs. OpenSimulator - wer lädt eine ganze Sim schneller?

Zwischen Systemen mit statischem Inhalt (z. B. WoW) und dynamischen Inhalt (z. B. SL) besteht natürlich ein wesentlicher Unterschied darin, dass tatsächlich der Inhalt zur Aktualisierung permanent zum Benutzer übertragen werden muss (Content-Live-Streaming). Bei geschickter Umsetzung und vor dem Hintergund moderner Netzwerktechnik stellt dies aber in der heutigen Zeit kein Problem mehr dar. Schliesslich bekommen wir unser Fernsehen inzwischen auch sauber über das Internet, dessen Technik Broadcasting und asymetrische Bandbreitenaufteilung gut beherrscht. Das Problem muss also an anderer Stelle liegen.

Ich dachte immer, in den USA sei SL schneller und wir würden das extreme Lag und die sich äusserst langsam aufbauenden Texturen ausserhalb der USA nur wegen der netzwerktechnisch etwas grösseren Distanz zum US-Internet erleben.

SL scheint aber also tatsächlich auch in den USA fürchterlich langsam zu sein. Chris Pirillo moniert in diesem Beitrag die SL-Performance ziemlich deutlich als “arsch-eklig”, mir ist SL auch immer viel zu langsam und ein Besuch macht daher kaum Spaß.

Aber wenn die Ursache nicht an der Leitung über den grossen Teich liegt, dann hat LL definitiv ein Problem. Vor allem, da OpenSimulator ja nachweislich bereits heute sehr viel schneller ist und weder mit Lag noch mit langsam aufbauenden Texturen zu kämpfen hat. Bandbreite zwischen Server und Viewer für einen schnellen Download wird natürlich benötigt, keine Frage. Aber wir leben ja inzwischen im >2Mbit/s (meistens) Zeitalter, also sollte das Thema nicht an der Bandbreite scheitern.

Nun geht OpenSimulator bzgl. der Texturen bereits schon länger den Weg eines http-basierten Downloads, hier ist also für Tempo gesorgt. SL muss das erst noch kopieren. Und OpenSimulator hält in seinen Regionsservern jeweils einen komletten Cache aller Texturen, so dass diese nicht immer erst vom Assetserver geholt werden müssen. Ausserdem liegt der Rest der Daten einer Region (speziell die Prims) im Hauptspeicher, hier geht die Datenbeschaffung für die Auslieferung also auch fix. OpenSimulator nutzt also schlanke Protokolle, Festplattencache und Hauptspeichercache zur Performancesteigerung.

Das eigentliche Live-Streaming ist sogar in SL bereits gut organisiert. Naheliegende Objekte werden zuerst berücksichtigt und es werden nur die Texturen übertragen, die der Viewer noch nicht im Cache hat. Die Prims sind hocheffizient, da im Gegensatz zu Meshes nur ein paar Grundparameter übertragen und die Daten erst im Viewer in Meshes umgerechnet werden. Hier wird also auch sehr effizient mit den Bandbreitenaforderungen umgegangen und die Arbeit auf die inzwischen leistungsfähigen Benutzerrechner ausgelagert.

Ich verstehe also “der wichtigste Einzelgrund für den Lag beim Rendern von Objekten in der inhärenten geometrischen Ineffizienz der Prims liegt” nicht. Mal sehen, übersetzen wir das erst einmal ...:



Qarl definiert in seinem Post erst mal die verschiedenen Arten von Lag:
1) there’s download speed lag - which effects how quickly objects rez.
2) there’s render speed lag - which effects how “responsive” the viewer feels.
3) there’s viewer-sim latency lag - which effects how “responsive” avatar movement feels.
4) there’s sim-side compute lag, which effects all kinds of movement and script performance.
5) there’s backbone lag, which effects (among other things) chat.

Meine Analyse:
1) Downloadspeed-Lag liegt an der Leitung zum User.
2) Renderspeed-Lag liegt an der Performance von CPU und Grafikkarte des Benutzerrechners.
3) Viewer-sim-Lag liegt an der Viewersoftware und an der Performance des Benutzerrechners.
4) Sim-side-Lag liegt der Serversoftware und an der Performance des Servers.
5) Backbone-Lag liegt an der Qualität der Internetanbindung des Serverrechenzentrums.

Qarl sagt in seinem Post, es läge an 2) und 3) und könnte behoben werden. Das stimmt, denn 2) und 3) sagen unter dem Strich nur aus, dass entweder der Benutzerrechner zu langsam für die Anforderungen des Viewers ist oder einfach der Viewer äusserst ineffizient arbeitet.

Da Prims als abstrakte Beschreibung der Objekte schneller über die Leitung gehen, als Meshes mit all ihren Punkten, Flächen und Texturkoordinaten und wir ja hier nur über die Optimierung der durch LL zu verantwortenden Komponenten reden, kann Qarl also nur meinen: “Der Mechanismus, der aktuell im Viewer zur Umwandlung und Darstellung von Prims verwendet wird (Prim nach Mesh-Konvertierung) ist extrem ineffizient. Hier kann die direkte Verwendung von Meshes eine erhebliche Performanceseigerung bewirken.” Das verstehe ich dann auch wieder. Uff uff !!!

Wie wäre es mit neuen Grafikkarten für das 3D-Internet, die Prims hardwarebeschleunigt in Meshes umwandeln? Prims an sich sind ja sehr effizient, zusätzlich Meshes für komplexere Strukturen zu haben wäre natürlich auch nicht schlecht.

Spannend ist, dass OpenSimulator mit den aus realXtend kommenden Modulen bereits heute Meshes beherrscht und die Viewer aus dem realXtend-Projekt diese auch anzeigen können. Bisher hat sich nur niemand an die Rückportierung der neuen Features in die auf dem SL-Viewer basierenden Projekte herangewagt und die von Grund auf neu geschrieben Viewer lassen noch auf sich warten.

Sollte es so einfach sein? Einfach den perfekten Viewer zusammenbasteln und dann hebt OpenSimulator ab? Zumindest einen aktuellen Test der derzeitigen Möglichkeiten von OpenSimulator, Meshmodulen und realXtend-Viewer sollte man dringend mal auf den Laborprojektplan setzen, um zu einer sauberen Einschätzung zu kommen. Ich werde mal meine Jogis fragen, ob ich eine Woche Bastelurlaub bekomme ... (Jogis im Chor:NEIN!)

Na gut, statt Theorie jetzt Praxis. Ich habe ja aktuell gerade die Möglichkeit zumindest den Unterschied der normalen Situation zu testen, also werde ich es auch tun.

Da wir die Full Prim-Sim Cybavaria (ca. 15.000 Prims, viele Texturen) bereits in einem internen Test komplett mit allen Prims und Texturen von SL nach OpenSim übertragen haben, werde ich gleich mal einen fairen Vergleich zum Thema “Sim-Erstanzeigeperformance im Viewer, SecondLife gegen OpenSimulator” durchführen. Mit gelöschtem Cache stelle ich mich in SL und in OpenSimulator an dieselbe Stelle und schaue was passiert. Unser Testsystem ist technisch up to date, SL sollte das ja auch sein.

Mal sehen wer gewinnt ...

aus: Hinter der Matrix  von .(JavaScript must be enabled to view this email address)  | 0x kommentiert, 1390x angesehen |

   
  © 2010 TalentRaspel virtual worlds Ltd. Kontakt  Impressum