The Lag Myths

I'm too lazy to go looking for it, but didn't Gwyneth post much the same thing to her own blog maybe a year ago?

Oh, screw it. Even I can't be that lazy. Here it is: http://gwynethllewelyn.net/2008/02/16/lag-myths-dispelled/

Anyway, the main focus seems to be on viewer-side lag, and treats sim script lag as mostly solved by the magic of multithreading and scheduler priorities. Indeed, sims are smarter than they used to be, but they also are having some pretty well-known bad behaviors lately in how they handle the coming and going of scripts. There's no mention of script memory usage--a pretty big omission at this juncture.

It's a bit buried in the text, but the piece does address the dynamics of avatars and their textures *arriving* in a sim, as opposed to their steady-state existence in the sim. If one is hosting a big party, lots of people arriving, rezzing everything in sight, and themselves being rezzed by everybody else, means (among other things) that the sim's image download queue will be spiked until the new avatar arrival rate settles.

This is also why changing clothes in a crowd is anti-social.

Plus since script time is a shared resource, it's not much good if the theme of the sim is a dance event and it takes minutes for your menu of dances to pop up just because a bunch of avatars have a radar on scanning every second just to find the names of people they don't know in their immediate vicinity!

(just one example).

For being stated so authoritatively, there was a lot of incorrect and/or misleading information in there. A lot. Also, it omits some common causes of server/client lag.

That kinda links to my next question: who is this person, and where can I check their qualifications?

I think the person is using SL version "in there dreams". This advice will not work:

I don't know about her qualifications, but she's been around for a long time and you can take a look at her blog over at http://gwynethllewelyn.net/

I added a link to the original article to the wiki Lag page:

https://wiki.secondlife.com/wiki/Lag#See_Also
https://wiki.secondlife.com/wiki/Lag#See_Also

Oh come on... you know you want to!



/me tries very hard not to encourage... does it any way.

Object-object occlusion is great. Unfortunately, it won't work up in the sky anymore. The 1.23.4 SL viewer, and third-party viewers using that code, can't handle it. Above about 500 meters or so, the blue water you see in the distance around you snaps in and out of existence like great flapping blue sheets on a clothesline.

http://jira.secondlife.com/browse/VWR-12984

You can turn object-object occlusion off in the Advanced menu, but you really need it when you get back down to earth to keep rez speed manageable, so you have to toggle it back and forth if you move between earth and sky a lot.

This does not appear to be a priority for LL to fix, which is very frustrating.

My second read kinda petered out somewhere around the suggestion the shopkeepers put their signage on the floor, because that's where we're looking most of the time.

We should just dump color and sound and all just have prim balls with smilies on them for avatars.
We should idealy be sticking as much stuff on hard drives as we can, there should be default wall and floor prim/texture sets we can choose to use reducing the amount of stuff we keep downloading everytime we walk into the same building as yesterday and also removing the 100 or so red brick wall textures in the asset server that all look the same.
We could have a few hundred basic prims for floors,10x5x.5 RedBrickWall, 10x10x.3 Timber floorboards, 20x20x.3 Sand, etc perhaps a pure basic box prrim type that just had X Y Z, no hollow, taper, path cut or anything else fancy just a prim type for making 90% of floors and walls.

Yeh, even a basic LL set of textures on the HD that you can switch on if your lagging or have limited download gigs.

If your in a laggy spot those 128 x 128 brick wall textures can be handy.. just put up textured wall so when you land there is less to take in and process..

When you tp over to a new location the sim will build an interest list for you of all objects in your vicinity that it thinks the client should know about. It'll be based on your avie's location, the camera, your draw distance and some ratio between prim size/distance.

The sim starts sending information about any and all objects on your interest list (the viewer does not play an active part in it and can't selectively choose *not* to get told about one object or another, nor does the sim do any actual occlusion culling, if an object is 20m away and completely obscured by another object then the sim will still send object update messages for it). As soon as they rez textures will be fetched - in part based on the amount of space each prim is taking up on the screen - but since rezzing isn't complete the client inevitbly ends up requesting textures it won't initially need.

The reason why you can't see a 0.5x0.5x0.5 prim from 100m, even if you cam over to the spot where it should be, is due to the sim deciding that the viewer doesn't need to know about it and to decrease the number of object update messages the sim needs to send out (ie take 20 christmas lights that change colour twice per second resulting in 40 - partial - update messages or about 40Kb of network data per second per avie who has them on their interest list). An avie selecting a prim that is too small to make your interest list will still get added to it at least temporarily.

The only thing the client does about distance is lower the LOD of prims the further away they are from your camera.

Relatedly, your draw distance might cause you to see (part of) a neighbouring sim in which case you become a "child agent" of that sim (just like the sim you're on that other sim is also maintaining an interest list for you). As a result an exceedingly high draw distance doesn't just end up stressing the sim you're on, but also surrounding sims that you can see (the minimap is a good indication for the most part, if a sim is showing on the minimap you're likely a child agent of that sim).

It's not nearly as bad as actually being on that sim (it doesn't have to simulate physics for you, it doesn't have to run your scripts, etc, etc) but it's still some extra housekeeping the sim has to do.

For things like the hair fair it's never the best solution to have a grid of 4 sims with everyone concentrated around the center of the 4-sim square because most people end up being a child agent of the 3 other sims even if they have a relatively low draw distance of 128m. In addition to dealing with 50 actual avies on the sim it has to deal with 150 child agents and if all 200 are constantly moving around (yes, that's not terribly realistic ) then that's probably around 1,000 update messages per sim just so everyone keeps track of where everyone else is (not entirely sure how many times per second agent movement is updated, but I *think* it's 10 times per second).

They changed something else too about a year ago so now you don't alwqays see neighbouring sims even with a high draw distance the formally surreal landscape horizon now is checkerboarded with missing sims of water.
I don't really see leaps and bounds of improvement in this area, it's like some accountant said "we're going to double the number of sims but halve the number of servers, make it work!"

Combat requires very good framerates and responsiveness. It is common for people to turn down graphics settings to a minimum, ignore clouds, sky and ground etc, usually anything short of going wireframe or removing volume

If someone is running a combat event and want the framerate to not slow too much on the typical graphics card then having an ARC limit will work
If they want their event to be able to be enjoyed by people without the top of the range graphics cards, its their right. They own the land so why do you insult them about it ?

It would be much better if the client had a max ARC you can see from each avatar that you could set in edit-preferences. But unfortionately it doesnt at the moment, so we have to live with the tools we have.

*************

Regarding the script lag myth:
Scripts that actually interact with the world CAN impact the performance of different things depending on what they do.

Examples:
- a script that server side changes textures (such as some product vendors) will be sending updates to the clients which requires bandwidth.
- a script that rezzes objects. This obviously doesn't only cause a slowdown of the scripts program thread but effects all threads involved in objects

technicaly the script does not generate the lag but the effect of the script does it should not slow down the script engine provided there is enough headroom for the general sim resources

Use the right tool for the job. If you want to engage in activities which push your graphics adapter hard, it's probably a good idea to buy a fast graphics adapter. It doesn't have to be top of the line. Those who are unwilling or unable to buy an appropriate graphics adapter are for the most part going to have to accept the limitations of their hardware.

Some sort of ARC limiting function or better control over avatar imposters would certainly help owners of low end graphics adapters. LL seems to have made a half-hearted attempt at that when they changed the "RenderAvatarMaxVisible" debug function to control how many avatars are fully rendered, but it doesn't seem to work properly in the current viewer.

Thank you for trying to provide some clarity on the issue of lag, which is a pain for everyone who ever tried to manage a sim. There will always be a little gray area and debatable points, but I appreciate the effort to debunk the myths and explain why some things about lag no longer apply. Anyone who has regular events on a sim is going to be confronted with this question, and having a good understanding of lag is prerequisite to responding to complaints about it intelligently. This is one situation where perception really is reality, much as I hate that phrase. In a virtual world, it perception is everything.

The people who whined about the length of the text are funny. It's hardly a novel. What are you supposed to do, draw pictures?

Provide a link to the article, not paste it inline in multiple messages.

Alternatively, they could use a more appropriate viewer. Recently I had to use an old (three or four years old, that is) pc when my normal one was being repaired. On discovering I could hardly move using 1.22 (which was then the most up-to-date version) I went over to http://sldev.free.fr/ and installed the "Legacy renderer (recommended for "old" computers with single core CPU and/or "old" graphic cards (e.g. Nvidia 7300 and older))," which is 1.19.05 -- the last pre-Windlight viewer -- with all the patches necessary to run it now. Worked like a charm.. lag cured.

Mischievous

You say that you have been in world for many years, yet your in-world profile shows your rez date as 10th of this month, so who were you? You apologize in that profile for mistakes made in the past, but then litter it with exhortations to people to go away (I'm translating from the Anglo-Saxon here). What happened to your old account? Were you banned?

It seems to me you haven't learned anything.

If we wade through your multiple posts to the end, you inform us in block capitals that you are not the author of this piece. This should have gone at the start of your post. Furthermore, someone who has been in SL for "many years" should know enough to post a link to the original, and credit the author.

If you really had to post this dissertation, you could have removed anything that wasn't strictly relevant - like unnecessary analogies. Or did you in fact bother to read all the way through? Did you just read the first paragraph and decide posting this would cover you in glory and/or up your post count in the forums.

Mmmmm - what delicious cookies!

/me looks guiltily at the empty plate

Um - what is tldr?

Too Long; Didn't Read. Usually written as "tl;dr"

D'OH! Thank you