• 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.

Identifizieren lag-erzeugender Scripte

Auf der SIM, auf der ich mich angesiedelt habe, herrscht seit einiger Zeit immer wieder erheblicher Lag (FPS-Werte erheblich unter 5). Da sich auf der SIM generell und auch zu diesen Zeiten nur sehr wenige Leute aufhalten (im Schnitt selten mehr als 5), kann es m.E. nur an lag-erzeugenden Scripten liegen. Das Deaktivieren der eigenen Scripte auf meinem Land reduziert den Lag aber nur unerheblich.

Bevor ich mich nun aber beim SIM-Owner beschwere würde ich mich gerne vorab mit den Nachbarn, die diesen großen Lag verursachen direkt und gütlich einigen.

Daher meine Frage: wer von Euch kennt ein geeignetes Tool, mit dessen Hilfe ich die lagerzeugenden Scripte auf der SIM orten und identifizieren kann?
 
ich scripte jez schon seit mehr als 2 jahren in sl und habe bis jetzt noch keine funktion gesehen die es einem ermöglicht die last eines anderen scriptes zu erkennen ;) da hilft nur den simowner ansprechen.
 
ich weis zwar nicht aber ich als owner kann im simtoll sehn was welches skript an msec verbrauch hat auch den gesamten wert und alles ...hat das was damit zu tun bzw . daran halten wir uns wen wir auf unseren FP und LP nach böasen skripten suchen
 
MayaOphelia Mathy schrieb:
Daher meine Frage: wer von Euch kennt ein geeignetes Tool, mit dessen Hilfe ich die lagerzeugenden Scripte auf der SIM orten und identifizieren kann?

Als Normaluser sieht man das wohl kaum. Aber der Sim Owner bzw. Estate Manager sieht im Estatemenü unter Debug/Top Scripts die genauen Laufzeiten der Scripte. Die könnten Dir da genauere Auskünfte geben

lg
Chris
 
Das klingt mir eher danach, dass der Server auf welchem die SIM gehostet wird, ein technisches Problem hat. Der Estate-Owner oder einer der Manager sollte mal einen Neustart durchführen.
 
Hi

mhh, könnte auch daran liegen das mal wieder das ein oder andere Script neugestartet werden sollte, kommt ab und zu mal vor das die sich etwas "verschlucken". Habs zB bei animierten Tieren ab und zu.

Auch ein weitverbreites Problem, Scripte welche eigentlich überflüssig sind, aber immer noch laufen bzw in Bereitschaft stehen.

Grüße

Fe
 
Lag hat viele Ursachen, wie kommst Du darauf das es ausgerechnet die Scripte sind?

Zunächst musst Du unterscheiden zwischen client- und serverseitigem Lag. Clientseitig kannst Du nur die FPS messen, geben aber keine weitere Auskunft darüber was tatsächlich die Ursache des Problems darstellt.

Viele timerbasierte Scripte sind nur eine mögliche Ursache, meistens verschusselt von Scriptern die nicht wirklich Ahnung von formvollendeter Programmierung haben oder sich nicht viel Mühe mit der Optimierung geben.

Dann gibt es aber auch sehr oft Lag durch falsche oder zu große Texturen die verwendet werden. Klamotten oder Skindesigner verwenden oftmals Texturgrößen von mindestens 1024x1024 Pixeln, da kommt dann schon mal ein einfaches Unterhemd mit 150 KByte Download daher. was sich schnell summieren kann. Ein aufwendig hestalteter Hut, mit 100 Prims, wobei jeder Prim seine eigene 1024er Textur hat...naja kannste Dir ja ausrechnen den Rest...wenn man eine 14 Megabyte Datei von einer Webseite laden müsste, das kann schon etwas dauern und das nur bei einem einzelnen Hut.^^
Hinzu kommt das viele "Designer" die empfohlene Skalierung nicht einhalten. Sprich 128x128, 256, 512 oder 1024 Pixel. Wenn man eine Textur mit krummen Werten verwendet, beispielsweise 1000x700 Pixel, dann muss das System die Textur erst einmal umrechnen in eine der Standardgrößen, bevor sie auf einem Prim dargestellt werden kann. Umrechnen = Rechenzeit.

Nächste Ursache, massenhafte Verwendung von Flexiprims. Ganz besonders bei Haaren ein weit verbreitetes Problem. Jede Strähne soll möglichst einzelnd sichtbar sein und im Wind hin und herwippen. Das ist schön, benötigt aber Rechenzeit. LindenLab empfiehlt sogar selbst, nicht mehr als 3 Flexi Prims pro Objekt zu verwenden. Designer like wurde das aber mißgedeutet und umbenannt in, Hauptsache sieht gut aus, nach mir die Sinnflut.

Komplexe Objekte sind vermutlich auch eine Ursache möglichen Lags. Zumindest nach meinem Basisverständnis aus der 3D Szene, geht es in vielen Videospielen nicht um Objekte oder Prims, sondern um die Anzahl der Vertices (Punkte eines Objektes). Je mehr Punkte ein Objekt hat um so komplizierter ist es darstellbar. Ein einfacher Würfel hat 8 Punkte. Eine Kugel dagegen vielleicht 256, je nachdem wie LL sie definiert hat. Sculpties je nach größe der SculptMap. Eine Sculptmap mit 256x256 Pixel sollte daher logischerweise 65.536 Vertices besitzen, was unwesentlich mehr ist als die 8 bei einer einfachen Box.^^
(Deshalb sieht man bei den Sculpties oftmals auch diese runden Preloadobjekte, bis die richtige Position der Punkte geladen wurde)

Lichtquellen können ebenfalls eine mögliche Lagursache darstellen. Soweit mir bekannt, können die gängigen Grafikkarten bis zu 4 Lichtquellen zur gleichen Zeit hardwareseitig berechnen. Alle weiteren Lichtquellen müssen aufwendig interpoliert werden oder via software berechnet werden. Auch hier bedeutet dies wieder Lag.

Neben dem Systemseitigen Lag kann es aber auch zu engpässen in Deiner eigenen Leitung kommen, vor allem jetzt zu den Feiertagen, wo jeder Hunz und Kunz im Internet herumschwirrt und seine freie Zeit mal so richtig im www nutzt, kann der Provider oftmals die zugesicherte Bandbreite gar nicht zur Verfügung stellen. Sprich Deine Up-/btw. Downloadrate ist schon mal geringer als sonst. Das läßt sich mit ein paar einfachen Tools spielend feststellen.
Dann kann hinzukommen, hast Du Musik nebenbei laufen, downloads, webseiten oder sonst irgendwelche Streams? Die verengen das Nadelöhr auch nochmal.

Serverseitig kann sich die Frage stellen, eine Sim ist normalerweise ein dedizierter Server auf dem Server (Hardware) selbst. Sprich er teilt sich mit anderen dedizierten Servern die Ressourcen des Rechners. Dabei sollte es eigentlich nicht zu Überschneidungen kommen. Betonung liegt hierbei auf SOLLTE. Wie LL das intern administriert, kann ich nicht sagen, ich vermute aber, das sie eine Art ressourcen sharing belassen haben und Sims ganz bewußt nationalitätenspezifisch in alle Zeitzonen gestreut haben, So das die Haupptlastzeiten rund um den Globus wechseln. Würde soweit auch ganz prima funktionieren, es sei denn auf einem der anderen dedizierten Server (Sims) findet gerade ein 24 Stunden Event statt und nutzt somit die Resourcen aller anderen mit, was dann wiederum zu einem Engpaß führt. Folge daraus ist Lag. Hast Du eine OpenSpace Sim ist dieses Szenario sogar sehr wahrscheinlich. Denn LL empfiehlt ja nicht umsonst "light use". Was auch die derzeitige Diskussion hinfällig macht. Auch wenn die Leute mehr bezahlen und die OS Sims voll nutzen, kommt es trotzdem schnell zu lags auf allen gekoppelten OS Sims des Servers.
Bedeutet letztendlich, Deine Nachbarn brauchen nicht mal schuld sein, wenn irgend ein anderer Trollo im Grid auf einer ganz anderen Sim, die zufällig auch auf Deinem Server gehostet ist meint, er müsste mal sie richtig auf den Boden stampfen, spürst Du die Vibration auch unter Deinem Haus.

Usw. usw. usw. Es gibt viele mögliche Ursachen, Scripte können ein einzelnes Problem daran sein und werden oft verdammt, weil sie als einziges mit Estaterechten "bemessen" werden können, zumindest partiell. Die Leute brauchen halt immer irgendjemanden den sie beschuldigen können, was das Problem nicht löst, aber Plazebo like das Gewissen beruhigt. :)
 
Ein sehr schöner Beitrag von Xaver, der einige Lagursachen kompakt darstellt. Zur u.a. Quote habe ich aber eine Frage. Die Textur wird doch bereits beim Laden auf SL passend gemacht, d.h. auf die Maße 128, 256, 512, 1024, danach liegt die Textur doch "passend" vor, oder versteh ich da was falsch?

Xaver Odell schrieb:
Hinzu kommt das viele "Designer" die empfohlene Skalierung nicht einhalten. Sprich 128x128, 256, 512 oder 1024 Pixel. Wenn man eine Textur mit krummen Werten verwendet, beispielsweise 1000x700 Pixel, dann muss das System die Textur erst einmal umrechnen in eine der Standardgrößen, bevor sie auf einem Prim dargestellt werden kann. Umrechnen = Rechenzeit.
 
Manni Lusch schrieb:
Ein sehr schöner Beitrag von Xaver, der einige Lagursachen kompakt darstellt. Zur u.a. Quote habe ich aber eine Frage. Die Textur wird doch bereits beim Laden auf SL passend gemacht, d.h. auf die Maße 128, 256, 512, 1024, danach liegt die Textur doch "passend" vor, oder versteh ich da was falsch?

Ja, da hast Du Recht. Wenn man ein Prim mit einer Textur in die Laenge zieht, und eingeschaltet hat, dass die Textur mitskaliert wird, ergibt sich ja auch keine neue Ladezeit, sondern das macht die Rendering-Engine auf dem eigenen Rechner (die die Textur ja sowieso dauernd skalieren muss, wenn man mal weiter weg ist, oder schief draufschaut, und das auch im Allgemeinen sehr gut&schnell macht^^).


Cheers,
Torrid
 
also alle texturen die dunkel sind erzeigen lag desto dunkler umso mehr und
wenn sie auf riesenprim sind dann erst recht..........
auch die robotter (Boots) machen einiges lag und die rezzer nicht vergessen :wink:
 
erich Boa schrieb:
also alle texturen die dunkel sind erzeigen lag desto dunkler umso mehr und
wenn sie auf riesenprim sind dann erst recht..........

Das kann ich nicht nachvollziehen.

erich Boa schrieb:
und die rezzer nicht vergessen :wink:
Meinst du sog. Temp-Rezzer? Natürlich erzeugen die Lag, genauso wie viele andre schlechte Ideen und Skripte.

erich Boa schrieb:
auch die robotter (Boots) machen einiges lag
Du meinst Bots, also normale Avatare? Natürlich verbrauchen die Resourcen ("machen Lag" klingt immer so wie 'Vakuum erzeugen'). Am besten wäre es natürlich, es würden sich gar keine Avatare [libary:e11c7ec83b][Spielfigur] in [SecondLife], welche von einem [Spieler] gesteuert wird. In [SecondLife] kann ein [Avatar] jederzeit beliebig sein Aussehen und Geschlecht ändern.[/libary:e11c7ec83b] nach SL [libary:e11c7ec83b]Abkürzung für [Second Life][/libary:e11c7ec83b] einloggen, das wäre dann am lagfreiesten. Aber macht das Sinn?

Bots - als 'lebende Schaufensterpuppen' z.B. sind eine feine Sache, die gut aus sieht. Wenn wir jetzt anfangen, alles zu verteufeln, was gut aussieht, dann dürfen konsequenterweise letztlich nur ein paar ungescriptete Holzklötzchen stehen bleiben.

-> Meiner Meinung nach ist der falsche Ansatz, immer auf Lagverursachung zu schimpfen, wir wollen nun mal SL [libary:e11c7ec83b]Abkürzung für [Second Life][/libary:e11c7ec83b] schön ausstatten, besser wäre es, auf SL-Seite leistungsfähigere Hardware hinzustellen. Dafür wäre ich z.B. bereit, als User Geld auszugeben.

Aber die ganzen Leute, die SL [libary:e11c7ec83b]Abkürzung für [Second Life][/libary:e11c7ec83b] möglichst billig haben wollen und dann über Lag schimpfen, dafür habe ich kein Verständnis.
 
Xaver Odell schrieb:
Dann gibt es aber auch sehr oft Lag durch falsche oder zu große Texturen die verwendet werden. Klamotten oder Skindesigner verwenden oftmals Texturgrößen von mindestens 1024x1024 Pixeln, da kommt dann schon mal ein einfaches Unterhemd mit 150 KByte Download daher...

Die Texturen auf Oberkörper, Augen, Kopf, Unterkörper und Rock haben immer 512x512 und werden vom Viewer gebacken udn als Baked Texture hochgeladen und von der Sim dann an die andern Viewer verteilt.
Ob der Klamottendesigner da eine 1024x1024er oder eine 64x64er Textur für die Hose verwendet ist egal - die Hose hat nacher immer 512x512.

Hinzu kommt das viele "Designer" die empfohlene Skalierung nicht einhalten. Sprich 128x128, 256, 512 oder 1024 Pixel. Wenn man eine Textur mit krummen Werten verwendet, beispielsweise 1000x700 Pixel, dann muss das System die Textur erst einmal umrechnen in eine der Standardgrößen, bevor sie auf einem Prim dargestellt werden kann. Umrechnen = Rechenzeit.

Die Texturen werden beim Hochladen in ein Seitenlänge = 2^x -Format skaliert, wobei Vorzugsweise abgerundet wird.
Aus der 1000x700 Pixel Textur wird also wohl eine 1024x512 Textur, die dann im Viewer als jpeg2000 komprimiert und dann ins Grid hochgeladen wird.
Diese Skalierung ist nicht empfohlen, die ist erzwungen.
Dabei ist es dann nacher mehr oder weniger wurscht, ob die Texture in Teilen oder ganz oder verzerrt auf dem Prim zu sehen ist, das macht beim Rendern nur einen kleinen Unterschied.

Wichtig ist nur die größe der Textur an sich, und eine 1024x1024 Textur ist in den allermeisten Fällen völlig überdimensioniert.
Da sieht man meistens überhaupt keinen Unterschied zu einer 512x512 Textur, die nur 1/4 des Speicherplatzes braucht.

Erst wenn man soweit an das Prim ranzoomt dass man einen ganzen Bildschirm damit füllt merkt man ein bisschen was - udn das auch nur, wenn Anti Aliasing und Anisotropes Filtern usw. aus ist.

(...)
Ein einfacher Würfel hat 8 Punkte. Eine Kugel dagegen vielleicht 256, je nachdem wie LL sie definiert hat. Sculpties je nach größe der SculptMap. Eine Sculptmap mit 256x256 Pixel sollte daher logischerweise 65.536 Vertices besitzen, was unwesentlich mehr ist als die 8 bei einer einfachen Box.

Wichtig sind da nur die sichtbaren Dreiecke, weniger die Anzahl der Punkte an sich, aber das hängt ja alles zusammen.
Die Punkte selbst zu transformieren ist für die Grafikkarte kein großes Dings, das macht die mit Links, das ist simple Matrixrechnung.

Die Textur dann da drauf zu legen usw. ist dann schon mehr rechenarbeit.

Würfel haben so zwischen 2 und 12 sichtbare Dreiecke.
Eine Sculptmap hat in der höchsten Aauflösung maximal 32x32 Pixel, also bis zu 2048 Dreiecke.
Ein Torus hat bis zu 1024 Dreiecke.

So kann es schon Sinnvoll sein eine komplexe Form aus z.B. 100 Tori, Zylindern und Spheres durch z.B. 3 Sculpties zu ersetzen.


Lichtquellen können ebenfalls eine mögliche Lagursache darstellen. Soweit mir bekannt, können die gängigen Grafikkarten bis zu 4 Lichtquellen zur gleichen Zeit hardwareseitig berechnen. Alle weiteren Lichtquellen müssen aufwendig interpoliert werden oder via software berechnet werden. Auch hier bedeutet dies wieder Lag.

SL kann die 6 intensivsten Lichtquellen + Sonne + Umgebung rendern, dabei werden alle weiteren Lichtquellen einfach nicht gerendert. (8 Lichtquellen ist der Mindeststandard von OpenGL 2.0)

Und die 8 Lichtquellen schaffen auch eigentlich alle gängigen Grafikkarten in Hardware.



Serverseitig kann sich die Frage stellen, eine Sim ist normalerweise ein dedizierter Server auf dem Server (Hardware) selbst. Sprich er teilt sich mit anderen dedizierten Servern die Ressourcen des Rechners. Dabei sollte es eigentlich nicht zu Überschneidungen kommen. Betonung liegt hierbei auf SOLLTE.

Pro host sind 2 Dualcore-Prozessoren und 4GB RAM verbaut.
Angebunden ans Grid ist das ganze über Gbit-Ethernet.
Und Pro host werden 4 sims betrieben.
D.h. jede Full Sim hat einen eigenen CPU-Core und im Prinzip 1GB Ram zur Verfügung, auf dem ein spezielles 64-bit debian Linux OS läuft.

Wie LL das intern administriert, kann ich nicht sagen, ich vermute aber, das sie eine Art ressourcen sharing belassen haben und Sims ganz bewußt nationalitätenspezifisch in alle Zeitzonen gestreut haben, So das die Haupptlastzeiten rund um den Globus wechseln. Würde soweit auch ganz prima funktionieren, es sei denn auf einem der anderen dedizierten Server (Sims) findet gerade ein 24 Stunden Event statt und nutzt somit die Resourcen aller anderen mit, was dann wiederum zu einem Engpaß führt. Folge daraus ist Lag.

Eigentlich ist das mehr oder weniger Zufall auf welchem host man nach einem Sim restart landet. D.h. nach jedem Restart bekommt die Sim eine neue Sim-ID und eine neu IP.
 
das mit der lagmacherjagt erinnert mich immer stark an die Hexenjagt

sehr viel halb bis 1/3 wissen ganz wenig echtes wissen lustige empirche erfahrungen die aber nicht falsifizirbar sind. so ala wenn mein festern geschlossen ist (also das in meinem zimmer an der wand so voll oldschool hardwaremäßig) dann habe ich weniger lag weil dann die auserirdichen mein SL nicht beinflussen können.

und wenn man mal was vermeindliches gefunden hat, jetzt sind es die sculpic dann wird das für alles mögliche genommen.

vorher waren es die temprezer
 
Ich habe den Text von Xaver inworld von einem Freund erhalten udn war sehr beeindruckt bis auf einige Passagen...:)


Die Engstelle fürs Lag ist sicher nicht der heimische PC.
Hier kann man dann notfalls was ändern..
bessere Hardware oder weniger Details anzeigen z.B.
btw:
wenn mir einer sagt das Lichtquellen (trueLights) Lag verursachen sollen... dann schalte sie einfach ab in den Einstellungen.

Ich denke vielmehr das der Server (SIM) und das Netzwerk (Internet + Linden Netzwerk) das Lag in den meisten Fällen verursachen.

Was wir tun können ?

Texturen:
Vollkommen klar wenn ich ne 256 x 256 Textur nehme um ne Tür darzustellen ist das längst genug... ich kann natürlich auch ne 1024 x 1024 nehmen... sieht genauso aus, geht auch prima. Aber kostet das 16(!)fache an Ladezeit.
Wichtig ist auch, nicht 100erte ähnlicher Texturen zu verwenden sondern wenige einzelne gezielt zu nutzen wo es möglich ist.
Jede Textur wird nur einmal zum Clienten geschickt und liegt dann dort im cache bereit.

Prims.
Ich bin kein Profi, aber ich gehe davon aus, das jedes Prim als ein Datensatz auf dem Server liegt und auch in dieser Form an den Clienten geschickt wird. Warum ausgerechnet den Server mit Rechenarbeit belasten ??
Dem Server tuts also nicht weh ob das Prim später 12 oder 128 "Dreiecke" anzeigt.
Diese Berechnung, meine ich, wird erst im Clienten ausgeführt.

Achso: Pysikalische Prims sind ne andere Hausnummer... sollte klar sein.

Musik und Videostream belasten ebenfalls NICHT den Server, sondern nur den Computer daheim, sollte also als Lag Quelle vernachlässigt werden können.


Im Übrigen mag ich insbesondere die Leute, die über Lag klagen und gleichzeitig Ketten mit 1000 Prims oder Schuhe mit 600 Prims lieben.

Schön solls sein, keine Frage, aber man kanns auch übertreiben.


scripts:
Seit kurzen hab ich die Möglichkeit als SIM Owner die Scripts zu vergleichen, was sehr interessant sein kann.
ich hab irgendwo gelesen das ein llSensor() sehr laggy wirkt wenn man den zu oft laufen lässt.
Ich hab den jede Sekunde laufen lassen incl Verarbeitung der Avatare (5).
dieses Script hab ich 10 mal kopiert im gleichen Objekt.
Ergebnis: Ein schaukelnde Hängematte bringt nach dieser "Messmethode"
deutlich mehr Lag.

Upps... soviel sollte das garnicht werden... man möge mir verzeihen
 

Users who are viewing this thread

Zurück
Oben Unten