Lag-o-Rama

Last night’s lag-fest prompted me to do a little more research into what causes lag and what, if anything, can be done about it. As I expected, there are a multitude of opinions and some amount of data about lag.

Some Realities

To paraphrase Caesar: All lag is divided into three parts, one of which is comprised of the local client lag, the server lag another, the third, which we call network or transfer lag.

The statistics bar (View > Statistics) will give you good information about all three kinds of lag, but the information is not labeled “lag” so much as it gives you the numbers which describe performance. That performance is usually expressed in frame-rate or frames-per-second (fps) and in general, more is better.

Client/Viewer Lag
Think of a movie. Typical movie films run 32 frames per second through the projector, putting 32 individual still pictures up there in a sequence that's fast enough that your eyes don't see the individual pictures, but see the images on the pictures appear to move. The human eye will translate individual pictures into moving pictures with frame rates as low as 12-15 frames per second.

The same thing happens in your local computer when the viewer translates the digital data that it has into a series of moving pictures on the screen. A good frame rate of 20-30 fps will give your SL view a pretty smooth look. Phosphor refresh rates on the screens has a bit of smoothing effect as well since the images do not change instantly on an electronic display, but rather fade in and out a pixel at a time at rates approaching 60 to 120 frames per second. (Not to bury you in numbers, but note that your computer screen is probably painting each frame in your viewer at least twice before changing to the next frame). If you computer does not have accurate data, or does not have the data it needs when it needs it, or does not have the capacity to keep up with the data that is coming into it, then your view of the world, and your ability to interact with it become choppy and unreliable. In short, lagged.

There's not much you can do about that in the short term except to make your view smaller, more compact, less complex. Let your computer work less. Bring down your draw range. Tilt your camera down so that you have less horizon and fewer objects in the view. There are some other recommendations below on how to reduce the load on your computer. In the long run, if your graphics are constantly being overwhelmed, maybe upgrade your card and/or computer.

Server Lag

There are a lot of servers. Most of the LL servers we have no information or control over but we see them every time we upload a file, buy something from a vendor, or look at a profile. The region servers, those portions of the computing platform that represent the region and parcel an avatar occupies at any given time, we do have some information about, and that information can help inform builders.

The Statistics Bar has regional server information and the key diagnostic there is “Time Dilatation.” Time dilation runs from 0 to 1 with 1 being “real time” or “every second of in-world time takes one second of real world time” and 0 being “stopped.”

Ideally, you want to see that number stay above .98. Anything below .8 is noticeable. A time dilation of .5 means that every in-world second takes 2 real-time seconds. Your avatar might use the walk animation, but move across the landscape very slowly.

A lot of server lag can be controlled through good building practice. Keeping the number of scripts and the number of prims down is one key practice. When addressing the prim issue, it’s important to recognize that the server only dishes up what you can “see” but it also has to dish up everything that anybody can see who is in that region.

A recommended practice where there are a lot of prims and/or a lot of textures is to rely on the aggressive “occlusion” engine that LL has developed. “Occlusion” means “blocked” and what it does is lets the server ignore anything that you shouldn’t be able to see, taking it and any of its textures off the list of things it cares about, reducing the load considerably. You do that by building solid walls.

Shops with open windows are nice, but if you have a lot of them in a small area, then the regional server needs to paint every thing in your line of sight, including the vendor-boxes hanging on the wall of the shop across the street which you can see through the transparent window you’re standing in front of. It’s scenic, but it’s lag inducing. Block those views with solid walls. Not only do you reduce the regional server load by blocking them from view, you reduce transmission lag (see below) by taking them off the list of things that needs to be sent down the pipe.

Scripts are another issue. Active scripts are a big deal. While it’s true that scripts run at a lower priority, that is, only when nothing else is running, it also means that activities that rely on scripts for interaction become very problematic as the server tries to find room in the queue for them to operate. One resource reports that each active script in a region uses up .003ms of the server frame as a minimum. Just a “Hello, Avatar” script in a box will use that much. Each class five server has the potential for 45 server frames per second – giving an updated status to everybody in the region once every 22.222ms. Doing the math, I calculate that something around 7500 scripts will fill the server frame’s time slot. That’s before anything else happens, like trying to walk across the room to see what’s for sale there.

Keeping the number of scripts down is a key to keeping regional activity moving.

Network or Transfer Lag

This is the “I see gray people” or “My hair won’t rez” problem.

Remember the viewer lag? Your viewer paints the scene on your terminal but it can only paint that scene based on the data that it has. If the data doesn’t get transmitted, you can’t see it. You might not even know it doesn’t exist because what gets painted in place looks ok.

This is everything. Shapes, textures, animations, sounds, all of it.

It will stack up and eventually it’ll all come to you, but if you’re relying on reading the vendor sign in order to know what you’re buying? Transmission lag will give you grief by not letting you see what’s in the scene.

Putting It Together

The server has to figure out what everybody is seeing and send that information to each, the network has to deliver all that information to your viewer, and then the viewer has to paint it onto the screen. Ideally, it does this 45 times a second.

If the server can’t process your view in time, then the network doesn’t have it, so your viewer doesn’t get it and you can’t see it.

If the server processes it in time, but your network is unable to handle the volume, then your viewer doesn’t get it and you can’t see it.

If the server processes it in time, and your network delivers it to you, but your client can’t process it in time, then you can’t see it.

Client lag, you can do something about. Reduce the load on your computer by shutting off other applications like Skype, or email. Turn off the audio streams – whether you’re listening to inworld or iTunes, stop that. Every cycle that your machine has to work that is not related to painting the SL scene for you to see is a cycle that might be used better to show you what you need to see.

Network lag, you can do a little bit about, depending on where the problems are. Shut off your network based apps like Tweetdeck, Skype, and AIM. Not only will you save machine cycles for your viewer to use, you’ll free up bandwidth that could be used to show the texture on that skin you’re trying to demo. Turn off your Bittorents, and close browser windows. Check to see if your kids are watching YouTube videos again.

Regional server lag, you can’t do much about except vote with your feet. If the place is LagLand, leave. If you’re a builder/designer, you can do a lot to help make your region or part of the region efficient by keeping the views discretely short, and cutting out the numbers of active scripts.

Some Things You Can Do

The number one cause of lag is avatars. If there aren’t any avatars in your region, then — well, really, you don’t care because there’s nobody there to see or do anything anyway. Without avatars, lag isn’t a meaningful construct. The old ‘if a tree falls in the forest’ idea.

As a visitor, keep your active scripts to a minimum. Any blinger that listens on open chat for “bling on” needs to be inactivated. You can take it off, or you can set the bling state you want (off is good), and then edit it and use Tools > Set Scripts in Selection to Not Running from the menus. The prims represented by that object will still need to be painted on the screen, but that collection of scripts buried in all those prims will be deactivated and removed from the region’s active server load.

Same thing goes for any script you’re wearing really. Resizeable hair? Size it and then turn off the script using the same technique. You don’t need to take the hair off or remove the script. Just turn it off. You can always turn it back on later in the privacy of your own home if you need to change it. Color change shoes or jewelry? Set the colors and turn off the scripts before you leave the house. Some jewelry can have hundreds of prims and if it’s color change and sized? That gets really ugly when you and nine of your friends show up at a party.

Builders? Reduce objects and scripts. If you have a mall or a shop, use the built in ‘set for sale’ capability of the prim. Sell a copy, or the contents without adding a script to the mix. This can add up fast in a mall. If each vendor box has an active script in it, even if there’s nobody there buying anything, every single vendor box takes its .003 ms bite of the frame slice.

Also limit the numbers of different textures (to reduce network lag) and the number of flexible building components like flags and fringes (to reduce client lag).

Finally, flexi and particles (bling) do contribute to lag, but they only contribute to client lag. The actual movement and interpretation of that movement is not something that’s handled by the server, nor is each flip and flap of a flexi skirt transmitted. Instead the description of that object is transmitted and the viewer interprets what and if you see. If your viewer is already overloaded then adding this additional load will hurt your view, but will have no effect whatsoever on anybody else’s view. You can actually shut all particles off so you’re not bothered by them in the Preferences > Graphics section. This is particularly useful for griefer attacks. Turn off the particles in your viewer. No attack exists if you can’t see it.

One last note on client lag and animations. We’ve all seen the ‘dancing fool’ who can’t stop dancing on your screen, but looks perfectly normal on their own. I believe this to be an artifact of transmission lag where the local client accepts the command to stop the animation in question, but the uploaded command gets lost before the avatar server accepts it. This is not a function of the region, altho accumulated laggings would undoubtedly effect it. Repeated attempts to stop dancing are often futile as cached copies of “current anim” are crossed up and repeatedly issuing a munged command doesn’t unmung it. Frequently one can stop that with a “stop all animations” command executed a few times until the cached duplicates can all be purged.

The infamous “model scream” pose – where an avatar’s face is deformed into a wide open mouth is probably a variation on that same problem when one person’s cached version of an avatar view includes the open mouth while others see that avatar perfectly normally using a cache that was kept in sync by a fast enough transmission and update cycle. Often the victim doesn’t know there’s a problem and frequently, even other people are unable to assist because the avatar looks normal to them. The only known solution is for the avatar to log off and back on again, which has the effect of refreshing the outgoing avatar cache so everybody gets a fresh look, one that’s complete – assuming the three lags don’t interfere again.

References

I owe a lot of this to various resources around the web. Thank you all for your work in helping to track down this stuff and make it available:

Chalice Yao’s post on SLUniverse Forums

Gwyneth Llewely’s Anatomy of Lag, Ana Lutetia

Pandora Wrigglesworth’s Lag101, what is lag and why does it happen. Curio Obsura. This is a particularly good explanation of why sculpties possibly reduce lag.

Advertisements

About Roland

I'm just an oversized avatar in a silly virtual world.

Posted on July 29, 2009, in Tech Talk. Bookmark the permalink. 2 Comments.

  1. Xenobia Foxclaw

    Wow! That’s a lot of information to take in, but I understand lag a little better and why color-change shoes are great for models but have lag-price to pay. Thanks for a great post, Roland.

  2. From a “lag production” standpoint.

    You’re better off to wear a single pair of color-change shoes and change the color than you are to make copies in each color you need and re-rez the shoes each time.

    Any prim you don’t need to rez is a *huge* savings in terms of short term lag production and you can turn the color change part while you’re wearing the shoes.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: