Da ich in SL drauf angesprochen wurde, wieso ich Daemonikas Kompetenz anzweifle, hier nun die wichtigsten Fehler.
Aus Daemonikas Blogpost
"Ja, der ganze Inhalt besteht nur aus Links zu Objekten auf dem Asset-Servern. Immer dann, wenn wir etwas auf dem Boden rezzen möchten, ziehen wir es nicht aus dem Inventar, sondern geben mit der Maus lediglich den Befehl, eine Anfrage des entsprechenden Links an den Asset-Server zu senden und augenblicklich beim Loslassen der Maus an der Stelle wo sie sich gerade befand das gewünschte Objekt hinzuschicken. Das bedeutet, die Objekte die wir rezzen, kommen direkt über das Netzwerk vom Asset-Server zu einem gewünschten Ziel auf der Region."
Zunächst was Theorie: ein Asset besteht immer aus Metadaten - d.h. ID, Name und anderes - und den Nutzdaten. Daemonika behauptet hier, dass die Nutzdaten vom Assetserver geliefert werden. Das ist erwiesenermaßen heutzutage
falsch.
Richtig ist, dass Linden Lab schon seit langem die Meta- von den Nutzdaten getrennt hat. Früher war das anders, da betrieb Linden Lab zu dem Zwecke eine fette Isilon-Instanz im Hause. Aber schon 2010 verschob Linden Lab alle Nutzdaten in Richtung Amazon S3. Damit liefert der Assetserver heutzutage nur noch einen Link zum entsprechenden Amazon S3 Token, und dies wird dann per HTTP geladen.
Übrigens Amazon S3, wer damit nichts anfangen kann: hochverfügbar, hoch skalierbar, extrem große Bandbreite bei der Anbindung ans Internet und auch als CDN zu gebrauchen. Da alle wichtigen Nutzdaten von Amazon S3 kommen, belasten diese die interne Infrastruktur und Bandbreite von Linden Lab nicht. Amazon S3 ist darauf ausgelegt, große Datenmengen hoch stabil und hoch verfügbar auszuliefern; SL ist da von der Bandbreite eher noch unter ferner liefen.
Damit komme ich dann zum nächsten Fehler: das Bandbreitenlimit.
"
Jeder der schon mal einen Film heruntergeladen hat, weiß im Grunde wie lange es mit 1000 kb/s dauert. Nun hat jeder Avatar ein maximales Limit von 1500 kb/s. Wenn wir jetzt berücksichtigen, das eine normal bebaute Region gut und gern mal 400 MB und mehr verwendet, kann das rezzen/aufbauen/scharf werden schon einige Minuten in Anspruch nehmen."
Richtig ist, dass es ein Limit gibt, das man im Viewer einstellen kann. Genauer: man kann im Viewer einen Maximalwert einstellen; der jeweilige Simulator aber entscheidet dann dynamisch, ob er den Maximalwert ausnutzt, oder eine niedrigere Bandbreite, wenn nötig.
Richtig ist auch, dass vor der Einführung von Amazon S3 und dem HTTP-Download über UDP die Texturen übertragen wurden; da aber Linden Lab schon seit langem diesen Übertragungskanal abgeschaltet hat, und es Texturen/weitere Nutzdaten nur noch über HTTP gibt, unterliegt der Texturdownload damit folgerichtig auch nicht mehr dem Limit von 1.500 Kbit/s. Damit ist auch diese Aussage von Daemonika schlichtweg
falsch; solch ein SL wäre ein unerträglicher Schnarchladen und wir schon alle entsetzt geflüchtet!
Die Wahrheit ist vielmehr, dass die Geschwindigkeit des Texturdownloads von Seiten Amazon/Linden Lab überhaupt nicht reguliert wird; es gibt auch keine direkte Einstellung im Viewer, dies zu beeinflussen. Einzig und alleine durch die Anzahl paralleler HTTP-Verbindungen kann man dies etwas beeinflussen, weniger Verbindungen bedeutet weniger genutzte Bandbreite. Oder man benutzt entsprechende Regulierungsmechanismen im Internetrouter wie Traffic-Shaper.
Vielmehr wahr ist durch diese Trennung, dass der SL-VIewer sehr wohl in der Lage ist, deutlich mehr als 1,5 Mbit/s an Bandbreite zu nutzen und dies ständig tut (sofern die verfügbare Bandbreite dies erlaubt), denn sonst würden moderne Sims ja ewig laden, was aber nicht der Fall ist. Fieserweise zeigt aber die Statistik im Viewer nur die genutzte UDP-Bandbreite an.
Wer's nicht glauben mag, der sollte einfach mal auf eine stark bebaute Sim einloggen und sich dazu den Bandbreitengraph seines Routers ansehen.
Daemonikas Darstellung vom "1,2 GB laden dauert ewig" ist damit ebenfalls ins Reich der Mythen und Legenden zu verbannen.
Was heutzutage noch über UDP übertragen wird, sind hauptsächlich die Bewegungsdaten und Avatarupdates. Und einzig und alleine auf diese hat der Schieber damit in Wirklichkeit noch einen Einfluss.
Weiter:
"
Lass in dieser Situation einen einzigen Gast crashen, weil sein Rechner oder Internet das alles nicht mehr packt. Dieser eine Gast löst in diesem Moment eine Kettenreaktion aus, wodurch die Region quasi in einer Schleife hängen bleibt. Ab jetzt wird immer wieder für jeden crashenden Avatar ein weiterer Avatar crashen. Nicht nur, weil die PCs eventuell mit der Situation überfordert sind, sondern weil das interne Netzwerk von Second Life ab jetzt ebenfalls ausgelastet ist und viele Avatare die jetzt neu einloggen möchten, wiederum die Login-Server und die Asset-Server ansprechen, schließlich wollen sie alle die Daten wieder anfordern."
Moderne Netzwerkinfrastrukturen in Rechenzentren sind auf Redundanz und hohe Übertragungsgeschwindigkeit ausgelegt. Was dem Außenstehenden als ein Rechner erscheint, ist häufig ein Load Balancer und dahinter ein ganzer Serverpark, auf den die jeweiligen Anfragen munter verteilt werden, damit keine Lastspitzen entstehen können.
1,2 GB in einem modernen Rechenzentrum zu übertragen ist ein Fliegenschiss - das ist gar nichts. Wenn jemand auf einem Simulator neu einloggt, dann kommt das meiste von Amazon S3. Wir können getrost davon ausgehen, dass Linden Lab fähig ist, ein modernes Rechenzentrum zu betreiben. Damit ist auch die obige Aussage einfach nur falsch.
Gehen wir mal davon aus, die Aussage von Daemonika wäre richtig - dann gäbe es in SL keine Livekonzerte, weil da ständig Leute fliegen und folgerichtig die Sim ja nur noch am Timeouts liefern wäre.
Apropos Timeout: was war früher das bekannteste Ergebnis eines Timeouts? Ruth. Ein Timeout bedeutet noch lange nicht zwangsweise, dass man aus Second Life fliegt. Im Falle eines Teleports allerdings ist dies nach wie vor möglich.
@Natascha Randt
Das ist die Kettenreaktion von der ich gesprochen habe.
Und das erste was wir machen, sobald wir Flugmailen bei Linden-Air sammeln, an Ort und stelle wieder einloggen. Das ist eine ganz normale Reaktion, doch fatal fuer alle anderen, die sich noch in dieser Lokation befinden.
Nun ist aktuell das Netzwerk damit beschaeftigt den betreffenden Avatar, der versucht wieder Online zu kommen, mit allen noetigen Daten zu versorgen. Jetzt hat der naechste, dessen Internet Leitung nicht gerade das Gelbe vom Ei ist das Problem, das fuer ihn manche Daten nicht rechtzeitig geliefert werden, weil irgend ein Time-Out das verhindert und schon crasht derjenige.
Jetzt will derjenige aber auch wieder rein und das ganze Spiel geht von vorn los.
Nun ist der Asset-Server nicht nur fuer diese eine Region und diesen einen Club zustaendig.
Lass es mal Freitag Abend sein und auf hunderten Regionen zig tausende Avatare gleichzeitig auf die Asset-Server zugreifen.
Ein Time-Out weil der Server nicht rechtzeitig antwortet und ein daraus resultierender Crash ist mehr als nur Wahrscheinlich.
Dann kommen noch alle dazu, die freiwillig reloggen, weil SL gerade kacke laeuft, die verbessern die Situation nun ueberhaupt nicht, sondern steuern zum allgemeinen Crash noch bei, sobald sie wieder einloggen.
Sh. oben - diese Erklärung stimmt einfach von vorne bis hinten nicht. Sie mag auf ein einfaches Opensimgrid zutreffen, aber auf Second Life ist sie nicht anwendbar.