Don't click here unless you want to be banned.

LSL Wiki : Lag

HomePage :: PageIndex :: RecentChanges :: RecentlyCommented :: UserSettings :: You are crawl338.us.archive.org

Lag


What is lag, and how can it be reduced? In networking parlance, "lag" (also called "ping" or latency) refers to the delay incurred when sending data from one server to another over a network. In SL, it's commonly used to describe any slowdown experienced, be it low framerate, a delay in movement, or a sim running slowly.

What is server-side lag? | What is client-side lag?
Reducing server-side lag | Reducing client-side lag


Server-Side

Each simulator within SL runs on its own independent CPU. This means that badly written, inefficient scripts can affect other residents in a sim. Lag is not just limited to physical objects, either. Things like listeners and sensors can do more than one might realize. There's often a more efficient--and frequently simpler--way to implement things.

These functions can help monitor a sim's "health":


Client-Side

There are various client-related things that are central to lag: texture and geometry changes must be transmitted from the server to the client, and this information can add up. SL requires a lot of bandwidth as it is. Frequent texture and audio changes can result in a queue for the client that just keeps growing and growing if the client can't download it fast enough.

Once downloaded, the amount of data can slow down the client if the computer it's running on doesn't have a lot of system or video RAM. Low video RAM can also result in textures being dropped, leading to blurry or missing textures on objects and avatars. Rendering speeds can also be affected by having to draw avatars or large numbers of prims, particularly when textured with alpha textures, can also impact rendering speeds, especially on slower computers.

(It is confusing to technical people to call any slowdown at all lag--technically, the "tardiness" of network data, which happens with long distances, busy servers, and having much too little bandwidth) because in SL it will regularly mean it applies only to the reporting person whose settings are taxing their computer.)

So how does one fix slowdown? As someone who is experiencing (rendering) lag, there are two options: either upgrade the computer or tweak your preferences. For the latter, play around with lowering the details in the preferences window (Ctrl+P), or even turn off less necessary rendering via the debug (enable using Ctrl+Alt+D) menu. The preferences are often enough: dropping the draw distance ("Adv. Graphics" tab, and ensure "Disable Far Clip" in the "Graphics" tab is not checked) can help tremendously. "Local Lighting" is also another lag inducer, particularly since SL 1.7, so disabling that can help too.

To make sure one's created objects aren't causing extra rendering lag, avoiding lots of polygons and textures is a good idea, but most people have computers that can keep up these days. It's server-side lag that we can really do something about.

Q: What about llSetTextureAnim? Someone told me to take it down because it was generating lag. Isn't it supposed to be client-side?
A: This person did not know what they were talking about. Unless you are constantly calling llSetTextureAnim from your script, texture animations cause only a single object update. llSetTextureAnim does not affect sim load. It causes only very minor client load. However, it should be noted, animated textures tend to be big which can cause increased loading times and can lower your framerate because more texture data needs to be swapped in and out of texture memory when changing your view.


Lag Reduction Tips: Server-Side



Lag Reduction Tips: Client-Side


Style Guide | Simulator | Server | Client
Comments [Hide comments/form]
Added minor note on use of return statements. I do this often.
-- JeffreyGomez (2005-05-31 20:11:24)
My mistake - this is redundant. Continuing to add additional "tricks."
-- JeffreyGomez (2005-05-31 20:12:45)
Let's try to reduce the amount of unnecessary comments, OK? You could've at least combined your 2 comments into a single comment, Jeff...
-- EepQuirk (2005-06-01 01:38:09)
Question: how is the following tip used: "Also try llKey2Name for passing data between objects. It can be used anywhere in the sim!" I'm not an expert scripter, and the only way I see to "pass data between objects" is a) llShout(); b) sending them emails; c) creative use of llRemoteLoadScriptPin() [clumsy and slow, but it works]; d) XML-RPC. I've heard about crazy people basically shooting invisible "bullets" to carry messages to remote objects (ie. when they collide to the destination, they get attached, thus allowing llMessageLinked() to work again), but frankly, this is way too complex for me.

So, how exactly do we use llKey2Name() to pass data between objects? Sorry if it's pretty obvious :P
-- GwynethLlewelyn (2005-08-31 11:37:48)
I seriously have no idea what they're talking about. Please feel free to remove that.
-- KeknehvPsaltery (2005-08-31 14:54:06)
You can use llKey2Name to pass data between objects in the same sim. One object can repeatedly check for changes in another object's name, by running llKey2Name in a loop or timer. An object can "send" a message by setting its name to the message data.
-- ChristopherOmega (2005-08-31 20:16:34)
Wow, it seems like that should be posted on clever!
-- SchitsoMonkey (2005-09-02 21:06:16)
Not necessarily, back in the days before email, there was no direct way to send data between objects by key. Because chat was limited to a 100 meter sphere around the chatting object, name-messaging was the only way to know that all objects in the sim had access to the data. I guess using this method now would be considered taboo cleverness, but when in the context of SL versions past then the distinction isn't so clear.
-- ChristopherOmega (2005-09-04 18:22:39)
That depends. It still has applications such as passing data to client objects when the server does not know the key of all the clients. A call to llKey2Name() is about 8 times faster than an llShout() (0.004382 seconds versus 0.034599 seconds by my tests of 5x10,000 iterations on the 1.7 preview grid), plus it has greater range. This would be efficient for high latency, periodic updates. Of course for faster communications, the timer involved would destroy the speed benefit.
-- AlondriaLeFay (2005-10-18 06:51:53)
After 2 months, I checked the comments on this post again :) Hmm, very, very clever idea. Of course, I assume that the name is limited in size, so I guess that to pass a large amount of data, it'll be not easy to do. Ah well. Waiting for the inter-object messaging system that was due to be released in 1.7... when 1.7 was due to be released in the end of July ;)

Thanks for the explanations, though. I must admit that this is really a clever workaround!
-- GwynethLlewelyn (2005-10-30 07:14:22)
Attach a comment to this page: