Bartholomew Gallacher
Superstar
@Nelly: hier hast du meine Wall-of-Text, warum ich Daemonikas Ausführungen für unplausibel und falsch halte.
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.)
@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: