• Bitte schaltet eure Ad Blocker aus. SLinfo kann nur betrieben werden, wenn es durch Werbung Einnahmen erzielt. Vielen Dank!!
  • Wir freuen uns, wenn du dich in unserem Forum anmeldest. Bitte beachte, dass die Freigabe per Hand durchgeführt wird (Schutz vor Spammer). Damit kann die Freigabe bis zu 24 Stunden dauern.
  • Wir verwenden Cookies, um Inhalte und Anzeigen zu personalisieren, Funktionen für soziale Medien anbieten zu können und die Zugriffe auf unsere Website zu analysieren. Sie geben Einwilligung zu unseren Cookies, wenn Sie unsere Webseite weiterhin nutzen.

Klamotten Design & techniche Umsetzung

@Nelly: hier hast du meine Wall-of-Text, warum ich Daemonikas Ausführungen für unplausibel und falsch halte.

@Bartholomew Gallacher

Sorry, aber auch Amazon ist nicht unfehlbar.
https://t3n.de/news/amazon-aws-ausfall-zentralisierung-800871/
https://t3n.de/news/slack-trello-aws-problem-internet-800645/

Anstatt mich bei jeder dir bietenden Gelegenheit versuchen zu diskreditieren solltest du dich mal entscheiden.
Entweder du jammerst herum, wie veraltet doch die Technik von Second Life ist, oder du machst das Gegenteil.
Aber das Faehnchen in den Wind haengen, nur um mal wieder gegen mich zu wettern ist kindisch.

Das hat hier nichts mit Diskreditierung zu tun, sondern ganz einfach alleine damit, dass du dich hier mit voller Inbrunst als Expertin in manchen Themen darstellst, in denen du eben keine Expertin bist. Ich bin auch kein Experte, verstehe aber von der Materie immerhin genug, um hier Ungereimtheiten zu erkennen.

Du verbreitest hier schlicht und einfach veraltete als auch falsche Informationen, und es besteht die Gefahr, dass dir Leute diese Falschinformationen auch noch abkaufen und danach fälschlicherweise handeln. Und genau das kritisiere und dagegen argumentiere ich.

Wenn du mit Kritik nicht leben kannst, dann hast du doch genau zwei Möglichkeiten:

a) lass es einfach bleiben und widme dich fortan lieber Themen, von denen du wirklich Ahnung hast oder
b) recherchiere besser vorher genauer.

Außerdem lieferst du hier bisher nichts außer ein paar weiteren Allgemeinplätzen, die weder dazu geeignet sind, meine Behauptungen zu widerlegen noch deine weiter zu untermauern.

Aber da du und andere auch Belege für meine Behauptungen willst, liefere ich dir die hier doch mal sehr gerne:

1. Der Assetserver

Dazu verweise ich hier mal auf Maddy: http://echtvirtuell.blogspot.com/2017/03/neuer-asset-http-projekt-viewer.html
Und den originalen Linden Lab Blogpost: https://community.secondlife.com/blogs/entry/2142-new-assethttp-project-viewer-is-now-available/

Dazu dann diese Meldung: UDP wurde im Januar 2019 für den Texturdownload abgeschaltet
Quelle: http://echtvirtuell.blogspot.com/2018/10/infos-vom-tpv-treffen-am-19-oktober-2018.html

Damit ist meine Behauptung, dass der Bandbreitenregler in aktuellen Viewern nicht mehr den Texturdownload beeinflusst, belegt, da als Protokoll dafür nur noch HTTP zur Verfügung steht.

Und wer es nicht glauben mag, dass sein Viewer - sofern die DSL-Leitung mehr als 2 Mbit/s hergibt - beim Landen auf einer Sim deutlich mehr als 1,5 Mbit/s nutzt, der kann sich unter Windows einfach mal einen Trafficplotter ansehen, möge auf eine volle Sim gehen und dem bei der Arbeit zuschauen. Dafür kann man beispielsweise Netgraph nutzen (https://www.wintools.info/index.php/netgraph), oder was einem sonst eben noch so einfällt.

Die meisten Viewer hatten ohnehin schon lange als Standard auf den HTTP-Pfad umgestellt gehabt. Das bedeutet also nichts anderes, als dass der Viewer in Wirklichkeit zur Kommunikation die "maximale Bandbreite" + X benutzt, wobei X sehr große Peaks verursachen kann. Das kann durchaus schon mal in den zweistelligen Megabitbereich gehen.

Endgültige Mitteilung der Abschaltung vom Texturdownload über UDP: https://community.secondlife.com/blogs/entry/2513-obsolete-asset-fetch-disabled/

Und dass die Assets von Amazon S3 geladen werden, ist auch kein Geheimnis, das hat Linden Lab auch oft genug mitgeteilt. Wer es nicht glauben mag, der kann mit Hilfe von netstat im laufenden Betrieb ja einfach mal selbst nachsehen.

Die ersten Gehversuche waren seinerzeit 2009, als die Map dahin verschoben wurde und sich so die Downloadgeschwindigkeit massiv steigerte.

2. Was regelt der Bandbreitenregler denn nun eigentlich genau?

Alles, was noch über UDP in den Viewer reinkommt eben; wer genauer wissen will, was das ist, wird u.a. hier bei Linden Lab fündig: http://wiki.secondlife.com/wiki/Protocol#Binary_UDP

Früher kam darüber auch die Texturen/Inventar rein; das läuft heute über HTTP.

Wenn man sich das Firestorm-Wiki anschaut, dann wird auch da ganz klar erläutert unter https://wiki.phoenixviewer.com/fs_speedtest , das man die Statistiken über Shift-Ctrl-1 bekommt. Das Tooltip beim Traffic zeigt dann klipp und klar, dass dort nur der UDP-Traffic und sonst nichts gemessen wird.

UDP als Netzwerkprotokoll ist für Wegwerfdaten gedacht; es ist sehr simpel, aber garantiert keinen zuverlässigen Empfang. Es ist eine Einbahnstraße in Sachen Kommunikation. UDP war auch der Grund früher dafür, dass manchmal Texturen nach dem Laden korrupt waren, wenn unterwegs eben Daten verloren gingen; deswegen hat Linden Lab auch diesen Transportweg abgeschafft.

TCP/IP dagegen ist das Netzwerkprotokoll, auf dem HTTP/HTTPS aufbaut - es ist komplexer, aber garantiert dafür den zuverlässigen Empfang beim Empfänger.

2017 brachte bereits Nalates Urriah einen Beitrag zum Thema Leistungsoptimierung in Zeiten von HTTP: http://blog.nalates.net/2017/02/22/second-life-performance-changing/ - wer also meint, sich daran abarbeiten zu müssen, der kann das damit gerne tun.

Was haben wir noch? Ach ja... die Beispielrechnungen, also:

3. Zeitaufwandsabschätzungen, wenn Daemonikas Maximallimit von 1,5 Mbit/s wahr wäre

Hier stand ja mehrfach eine gut bebaute Sim - 400 Megabyte an Daten - mit 30 Avataren je 40 Megabyte - also 1,2 Gigabyte - im Raum. Mit diesen Zahlen hat Daemonika gearbeitet; ich habe auch keinen Grund, an diesen Hausnummern zu zweifeln.

Man kann nun ganz einfach anhand der verfügbaren Bandbreite sehr genau ausrechnen, wie lange es wahrscheinlich dauert, eine gewisse Datenmenge zu laden, sofern die Verbindung nicht abbricht und die Leitung nicht spinnt: man muss einfach Bit in Byte umrechnen - ein Byte sind 8 bit, also muss man die Bitwerte nur durch 8 teilen, und schon kann die Rechnung starten.

Also bei 1,5 Mbit/s oder 1,500 kbit/s liefert die DSL-Leitung im Bestfall diese Menge an Kilobyte pro Sekunde:
1,500 kbit/s / 8 = 187,5 kilobyte/Sekunde.

(Da die eingesetzten Netzwerkprotokolle auch noch einen gewissen Overhead besitzen, müsste man den Wert noch eigentlich um diesen bereinigen, also als Faustregel 80% des Maximalwertes annehmen. Das lasse ich hier mal einfach bleiben, denn es ändert ohnehin nicht viel.)

Wie lange benötigen also 400 Megabyte, bis sie vereinfacht durch die Leitung flutschen? Als korrekten Umrechnungsfaktor nehme ich hier die 1024.

Also: 400 Megabyte * 1024 = 409600 Kilobyte.

409600 Kilobyte / 187,5 Kilobyte / Sekunde = 2185,53 Sekunden.

2185,53 Sekunden / 60 = 36,40 Minuten!

Nehmen wir nun 1,2 Gigabyte für sich alleine:

((1,2 Gigabyte * 1024) * 1024) = 1.258.291,2 Kilobyte.

1.258.291,2 Kilobyte / 187,5 Kilobyte/Sekunde = 6710, 88... Sekunden.

6710 Sekunden / 60 = 111,84 Minuten oder in etwa 1 Stunde 52 Minuten.

Und die volle Sim inkl. aller Avatare also über 2 1/2 Stunden locker - schnarch, danke aber auch, wenn das so wahr wäre!

Das selbst auf gut besuchten Sims die komplette Szene - bei entsprechender Internetleitung vorausgesetzt - deutlich schneller komplett geladen ist, wird die Mehrheit aus eigener Erfahrung bestätigen können. Auch damit ist die Aussage, dass 1,5 Mbit/s das Maximallimit beim Texturdownload darstellt bzw. da drin enthalten ist, widerlegt.

(Und korrekt gerechnet müsste man auf die Beispielwerte noch 20% Zeit draufschlagen, weil das in etwa für den Protokolloverhead von TCP/IP mit UDP beim Transport einfach draufgeht, und dagegen kann man nichts machen. Das ist systembedingt.)
 
Zuletzt bearbeitet:
(Und ja, da ein Beitrag nur 10000 Zeichen enthalten darf, sind zwei Posts technisch notwendig.)

4. Die These vom crashenden Avatar, der andere Avatare auf der vollen Sim mit in sein Elend der Timeouts reißt

Oder anders gesagt: das Kernstück von Daemonikas Beitrag, dessen Erklärung weitgehend auf den bisher vorangegangenen Erläuterungen.

Ein wesentlicher Pfeiler dieser These ist dabei Daemonikas Ausführungen zum Thema Assetdownload&maximale Geschwindigkeit, da sie eine Verknappung/Limit der pro Benutzer zur Verfügung stehenden Geschwindigkeit voraussetzt, um den Rest zu erklären.
=> diese Ausführungen von Daemonika habe ich oben Stück für Stück widerlegt, sie sind einfach schlichtweg falsch und nicht zutreffend. Es stimmt einfach nicht, dass Second Life bei passender Voraussetzung nur maximal 1,5 Mbit/s liefert.

Da damit ein wesentlicher Pfeiler ihrer These, auf dem sie den Rest aufbaut, weggebrochen ist, wird es schon mal eng.

Dann kommen wir zum Thema: wie funktioniert eigentlich der Serverpark von Linden Lab, der Second Life bedient? Und hier wird es schwierig, da Linden Lab sich darüber - wie viele andere Unternehmen auch - weitestgehend in Schweigen hüllt.

Gesichert ist, dass der Viewer im normalen Betrieb gleichzeitig eine Vielzahl an unterschiedlichen Servern, die unterschiedliche Dienste bereitstellen, nutzt.

Eine ungefähre Aufstellung der unterschiedlichen Server findet sich im Second Life Wiki selbst: http://wiki.secondlife.com/wiki/Server_architecture

Allerdings ist diese als veraltet zu betrachten; man kann aber getrost davon ausgehen, dass die interne Architektur nicht einfacher geworden ist.

Daemonikas These ist nun verkürzt gesagt, dass zu Stoßzeiten das erneute Einloggen eines Avatars auf einer vollen Sim den Assetserver überlasten kann, dies bei bereits eingeloggten Avataren auf der Sim zu Timeouts führen kann und diese so ebenfalls fliegen.

Daemonika geht nun davon aus (Randnotiz im Blogbeitrag), dass Linden Lab seit Jahren unfähig ist ein Netzwerk und Rechenzentrum zu bauen und zu betreiben, dass mit im Normalbetrieb regelmäßig zu erwartenden Lastspitzen fertig wird. Da ihrer Meinung nach Linden Lab dazu unfähig ist, kommt es dann zu regelmäßigen überlasteten Servern - und Timeouts. Genau das und nichts anderes ist ihre These in der Randnotiz mit anderen Worten ausgedrückt.

Tut mir leid, aber für so blöde halte ich Linden Lab nun absolut nicht. Es mag sicher immer mal wieder einige ungeahnte Ausnahmesituationen geben, die zu einer Überlast führen können, aber den normalen Lastbetrieb hat Linden Lab sehr gut im Griff!

Interne Netzwerke in modernen Rechenzentren haben Backbones im Gigabitbereich und mehr; jeder 08/15-Rechner kommt heutzutage mit einer Netzwerkkarte daher, die bereits 1 Gbit/s bedienen kann, und wenn's sein muss, kann ein Host auch durchaus noch mehr bedienen. So etwas bekommt ein Avatar, der crasht und mal eben wieder einloggt, absolut nicht klein; die Internetanbindung der Rechenzentren wird ebenfalls nicht von schlechten Eltern sein, und auf den Regelbedarf der Benutzer plus deutlichen Puffer ausgelegt sein.

Abgesehen davon wird der Löwenanteil des Traffics zum Viewer nicht mehr von Linden Lab selbst, sondern Amazon geliefert. Und natürlich wird ein "Loginserver" in Wirklichkeit nicht nur ein Rechner sein, da man in solch kritischen Bereichen sogenannte "single points of failure" vermeiden will. Das ist vermutlich eher ein Loadbalancer, der die Last auf mehrere Rechner verteilt, und in einem zweiten Rechenzentrum steht dann wahrscheinlich für den Loginserver nochmal ein Backupsystem, das ggf. automatisch übernimmt.

Daher halte ich auch diese Randnotiz für absolut unplausibel und deswegen bewegen wir uns nun endgültig im Bereich der gehobenen Kaffeesatzleserei, denn wie Linden Lab intern arbeitet, weiß bis auf Linden Lab keiner genau. Solange also es dazu nicht bestätigte Einträge im JIRA oder belegte Aussagen von Linden Lab Entwicklern gibt, kann man das auf Grundlage von eigener Erfahrung und Beobachtung alleine eben nicht gesichert behaupten.

Genau das aber scheint hier geschehen; es steht natürlich Daemonika frei, ihre Meinung durch entsprechende, seriöse Quellen zu untermauern. Solange aber das hier nicht passiert, bleibe ich dabei, dass man mit der These endgültig den Boden dessen, was man weiß und gesichert sagen kann, verlassen hat - und fabuliert.

Natürlich gilt dies auch umgekehrt, keine Frage, und das Gegenteil beweisen ist auch nicht einfach.

Die Sache ist aber diese: ich habe schon den Boden, auf dem die These steht, weitestgehend zertrümmert. Wenn Daemonikas These wahr wäre, dann müsste es in Second Life doch ständig, stetig und überall auf vollen Sims zu den entsprechenden Stoßzeiten wegen ihrer Überlegungen zu Massencrashs kommen. Vor allem aber reproduzierbar, wiederholbar und sehr oft!

Das Ergebnis wäre eine unvergleichlicher Aufruhr, da vor allem die Community der Livesänger/Tributebands/DJs/Clubbesitzer darunter massivst zu leiden hätte. Dieser Aufruhr wäre wohl kaum unbemerkt an uns vorbei gegangen; wir hätten den schon längst bemerkt.

Ich jedenfalls kann mich nicht entsinnen, dass es regelmäßig zu Massencrashs von Avataren auf gut besuchten Sims kommt. Ein bißchen Verlust gibt es immer, und ab und an einen Fehler im Simulatorcode der zu Crashs führen kann, den Linden Lab aber meist flott behebt, aber diesen hier beschriebenen Teufelskreis habe ich noch nie erlebt - eher, dass mal eine Sim komplett den Bach runter ging, aber das hat Linden Lab ja schon seit langem recht gut im Griff.

Fazit: ich halte nach wie vor Daemonikas Hauptaussage für unplausibel und da schon die Voraussetzungen, auf denen diese aufbaut falsch sind, damit natürlich erst Recht für falsch.

Ach ja, und noch eines: deine Whataboutismen kannst du dir bitte sparen; dass ich Linden Labs Architektur, das betrifft vor allem den Client, in manchen Bereichen für veraltet halte - was übrigens belegbar ist - hat absolut nichts damit zu tun, was du erklärt hast - und ich dagegen argumentiert habe. Das ist eine völlig andere Baustelle.
 
Zuletzt bearbeitet:
@Bartholomew Gallacher
Offensichtlich hast du meinen Blog-Eintrag ueberhaupt nicht gelesen.
Ueber 90% von dem was du hier hin gekritzelt hast, bezieht sich in keinster Weise auf den Blog, welchen ich behaupte das du ihn gar nicht gelesen hast.
Vielmehr legst du mir immer wieder Worte in den Mund, die ich niemals gesagt habe und ziehst dich an Sachen hoch, die deinem eigenen Wunschdenken entspringen.
Auch das ich Linden Lab in dem Beitrag fuer unfaehig halte ist wiederum eine Luege deinerseits.

Wenn du den Blog-Eintrag gelesen haettest, waere dir aufgefallen, das ich den weitgehend recht Allgemein verfasst und so gut wie gar keine technischen Details genannt habe, mit Ausnahme des Limits der Bandbreite fuer Avatare.
Gut, wenn das nicht mehr aktuell ist, schoen, ich lass mich gern auf den neuesten Stand bringen und ueberzeugen, aber nicht so wie du es gemacht hast.
Dein Machwerk dient einzig allein zur Diskreditierung.

Im uebrigen, die Randnotiz bezieht sich einzig auf den einen Absatz und der ist nunmal Fakt.

Desweiteren beziehe ich mich auf eigene beobachtungen, in denen ich feststellte, das von einer Region beinahe alle Besucher auf einmal geflogen sind.
In der Vergangenheit habe ich das oefter erlebt und es stimmt, das ist deutlich seltener geworden, dennoch kannst auch du das mit deinem Erklaerungen nicht ausschliessen.
Vor allem nicht, da ich so eine Situation zuletzt erst dieses Jahr erlebt habe.

Im endeffekt hast du viel erzaehlt und nichts gesagt.
Nur weil du viele Fachbegriffe abgeschrieben hast, wird der Kern deiner Aussage nicht richtiger.

"Hochachtungsvoll"
Dae
 
Du stellst hier deine Meinung als Faktum dar, und belegst im Grunde gar nichts. Und anstelle in der Sache zu argumentieren, argumentierst du lieber über die Sache.
 
Quelle https://wiki.phoenixviewer.com/speedtest_de
Speedtestseite: https://brinkster.speedtest.net/

Kommentar Beispiel 1
Da 800 Kbps kleiner ist als 1500 Kbps, ist deine einzustellende Bandbreite demnach 800 Kbps(oder weniger)

Kommentar Beispiel 2
Da 4915 Kbps größer ist als 1500 Kbps, ist deine einzustellende Bandbreite demnach 1500 Kbps (oder weniger)

Dein eigener Link sagt das gleiche, halt nur auf Englisch.

https://wiki.phoenixviewer.com/fs_speedtest


"Netzwerk:" > "Maximale Bandbreite" auf "1500 kbit/s" einstellen.
Quelle: http://echtvirtuell.blogspot.com/2011/11/second-life-viewer-tipps-zu-den.html
Fakt ist auch, dass Anwender mit Highend-Systemen, bei 1500 kbit/s ihr Maximum an Viewer-Performance erreichen. Egal ob ihr Router oder Kabelmodem wesentlich schneller könnte.
Meinen Beobachtungen zur folge, verbraucht der Viewer bei Normalgebrauch ohne das Ereignis Einloggen oder Teleport im Durchschnitt 50 - 100 kbit/s.
Wenn die 1500 kbit/s kein Fixes Limit mehr sind, schoen dann stellen Pieks ueber diesen Richtwert kein Problem mehr dar.
Bemerkenswert finde ich auch, das der Standard Linden Viewer bei meiner eben durchgefuehrten Installation gleich 3000 kbit/s voreingestellt hat.

Damit hat sich diese Diskussion mit dir, fuer mich entgueltig erledigt und ich moechte mich wieder dem eigentlichen Thema dieses Trheads widmen.
Wenn dir das nicht genehm ist, eroeffne bitte einen neuen Themen-orientierten Thread.

"Hochachtungsvoll"
Dae
 
Zuletzt bearbeitet:
Duell wäre eine Möglichkeit - Pistole oder Säbel...oder doch lieber Schlagmichtotkeule ?

In den Morgenstunden des 31. Juni diesen Jahres könnte ich als Sekundant zur Verfügung stehen.:D
 
Ich bin grad eben erst durch Zufall über deinen Blogpost gestolpert und letztlich hier gelandet, @Daemonika Nightfire .

Es tut mir ja leid das sagen zu müssen aber auch ich halte deine Herleitung und Schlussfolgerung was das "Massensterben" angeht für grob falsch. Nicht nur das ich ja selbst schon viele high-traffic Events betrieben habe und das von dir beschriebene Phänomen nie beobachten konnte, auch deine technische Herleitung klingt für mich nicht richtig. Es kommt schon mal vor das es ein paar Avatare auf einmal raushaut, was aber meist an einem bestimmten Ereignis in der Umgebung zu tun hat (extremer Partikeleffekt ö.ä.; generell Dinge die das eigene System/Graka überlasten), aber von so einer Kettenreaktion hab ich noch nie gehört und nie erlebt.

Zumal das auch keinen Sinn ergeben würde, da der Server/Viewer auf einen Timeout beim Avatar-Laden nicht wie von dir beschrieben mit einem Disconnect reagiert, sondern einfach damit das der Avatar nicht vollständig angezeigt wird bis alles geladen ist. Alles andere technische hat Bart sehr sachlich dargelegt und verargumentiert (besser als ich es je könnte) und deine einzige, eher unsachliche, Reaktion darauf ist "Du willst mich nur diskreditieren" - find ich nicht so gut. Dein Fachwissen in scripten in allen Ehren, aber hier liegst du glaub ich einfach mal falsch.
 
Also mal vorab allen ein schönes, friedvolles Weihnachtsfest:)

Und nun mal eine Frage einer technisch eher unbedarften Person. Bisher hiess es immer im Viewer die Bandbreite auf max 1500Kb zu stellen und bei WLAN auf 500KB. Ist die Einstellung der Bandbreie im Viewer also nun egal?
 
Aus der Praxis:

Oft wenden sich Freunde/ Bekannte an mich, wenn sei massive Probleme in SL haben.
Unter Anderem stellt sich dann oft heraus, dass sie Paketverlust haben.
Meine erste Frage ist bei Paketverlust dann, was für eine Internetleitung genutzt wird und wie hoch sie die Bandbreite eingestellt haben.
Ist diese dann höher als die vom FS Team empfohlenen, hilft es, diese an die Empfehlungen anzupassen.

So ist das, egal was hier gezankt wird.

Einen schönen zweiten Weihnachtstag!
Tanja
 
Also mal vorab allen ein schönes, friedvolles Weihnachtsfest:)

Und nun mal eine Frage einer technisch eher unbedarften Person. Bisher hiess es immer im Viewer die Bandbreite auf max 1500Kb zu stellen und bei WLAN auf 500KB. Ist die Einstellung der Bandbreie im Viewer also nun egal?

Nein, ist sie nicht. Man sollte einfach den Empfehlungen folgen und fertig.

Genauer: die Einstellung der Bandbreite betrifft nur alle Informationen, die über das Netzwerkprotokoll UDP übertragen werden. Etwas Paketverlust gehört bei UDP dazu, da dieses Protokoll den Empfang nicht überprüft noch sicherstellt; übermäßiger Paketverlust allerdings nicht. Es ist gedacht für Wegwerfdaten, wie z.B. die Uhrzeit, die wenn es nicht ankam erneut verschickt werden.

Über UDP werden heutzutage noch vor allen in SL diese Informationen übertragen:

- Avatarbewegungen
- Objektupdates
- Tastatureingaben

Mehr dazu hier: http://wiki.secondlife.com/wiki/Protocol

Der Viewer regelt übrigens bei Bedarf automatisch runter - aber niemals rauf. Und wie zuverlässig dieser Automatismus ist, darüber streiten sich die Geister.

Was jedenfalls nicht darüber übertragen wird, das sind Texturen. Die werden heutzutage ausnahmslos per HTTP (das auf den TCP/IP-Netzwerkprotokollen aufsetzt) übertragen und von der Amazon S3 Cloud ausgeliefert, ebenso kommt das Inventar heutzutage darüber.

Der Bandbreitenregler ist damit für Texturen wirkungslos; das hat zur Folge das ein SL-Viewer durchaus wenn er nur auf 1500 kbit/s eingestellt sein sollte, dennoch auf einer gut besuchten Sim locker 30 Mbit/s oder mehr durch die Leitung saugen kann. Der Rest sind eben die Texturen, und das ist auch gut so, weil sonst würde eine Sim einfach im Zeitalter der Meshbodies und sonstwas nur noch ewig laden.
 
... Bisher hiess es immer im Viewer die Bandbreite auf max 1500Kb zu stellen und bei WLAN auf 500KB. Ist die Einstellung der Bandbreie im Viewer also nun egal?

Also, nach meiner Erfahrung ist es keineswegs egal.

Das Team des Firestorm Viewers empfiehlt in seiner eigenen Wiki, eine Prüfung Checking Your Real Bandwidth vorzunehmen.

Dieser Test prüfe, was tatsächlich bei mir ankomme, heißt es. Und ich denke, diese Prüfung kann man auf jeden Fall durchführen, ganz gleich, welchen Viewer man verwendet. Den Anweisungen des Tests zu folgen, ist etwas fummelig. Scheint aber zu funktionieren.
 
Zuletzt bearbeitet:
Dass nicht mehr viel über UDP läuft ist richtig; einiges aber läuft nach wie vor darüber. Jedenfalls ist beim Firestorm-Support nach wie vor eine der ersten Einstellungen die abgefragt wird die eingestellte Bandbreite.
 
Also irgendwie übersteigt diese Diskussion (besonders die Kontroverse zwischen @Bartholomew Gallacher und @Daemonika Nightfire) technisch VOLL meinen Horizont, dennoch habe ich versucht, dahinterzusteigen, weil ich ab Januar wohl wieder über die Anschaffung eines neuen Comouters nachdenken muß. Hier schien aber durchzuschimmern, die Performance wäre gleich lausig, egal wie gut Computer und DSL seien, wegen irgendeiner Kennzahl von 1500 oder so.

In Daemonikas Blog las ich " Ihr könnt nun noch so fette Rechner und noch so dicke DSL Leitungen haben, an dem Limit von 1500 kb/s kommen wir alle nicht vorbei und müssen diese Ladezeiten gänzlich in Kauf nehmen."
 
@Leora Jacobus ich wuerde dir empfehlen, dir einen Rechner zuzulegen, der deinen beduerfnissen gerecht wird und nicht zwingend auf SL zugeschnitten ist.
Wenn wir den Teufel an die Wand malen, hast in absehbarer zeit erneut das selbe Problem, das die Leistung deiner Hardware zu wuenschen uebrig laesst.
Du musst fuer dich entscheiden was dir wichtig ist und wenn du nachhaltig auf etwas laengere Sicht einen Leistungsfaehigen Rechner moechtest, empfehle ich dir einen der fuer SL grob gesagt ueberkandiedelt ist.
Das muss jetzt nicht zwingend ein High End Gaming PC sein, waere aber nicht die schlechteste Idee.
Wichtig ist, das deine Hardware bei bedarf noch erweiterbar ist, wie zum Beispiel mit einer staerkeren Grafikkarte, oder zusaetzlichen RAM, ohne das du gleich ein Neues Mainboard kaufen musst.

Auf diese Weise habe ich mir ebenfalls ein paar Jahre ruhe erkauft. ;)
Mein Rechner geht jetzt ins dritte Jahr und kann mit den Systemvoraussetzungen von SL immer noch locker mithalten, ohne das ich in der Zwischenzeit irgend etwas ausgetauscht habe.

LG
Dae
 
Ich möchte jetzt hier keine alten Wunden aufreißen...Aber :) ich bin über den Blog Eintrag von Dae auf diesen Thread gestoßen.

Die Aussage auf dem Blog:

Jetzt lass aber mal einen Avatar lediglich 40 MB verbrauchen und stelle bis zu 30 Avatare in einen Club. Das entspricht nun rund 1200 MB (1,2 GB). Es wäre naiv zu glauben, das die gesamte Gruppe innerhalb einer Sekunde deutlich geladen und gerendert ist. Ihr könnt nun noch so fette Rechner und noch so dicke DSL Leitungen haben, an dem Limit von 1500 kb/s kommen wir alle nicht vorbei und müssen diese Ladezeiten gänzlich in Kauf nehmen.

ist definitiv falsch und sollte vielleicht langsam mal korrigiert werden.

Ich kam nämlich auf den Blog Eintrag weil mich jemand in SL um Hilfe bei seinen Performanceproblemen ansprach und u.a. traf ich dort die Aussage: Das mit den 1.500 ist auch so ne alte Legende...und schon hatten wir den Salat. Mit wurde dann der Blog unter die Nase gerieben.
 
Daemonika hat ja zu dem Thema Performance kürzlich oder schon seit längerem - keine Ahnung - auf ihrer Homepage einen Artikel veröffentlicht, wo sie sich unter anderem zum Thema Leitungsausnutzung und Viewercache auslässt, guckst du hier: https://www.daesigns.de/projecte/performance/#avicom

Darauf aufmerksam geworden bin ich, weil dieser Artikel durch ein anderes Blog beworben wurde.

Es hat sich da ein wenig was getan, nun ist nicht mehr 1500 kbit/s das Limit laut Daemonika, sondern 3000 kbit/s. Aber es stimmt eben nach wie vor absolut nicht. Man sollte doch so langsam mal akzeptieren können, dass man sich in dem Detail geirrt hat und nicht nach wie vor Falschheiten unters ahnungslose Volk bringen.

Ich habe das dann zum Anlass genommen, mal meinen Senf zu den Themen Sichtweite/Bandbreite und Viewercache bei mir dazulegen inklusive was daran genau falsch ist: https://blog.no-carrier.info/2021/0...rformance-im-artikel-von-daemonika-nightfire/

In Kurzform: Second Life kann eine moderne Internetleitung problemlos bis zum Anschlag auslasten. Der Viewer zeigt nur die UDP-Datennutzung an und auch nur diese regelt der Netzwerk-Schieber, aber nicht was über TCP/IP runtergeladen wird. Texturen aber, die 95% des Traffics ausmachen, werden ausschließlich über das HTTP-Protokoll geladen - und dieses setzt eben auf TCP/IP auf. Wer die wirkliche Auslastung beim Besuch einer belebten Sim wissen will, sollte sich mal einfach den Netzwerkgraphen seines Routers anschauen.

Bei mir sieht das dann beim Besuch vom Exhale (Sim mit > 60 Avatare) nämlich so aus, VDSL50, also Leitung dicht (Einheit kbyte/s):
after.png


Und zum Thema Cache: es ist nicht egal, auf welcher Art Speichermedium man das Ding ablegt.

Es gibt eine ganz klare Reihenfolge, von schnell nach langsam: SSD >> Festplatte > USB.

Der Nutzen von Defragmentierung ist meist nicht messbar, und den Cache auf derselben Platte in eine extra Partition auslagern erhöht nicht den Flaschenhals maximale IOs pro Sekunde auf einer Festplatte.
 
Zuletzt bearbeitet:

Users who are viewing this thread

Zurück
Oben Unten