Daemonika Nightfire ist eine altgediente und erfahrene Skripterin in Second Life, die sich gerne und oft zum Thema Lag äußert, dazu auch zitiert wird und von vielen als eine Expertin darin angesehen wird.

Während sie meistens in den Grundlagen mit ihren Meinungen richtig liegt, so liegt sie dann auch leider in manch wichtigen Details ziemlich falsch.

Diese Kommentare verstehe ich als Errata zu Daemonikas Beitrag „Performance“ auf ihrer eigenen Webseite.

Im Wesentlichen geht es mir dabei um die zwei Kapitel „Sichtweite“ und „Cache“, die dringend eine Korrektur benötigen. Fangen wir also mal damit in genau der Reihenfolge an an.

Sichtweite
Der grundlegende Sachverhalt, dass je größer die Sichtweite man umso mehr Daten übertragen muss, bis alles gerezzed ist, ist natürlich richtig.

Eindeutig falsch ist aber, dass Second Life unfähig ist, eine moderne DSL-Leitung mit 16 Mbit/s und mehr völlig auszulasten. Das schafft SL nämlich heutzutage problemlos, wie ich hier in aller Ausführlichkeit erklären werde. Ebenso, wo der Denkfehler in der Aussage Daemonikas liegt.

Zur Erklärung: im Second Life Viewer gibt es den berühmten Schieber, mit dem man die „Maximale Bandbreite“ einstellen kann. So sieht er aus, und die maximale Geschwindigkeit, die man hier einstellen kann, ist in der Tat 3000 kbit/s:

So weit, so gut. Dieser Regler verändert auch in der Tat die Bandbreite, die der Viewer benutzt – aber nur in Bezug auf das Netzwerkprotokoll UDP. Über UDP wurde ganz früher alles übertragen, heute damit deutlich weniger. Benutzt wird es u.a. noch für Kommunikation, Telemetrieupdates der Avatare und andere Sachen.

Es gibt auch eine Statistikanzeige, die die vom Viewer aktuell benutzte Bandbreite anzeigt, diese sieht so aus:

Wie schon der Tooltip korrekt anzeigt, handelt es sich dabei um die „Message Systtem Daten“ und der Bereich heißt auch nur „Empfangene UDP-Daten.“ Der vertikale Balken oben rechts ist übrigens nichts anderes als eine kleine Anzeige des oben gezeigten Balkens.

Den Hauptanteil der benötigen Bandbreite für Übertragungen aber machen Texturen aus. Texturen wurden früher per UDP übertragen, aber dies wurde schon vor langem abgeschaltet.

Texturen werden heutzutage per HTTP, also dem Webserverprotokoll, aus der Amazon Cloud über TCP/IP übertragen.

Viel Text damit für zwei einfache Tatsachen: der Viewer zeigt einem die Bandbreite, die er für den Download der Texturen aktuell benötigt, gar nicht an.

UND

Der obige Schieber hat keinerlei Einfluss auf die Downloadgeschwindigkeit von Texturen!

Daemonikas Denkfehler besteht einfach darin zu meinen, dass der obige Schieber noch einen Einfluss auf den Texturdownload hat – und damit auch dessen Bandbreitenmaximum von 3000 kbit/s. Beides ist nicht mehr der Fall.

Wer die wirklich genutzte Bandbreite für den Download einer belebten Sim anschauen will, der sollte sich also lieber auf eine Quelle verlassen, die dieses auch richtig anzeigt. Am Besten nutzt man dafür einen Echtzeitgraphen im eigenen Router.

Sollte man das machen, fällt einem sofort auf wenn man einen Club wie z.B. „Exhale“ rezzed: ja, SL gibt richtig Gas!

So sieht meine VDSL50-Internetleitung aus Routersicht aus, wenn sich mein Netzwerk langweilt, ein Balken entspricht dabei genau einer Sekunde:

Und so sieht derselbe Graph aus knapp 45 Sekunden nach Ankunft im Exhale aus:

Ich selber nutze VDSL mit bis zu 50 Mbit/s; die Angaben oben sind in Kilobyte/Sekunde. Einfache und grobe Rechnung: 50000 / 8 sind ca. 6250 Kbyte/Sek.

Fazit: wie man oben genau sehen kann man Daemonikas Aussage, dass SL eine Leitung mit 16 Mbit/s und mehr nicht voll ausnutzen kann weil bei 3000 kbit/s Schluss ist, getrost ignorieren. Sie ist schlicht und ergreifend einfach sachlich falsch, denn SL reizt die komplette eingehende Bandbreite bis zum Anschlag aus!

Cache
Es ist richtig, dass man nichts aus dem Cache laden kann, was vorher nicht drin ist.

Die Idee eines Caches ist aber auch, dass manche Texturen eben häufig genutzt werden. So haben z.B. viele Sims einfach dieselbe, langweilige Grastextur, die wir alle kennen. Sowas beschleunigt das Laden einer zweiten Sim mit derselben Textur um einiges, man hat einen Hit erzielt – die Textur wird aus dem Cache direkt geladen, und nicht erst über das Internet angefordert.

Falsch ist allerdings auch hier wieder die Aussage, dass man zwischen 16 Mbit/s und 200 Mbit/s keinen Unterschied spüren würde. Diesen Unterschied gibt es nämlich sehr wohl. Warum, habe ich ja gerade oben erklärt.

Falsch liegt Daemonika leider auch in ihrer Aussage, dass es keine Rolle spielen würde, auf welcher Art von Datenträger sich der Cache befinden würde. Hier gibt es eine eindeutige Reihenfolge, nämlich von schnell nach langsam der Art SSD >> Festplatte > USB-Stick.

Der Grund dafür liegt in der Art, wie der Textur-Cache auf dem Datenträger angelegt wird, nämlich so:

Es handelt sich dabei zunächst einmal um einen Ordner mit genau 16 Unterordnern. In diesen Unterordnern werden dann Texturen möglichst gleichmäßig verteilt gespeichert, das sieht dann z.B. im Ordner a so aus:

In einem vollen Cache mit 4 GB oder größer können also in einem Unterodner durchaus schon mal 4000 Dateien und mehr liegen. Das heißt 40-100000 Einzeldateien sind durchaus für einen kompletten Cache möglich und keine Seltenheit.

Eine einzelne Sim kann dabei durchaus locker einige Hundert Texturen oder mehr noch laden wollen. Damit ein Cache Sinn macht, bleibt dieser natürlich auch nach dem Beenden einer Viewer-Sitzung weiterhin auf der Festplatte bestehen. Der Flaschenhals hierbei ist nun die Zugriffsgeschwindigkeit des benutzten Speichermediums.

Moderne Betriebssysteme, egal ob MacOS, Windows oder Linux, bringen von Haus aus einen eigenen, dynamischen Dateisystemcache für Lese- und Schreibzugriffe mit. Das Betriebssystem versucht, hier häufig genutzte Daten möglichst lange im Speicher zu halten, um so nicht erst auf die langsameren Speichermedien zugreifen zu müssen.

Das Problem beginnt nun nach einem Neustart des Betriebssystems, wenn man das erste Mal Second Life besuchen will. Der Viewer-Cache ruht nämlich ungenutzt auf der Festplatte, und dementsprechend ist auch der Cache vom Betriebssystem leer. Mit anderen Worten ist hier nun das Speichermedium wirklich gezwungen, jede angeforderte Datei erst einmal anzufahren und dann zu lesen.

Der Viewer-Cache hat eine Art Inhaltsverzeichnis, das schnell abgefragt werden kann, ob es eine Textur gibt oder nicht. Danach muss diese aber auch vom Speichermedium geladen werden.

Und hier kommen nun endgültig die physikalischen Unterschiede zwischen SSD und Festplatte zum Tragen.

Moderne Festplatten haben neben der Speicherkapazität zwei wesentliche Kenngrößen, nämlich die Übertragungsrate im sequentiellen Lesen und die mittlere Zugriffszeit. Die mittlere Zugriffszeit gibt damit genau die benötigte Zeit im Mittel an, die ich für das Laden einer beliebigen vom Dateisystem brauche.

Typische Festplatten im Desktopbereich haben Zugriffszeiten im Bereich von 8-12 Millisekunden, d.h. schaffen es im besten Fall in diesem Zugriff 83 bis 125 Dateien in einer Sekunde zu liefern.

Eine SSD dagegen hat Zugriffszeiten, die 100x schneller als bei Festplatten sind. Damit schlägt die SSD in Sachen Geschwindigkeit des Caches die Festplatte immer spürbar um Längen, diesen Zuwachs kann man deutlich im Viewer erkennen.

USB-Stick kann in der Theorie von der Zugriffszeit her zwar auch schnell sein, aber dazu braucht man auch einen USB3-Stick. Den hat nicht jeder. Ein anderes Nadelöhr hier ist das verwendete USB-Protokoll und die oft schlechte Qualität der USB-Hubs. Daher liegen sie bestenfalls mit Festplatten gleichauf, darauf zählen würde ich aber meistens nicht.

Die Kurzfassung hier: SSD ist besser und deutlich schneller als eine Festplatte, und für den Cache immer die erste und beste Wahl. Dann kommt die Festplatte und der USB-Stick ist bestenfalls eine Notlösung, mehr aber auch nicht.

Damit kommen wir noch zum zweiten Unterpunkt in Sachen Cache. Hier schlägt Daemonika die Auslagerung auf eine eigene Partition oder gleich Festplatte vor.

Was ist nun davon zu halten? Typischer Fall von „Ja, aber“ – es kommt darauf an, was man im eigenen Rechner für Möglichkeiten verbaut hat.

Wenn man in der Tat nur zwei Festplatten im Rechner hat, und sowohl das Betriebssystem als auch der Viewercache liegen auf derselben Festplatte, dann macht das Verschieben des Caches auf die zweite Festplatte durchaus Sinn.

Warum macht das Sinn? Ganz einfach weil Windows (und andere Systeme auch) gerne ständig die Betriebssystem-Festplatte für alle möglichen Dinge benutzt, und sei es nur Swapping. Der Cache muss sich dann hier die Nutzung der Festplatte mit anderen Programmen teilen. Ebenso macht es, wenn man nur eine Festplatte hat, keinen Sinn, den Cache auf eine eigene Partition zu verschieben. Warum? Weil sich dadurch die Zugriffsgeschwindigkeit leider nicht verbessert, alle Partitionen müssen sich dieselbe Zugriffsgeschwindigkeit nämlich teilen, denn nur durch das Anlegen einer neuen Partition auf derselben Festplatte wachsen der leider nicht magischerweise neue Schreib-/Leseköpfe.

Verschiebt man ihn auf eine reine Datenplatte ohne Betriebssystem, dann hat man meistens die volle Leistungsfähigkeit dieser Platte nur für sich. In genau dem Fall macht das Sinn.

Hat man aber eine SSD und eine Festplatte, dann sollte der Cache immer auf der SSD liegen. Warum? Siehe oben, weil SSDs in Sachen Zugriffsgeschwindigkeit Faktor 100x schneller als Festplatten sind, darum. Was das Betriebssystem sonst noch so an Zugriffen veranstalten sollte hat für die Performance hier nur einen meist untergeordneten Einfluss.

Bleibt noch das althergebrachte Thema Defragmentieren der Festplatte: bringt das eigentlich wirklich was? Kurz gesagt: nein. Moderne Dateisysteme, auch NTFS, sind so konstruiert, dass sie schädliche Defragmentierung so gut es geht schon von Haus aus vermeiden.

Und der mögliche Performancegewinn nach einer Defragmentierung ist oft so winzig, dass man ihn im Normalbetrieb gar nicht merkt. Wer danach aber besser schlafen kann, kann es dennoch beruhigt laufen lassen. Es nützt zwar nicht (viel), aber schadet in der Regel auch nicht. Natürlich benötigt es Zeit und damit Strom.

Abgesehen davon ist das ein Thema nur für Festplatten, weil SSDs aus gutem Grund nicht defragmentiert werden sollten. Wer SSDs defragmentiert verkürzt möglicherweise deren Lebensdauer, da SSDs intern völlig anders arbeiten als eine Festplatte.