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.

One Hundred Posts

Seven months ago, almost to the day, I started this blog. All in all, it’s been a great seven months, and a hundred posts that probably won’t change the world, but give me the opportunity to look back over my journey of exploration and growth in Second Life.

My goal in the beginning was to document my exploration of being a non-standard avatar – hence the name xtralarge in the URL. It seemed important to me then to see how people would react to an overweight avi, and I may go back to that, but along the way I gave up on wrestling with the shape tool – trying to make a shape that didn’t have weird triangles sticking out in odd places. Instead I started building a kind of “just a guy” avi.

Anybody who’s spent any time on the grid knows that the vast majority of male avies are overly bulky and blocky. Head proportions seem to be a bit on the small side while arm and shoulder sizes are radically disproportionate. If you’ve ever seen Larry the Lobster on Spongebob, you’ll recognize the archetype. And for some reason, a large number of them seem to think that “shirtless” is the new black. Against that backdrop, I guess I can understand why clothing designers don’t design much for men.

That did raise an interesting question for me, though, and that was “What does a nicely proportioned guy really look like?”

I ran through a series of shape mods based on various artistic traditions and wrote that up, too. But the aesthetic values of the grid aren’t really based on those traditions when it comes to fashion. I suppose that’s no different from RL modeling when you consider what models go through to maintain their artificially slim shapes. The difference is most striking when you realize just how tall models are.

Since then, the majority of my posts have been documenting my experiences as a contestant and model. I’ve taking a lot of photos and started a Flickr account to publish them.

I did get a plum job when the 2009 Clothing Fair opened. I learned that I could get press credentials if I asked, and that those press credentials would allow me a kind of “backstage access” to the show. I didn’t really know anybody there so I kept a low profile and just went to the Fair – documenting what I saw, visiting with the vendors, and writing it up as I went. The resulting series started with a pair of pre-Fair previews followed by a daily report from the floor documenting some aspect of the fair. I have to thank Nevar Lobo who took a chance on an unknown blogger and gave me a press pass. I had a blast writing up the fair, and I hope that it helped raise even a few L$ for the cause.

There have been some other themed posts — in addition to my nightly contest series where I document all the styling contests I entered. Probably the “prettiest” series was the set of articles on the grand re-opening of Caliber, a shop specializing in costume and role play clothing and gear. From Bogies to boggles, the new build there was spectacular and I enjoyed my time creating those photo-stories and meeting some really great people along the way.

And that’s really what it comes down to on the grid. The people. If it weren’t for the people you meet along the way — avatars of reality projected into the virtual world — the metaverse would be a sterile and empty place. I’ve met some great ones in my time in the world and I’m looking forward to meeting more.

Yea, it’s still a brave new grid. And there are still a lot of stories to be discovered and told here. I hope this first hundred is just the beginning and I’m looking forward to the next.

Onward.

RZ

Avatar Draw Cost

This isn’t really about fashion, altho maybe it should be. If you’ve ever been in a group of more than about 10 people, you know that things get a little squirrely and after about 30 or 40 folks, things grind rapidly to a halt. There are reasons for that and while most people blame stuff like bling scripts (undoubtedly true), my rather informal observation is that a more important factor is a rather obscure metric known as “avatar draw cost.”

ARC is a measure of how much of a load any given avatar puts on the SL viewer to render it. You can see that measure under the Advanced menu > Rendering > Info Displays > Avatar Draw Cost (Cntl-Alt-Shift-D to turn on Advanced, if it’s not already). When that function is checked, numbers appear above avatar heads to let you know how much effort it takes for that particular avatar to get shown on the screen. The higher the number, the more load that person puts on the viewer. Lower is better. Good numbers are in green, borderline numbers in yellow, and heavy numbers are in red.

Here’s the thing that makes this relate to fashion.

I understand the desire to look good, but when your avi has a draw cost in excess of 5000, you’re using 10x the resources of a person with only 500. What that basically means is that everybody’s viewer (yours included) is having to work as hard as if it were 10 “normal” people instead of just you. Put five or six folks like this in a view and your viewer thinks this is a big crowd. I’m standing in a shop right now — already laggy because of the numbers of textures in my view — and of the dozen or so avi’s here, more than half have numbers in the red (above 1500) and a couple are over 5000 — one of whom is (Away). The rest are in the yellow. I’m the lowest at 315.

What does that mean?

For all intents and purposes, my viewer is having to load the equivalent of .. I’m making a rough count here .. of about 60 “normal” avatars. I’ve been standing there for 15 minutes and all the vendors haven’t loaded. For that matter most of these people standing here are still gray as well. I am able to move about fairly easily, but it seems counter productive to me to build a good looking avi that people can’t see because it never gets a chance to load.

Things to think about.

Draw cost seems to be most effected by flexi, then by complexity of prim attachments. A single prim doesn’t add a lot. A 100-strand flexi tail does. Hair seems to be the worst offender — because almost everybody has it. Some jewelry, especially those items with over 200 tiny prims, appears to add a lot as well, especially when you get close to the individual wearing it.

When I’m putting together a look, I pick the item that gives the most effect and then build around it with the goal of keeping my share of your viewer cost down. My goal is “under 400” and usually I can make it.

Hair: no flexi. I know that flexi generally looks better, but many short hairs and most women’s updos have only a few strands of flexi giving a softer look without contributing thousands to ARC.

Jewelry: simple is better. The highly detailed, scupltural items can add 300-500 points each. That adds up fast.

Clothing: More and more designers are putting in prim/sculpty attachments to their clothing. Sculpty collars, prim cuffs, belts, etc. Most of these don’t add too much, but when you add in a gown with 100 flexi panels in it — or even a jacket with a half dozen flexi bits in the tails — the cost mounts very fast.

When you’re going out shopping, or to an event where you can logically expect a lot of people, pick an item or two that make a big statement and then fill around it with less costly ones. Got a great hair? Terrific! Choose to wear it with a simple diamond stud earring, a tasteful outfit, and some low-draw shoes. Don’t add the 400 prim neck chain with 60 bling scripts, the flashing Oyster watch, and a flexi-tailed tux.

So as we head into the new year and start thinking about resolutions, maybe think about how to make your avi a little less “fat” by paying attention to avatar draw cost. Your viewer will thank you for it.