(I told you and warned you that you would be here. Consider yourself lucky that it was the avatar and not something we both know it could be far worse)
Anatomy of Lag
June 22, 2009 by Gwyneth Llewelyn (cached page)
The Grid Is Misbehaving — What Shall I do?
It’s a weekend where Hair Fair ’09 is in full force, and builders are happily finishing their work for SL6B. Guess what? Nothing could make Linden Lab more happy than having half the grid down, going through “emergency maintenance”, and dealing with the painfully long list of complains that dozens of thousands of residents are submitting…There is nothing else but to be patient (Linden Lab will finish their work when they can… they’re not exactly asleep ), and in the mean time, what are residents doing in-world in the very crippled grid?
They accuse each other of creating lag.
This is a typical pastime of the Lag & ARC Nazis. When things start to fail, specially in very popular events or highly-crowded areas, it’s far better than to blame everybody else than to deal patiently with the issue. However, you can have fun blaming everybody else, but that won’t fix the problems. Really. Let Linden Lab do their work. Eventually things will get back to normal. Blaming everybody around you for either a super-crowded event or a failing grid will not make it happen faster. You will just get angry and get other people angry. And when we all are furious with each other, we react irrationally, and lose all the fun we have with Second Life® — trust me, that’s the last thing you wish to happen.
The Lag Myths
Let’s set the time clock a few years… six or even seven. Back then, Linden Lab had a handful of servers and the grid had just 16 sims or so. If a dozen people stayed in the same place and just chatted, sitting on the ground, the sims would not only lag, but crash — both your SL client and the sim you were on. People tried to break records — who could join the highest numbers of avatars in the same place and stay online the longest? This was usually measured in minutes, not hours or daysAnd of course a few would have found a trick. If you’d go in with your Linden skin, no attachments, and cleared the sim from all prims, textures, and scripts, it was quite likely they could all stay in-world for longer before the sim crashed.
Why was that so? It takes two to tango — the sim server (what Linden Lab hosts at their side) and your SL client application. Each contribute to render this wonderful virtual world. But each does quite different tasks. Each has also limitations, and that means that when you hit those limits, things start to break apart.
In the past, the sim servers behaved as if they could do just one thing at a time (which is, of course, an oversimplification). They sent each avatar prim data, and, most importantly, textures; they tracked down where on the sim your avatar was; they ran scripts; they handled physics (this does not only mean the cute physical-enabled objects — like vehicles! — but also much simpler things like knowing if your avatar was walking on the ground). The problem was that when one of those things was being overburdened for some reason, the whole sim was laggy, and this influenced all avatars on it. Similarly, your own SL client would first attempt to load all prims and all textures before showing you anything at all — even those tiny nanoprims on an earring that was 200 m away.
No wonder it was a grey world.
On those days, four or more years ago, people had only one way to deal with lag: make avatars as simple as possible; get rid of all attachments; stop scripts in the sim; keep event locations as simple as possible (cubes with blank textures); and hope for the best. The truth is, all these things actually helped. The technology was so little advanced that “keeping it simple” really improved the viewing experience. Even turning off title tags did have an effect on reducing lag!
Second Life in 2009 — Myth, Etiquette, and Anger
Well, things have changed since those days, and they have changed dramatically. Since SL pretty much looks the same — it just looks better, but not different — it’s natural that people wrongly assume that “the old methods of dealing with lag” still apply. They don’t, and they have little relevance to how SL actually works.First and foremost, on the server side, the sims are now doing things in parallel much better, and allocate different priorities to different things. The largest impact has been on scripts. Scripts will only run when nothing else is to be done — this means they run at the lowest possible priority, and the more scripts in the sim, the slower they will run — without affecting texture download or avatar movement whatsoever. This is a crucial change. You might have noticed that sometimes your favourite AO or Dance HUD will respond slowly when you touch its buttons, on a very crowded event. That’s just the way things work now. First and foremost, you’ll get avatar data (their position), shortly followed by their shape, body textures and attachments.
Then you get the sim’s prim data in your neighbourhood (it makes no sense to get you all those nanoprims from someone’s earring half a sim away, if you can’t see them anyway), as well as only the textures you can actually see from your viewpoint. And only then will the sim start to run scripts on your behalf. Having more scripts will not lag the sim: the scripts will only run slower. In fact, sometimes it might look they’re not running at all, since most of the time the sim will be happily sending you textures.
So, turning off your AO, entering “sleep mode” on MystiTool, or detaching everything with a script in it will make no difference at all. Granted, if everybody is wearing a thousand scripted attachments, they will notice that their attachments work very, very slowly, or possibly not at all. But they’re not lagging the sim.
Why do people still worry about how many scripts are running on the sim? Well, you can imagine that a slow-running vendor script is a problem: you pay to it, and have no way to know when your item is going to be delivered: either it happens instantly (on a fast sim!), or it can take minutes (on a very crowded shop). So keeping the number of running and active scripts down is important because they might be running too slowly to work at all — and when you’re dealing with shops and money transactions, this is a problem.
So, although it’s usual that people host mega-parties to launch their shops (or launch a new line of products in an existing shop), this is actually not such a good idea: people will enjoy the party, but they won’t be able to shop on script-enabled vendors. A good alternative is simply to set prims to sell content (without any scripts) because these won’t get lagged; a clever shopping area designer will make sure that the place where the event takes place is not close to any shop (let them be on neighbouring sims) or that all shops in the neighbourhood don’t use script-based vendors. Not because of the lag; but because they might be simply working too slowly.
Nevertheless, technical reasons are not always acceptable to the majority of the SL users. Having in mind that it’s easier to blame others when things don’t work, than try to understand what is happening “under the hood” (because it’s just magic…), an etiquette has slowly evolved over the years.
Sadly, it’s an etiquette based on superstition and magic, and not on scientific facts; in spite of that, breaking the etiquette is simply bad manners.
Suppose you invite a Jewish family to your dinner. They will be seriously offended if you don’t offer them kosher food but insist that sliced ham is perfectly reasonable and healthy to eat; it’s just their prejudice and superstition that makes them believe that pork is “impure” or “unhealthy”. In fact, in Palestine 1000 BC, conserving pork meat was hard, and it spoilt too quickly, compared to other types of meat; so it was perfectly reasonable to create a superstitious rule that told them not to eat pork “because God doesn’t want it”. In fact, it was pretty sound advice — for 1000 BC. In the 21st century, of course, we have refrigerators and vets monitoring the health of pig farms, and sterilised procedures to deal with ham manufacture. Thus, a 3000-year-old superstition (which originally was founded on a real problem!) doesn’t make any sense today, does it?
Well, no. But it’s still not polite to offend other people who believe in silly superstitions. Etiquette, or the notion that to live better in a more friendly society we ought to adopt a polite form of addressing others, and tolerating their quirks and superstitions, tell us that we would be very, very rude if we offered non-kosher food to a Jew. So we don’t. We know it’s silly. Even most of them will know it’s silly, too. But none of us violate the social norms that rule our society.
Similarly, in Second Life, a lot of etiquette rules have popped up, many of which making sense in the remote past, but not any more. Turning AO offs will not reduce lag, but people still believe they do. So, even if that’s a stupid superstition, it doesn’t mean we ought to be rude and offend them. We can be politically correct and accept that their erroneous views on how SL runs truly don’t affect us; we can live without our AOs for a few hours and be seen as polite and respectful and tolerant towards others.
Nevertheless, as time goes by, the myths self-perpetuate, and it’s a pity to see that more and more of our social conduct is based upon superstition than on cold, hard facts. Here are some of them.
Lots of prims create lag, so let’s build open-space!
It’s true that the more prims you got on a place, the more textures your SL client has to download, so that means things will take longer to rezz. Most people got that right, because it’s obviousWhat they fail to understand is that nowadays the SL client uses a very aggressive method to just download what it needs. This is called occlusion — a big object in front of smaller ones will make the ones behind not visible, so it’s pointless to download textures for them. Similarly, you don’t need much detail to view objects further away, so the SL client doesn’t request much information for it either.
On the server side, a similar process also helps. The sim will keep an interest list on behalf of each avatar. This is mostly what is in the immediate neighbourhood of the avatar (other avatars and their attachments, prims, textures). So only these get sent — and it depends on the setting you have for Draw Distance on your SL client. The lower it is, the smaller the interest list. By matching all three approaches — just sending items on the interest list; just requesting objects you can actually see; not requesting much information from objects a long distance away since you won’t see more than a few pixels anyway — this will mean that the amount of content transfer between the SL client and the sim will be much, much reduced.
So what should a good shop designer do? Avoid open space! If someone drops in a sim with a Draw Distance of 256 m, it means that the interest list for that avatar will cover the whole sim (these days, with more and more advanced graphics cards, this setting is often the default — and most people don’t know, or don’t want, to change it). If there is nothing in front of the avatar, it means there will be no occlusion, and thus the SL client will request everything in sight — contributing to a huge spike in content transfer requests, and oh yes, these will lag the sim.
Now imagine 60 or 100 avatars all jumping to a hugely-packed shop at the same time. All those residents will be downloading an insane amount of content, all at the same time. That definitely lags the sim a lot!
A much better strategy is not to build open space shops. Create partitions and rooms — make them big enough to allow for easy movement around (remember the camera!) but also artificially enhance the optimisation mechanisms built in SL to take advantage of occlusion and interest lists. Thus, if none of the “rooms” in your shop is bigger than 64 m — which is large enough — you can tell people to keep their Draw Distance at that level. They will still rezz everything on sight — and when moving to a different room (or cornering a partition) they will start just to download that content, not “everything else”.
Similarly, partitions and rooms allow for avatars not to be in plain sight of each other all the time. A clever approach, if you own the sim, is to have several entry points and disallow direct teleport. That way, you can set the telehub from the Estate Tools to have multiple landing points, and avatars will pop up at different parts of your shop. This will mean that even a very crowded shop will only have a handful or so of avatars in plain sight of each other, and this will allow each SL client only to actually rezz the avatars it needs to display. You might have seen that a few designers use this approach very cleverly, and their shops, although apparently as densely-packed as others, have far less lag. Now you know the trick
Remember that for this to work you cannot use alpha’ed textures. Anything with an alpha in it will prevent occlusion to work — even if the texture looks “solid”. To make double-sure, and assuming you do your own shop’s textures, upload them as 24-bit TGA images. Only 32-bit TGA images can have transparency and alpha settings in them (they need extra information to let the SL rendering engine know which parts of it are translucent or transparent). So, a glassy partition looks classy and fashionable, but it also means that it will not only prevent occlusion from happening, but alpha textures take longer to render than the un-alpha’ed ones. So your partitions will actually make lag worse!
There are also a lot of optical illusions that you can use when planning your shop. Items on display will usually have huge textures — 512×512 at least, but often more — since people will wish to see your wares in good, close-up detail. But the rest of the shop is just “decoration” to make a better shopping experience. It’s not as “important” as the items on display, so why don’t you save prims and textures on decoration? The part that people will see most of the time is the ground — so make sure that you can get the best possible texture on it. Walls might simply get less detail, and a very good texturiser will be able to get away with 64×64 textures on walls without making them look weird. Also, use few textures. If you take a look at some of the best designs in SL — mostly by RL architects or interior designers — you will see that their builds will have a lot of prims, but actually just a handful of textures. They will play with subtle tricks of texture alignment and tinting to give the illusion that they have used more textures on the build — but it’s just illusion. That’s why their builds, even if usually far more complex than the average shop, will rezz so quickly.
A lot of problems exist that are typical of SL. For instance, imagine that you have your open space are partitioned correctly with panels — but you have items covering all the walls, from the bottom to the top. What will avatars do? They fly. And once they start flying, they will have a clear line of sight over the panels and partitions — there go all advantages of occlusion! So should you prevent people from flying in your shop? Definitely not — flying is a key element in SL, and you should adapt to it, not prevent residents from using it. So, a good shop should make things easy to find without requiring avatars to fly.
That will also mean better signage. Most amateur shop builders will use a lot of signage, usually on the walls or suspended from the ceiling, so that they don’t cover the items for sale. Well, remember what I told you that most of the time people will be looking at the floor? (It has to do with the way the standard camera works: most avatars are seen slightly from the top) So the signage, unlike RL shops, should be on the floor, not on walls or ceilings! A further advantage of placing things on the ground is that there seldom is anything behind the floor (which means that once the floor is rezzed, the SL client has nothing further to download from that direction, and finishes much faster), unless, of course, you have a multi-floored build. Nevertheless, the best shops have been placing information on the ground and colour-coding areas to make them easier to navigate.
Avatar Rendering Cost Shows That Hair is Prohibitively Laggy!
Since Linden Lab introduced Avatar Rendering Cost as an option on the Debug menu, people have been shocked at how terrible hair is! This has lead hair designers to despair — the better hair looks, the more likely it’s going to clash with the ARC Nazis, who are always eager to shout angrily “Remove your hair now! You’re lagging the sim!” So this means that as a hair designer you have a difficult trade-off to deal with: either please your customers but displease the ARC Nazis, meaning that common residents will avoid gorgeous designs (or just use it privately at home) because they fear they’ll be lagging the sim…Nothing could be further from the truth. In fact, prim hair usually uses just one or two textures at most, and it often uses the most simplest of prims, because they’re the ones that can get flexified (when flexible sculpties become a standard feature of the Linden viewer, as they already are on some viewers, there will be a new Hair Renaissance!). They still get a very high rating on ARC, because, of course, “lots of prims” will always get a higher rating, specially if they have a lot of alpha textures on each prim’s face (which will be the case for most of the very primmy hair).
But… high ARC does not create sim lag! Seriously! A prim is just a prim, 200 prims on the ground or attached to an avatar’s head take exactly the same time to rezz (actually, prim hair will rezz first, since all attachments have priority when downloading). So what’s the problem with high-ARC prim hair (or shoes)?
To understand this, you will need to know that there is sim lag, and there is client lag. Sim lag happens on SL’s grid and affects everybody on the same sim. Client lag is what you experience on your own computer.
Typical cases of client lag are… an underpowered laptop on wi-fi. Sure, it’s fun to be chatting with your beloved one in bed, but your poor laptop on wi-fi will simply be much more laggier than a desktop computer of half the price with a wired connection to the Internet. There is little you can do about that — it’s just the way technology works. Wireless and wi-fi are bad for SL — they lose packets, and when that happens, information has to be retransmitted.
Laptops overheat quickly and easily, and that means that the laptop has to start slowing things down — CPU and graphics card are the first to go, and these two are what you need for ultrafast performance in SL!
The next most common mistake is an unconfigured computer. Although these days almost everybody in the Western world owns and uses a computer daily, they’re still viewed as an appliance — like your toaster in the kitchen — that you just plug in and it works. Sadly, they’re not even close to that, even if every year they get better at predicting what kind of use you’re going to give it. Here goes a typical example. Some of the most recent Vista-based, low-end laptops have a setting to run the CPU at half speed. Why? Vista is more demanding in CPU, and this meant more power consumption, and a battery that runs out quicker. This meant that the computer manufacturers felt that their products would be evaluated against other, non-Vista computers, and people wouldn’t want such short battery life. Thus, they just switch the CPU down to half the performance, and that will make the battery last longer. It will also mean that Vista will be far slower, but since people are used to slow computers anyway, it wouldn’t make any difference at all.
How each manufacturer deals with this is different, but the point is, by just clicking a checkbox or a slider you can suddenly get twice the performance out of your laptop! There goes your SL lag away… But tweaking and experimenting takes time, requires knowledge, and patience. And usually requires an expert too!
Not all of us are experts, so SL tries to estimate what are the best performance settings for your brand and model of computer. It often guesses wrong. I always tell people to experiment with the settings under Preferences to see if they get a bit more performance out of their computers; sometimes, a trick that makes a huge difference for someone will do nothing for you — and inversely, something that everybody else tells you never to touch will make all the difference! I have a very underpowered MacBook from late 2007, and I was very disappointed with it: it has an Intel card that is not supported by Linden Lab. So I wasn’t much surprised that I just got 1-3 FPS out of it, which pretty much frustrated me.
But one day I gave it a try again, and started tweaking with the parameters. By placing all settings at the lowest setting, suddenly I got it going at 40 FPS! Granted, SL didn’t look nice, but clearly that old, unsupported Intel card was not that bad! After playing a bit with the settings I found out that the only serious limitation was with the shaders (used by Windlight to get you gorgeous sky and water). Well, I could live without water reflections — so long as I got the avatars rendering nicely, with plenty of shiny, and good enough detail on the objects. So, getting rid of water reflections turned a “useless” laptop in a quite performing machine! On a good day, I can easily get 30 FPS out of it, and SL doesn’t look that ugly, either!
So is all client-side lag caused by improper configuration? In most of the cases, yes, but the truth is, some features in SL are really meant for high-end graphics cards. If all you can afford is a US$700 laptop or a US$500 desktop, you will get a “bare bones” graphics card — good for Word and a web browser, but not for much more. You can’t expect a low-end, US$10-50 graphics card, which is what comes with the low-end computers, to be able to render things like state-of-the-art graphics cards that will cost more than your laptop!
Sadly, most people simply cannot afford a state-of-the-art graphics card, and will have to make do with what they have. I’m afraid that what this means is that you’ll always be experiencing some sort of client-side lag. Even if people around you run naked, without script attachments, and paint all walls white… you’ll always lag on a sim with 50-100 avatars on it. Your graphics card is simply not powerful enough to deal with that.
Now you know that all ARC Nazis, by definition, have low-end graphic cards I can only pity them for that, because they have a perception of the world that is just unique to them, and they yell and get angry with everybody else because they believe that the whole world is conspiring against them to make their computers more laggy. I’m sorry — but, again, this is just superstition, just a magical belief that you can transform your underpowered computer into something powerful, if only everybody else used Linden avatars.
ARC Nazis will always put the blame on someone else. If they manage to get everybody in a place turning into Ruth, and they are still lagging, they will immediately suspect that everybody is secretly running scripted attachments. So they immediately yell to people to drop their attachments, and visually confirm if someone hasn’t done so. When they’re satisfied, they will still lag… and then remember that people also have HUDs. HUDs, unfortunately, you cannot see — so the ARC Nazis, living in their RuthWorld, will still believe people are hiding their HUDs behind their screens just to create lag.
But wait — you’re thinking — I’ve actually made some measurements, and high-ARC avatars, specially a lot of them, really make my computer run slower!
To understand why this is the case, you have to forget about prims for a moment. Graphics cards know little about prims or even avatars — all they know is about polygons (or triangles, depending on the model). You can see how Second Life looks like from the perspective of your graphics card by going to the Advanced menu and looking for the “Wireframe” mode. SL will look funny that way, but you’ll see that everything is actually really made out of small triangles, all the way.
Now you’ll notice one thing: the more complex the prim (i.e. the more it’s twisted!), the more triangles it has. Avatars have a lot of triangles on their own (about 7500 at my last count). A plywood cube will just have 12.
As you can imagine, your graphics card can only render a specific amount of triangles per second. How many? That depends on the brand and model, but you can expect that higher-end cards can actually render thousand times as much as lower-end cards. Now, SL is optimised to try to feed you a stream of 25 or so frames per second (enough to give you the illusion of smooth movement). This means that in a single second, all those triangles you see in a scene in front of you — hundreds of thousands, often millions have to be rendered at least 25 times.
It’s hard to get a list comparing graphics cards — most use “synthetic tests” where the overall performance is measured using a combination of techniques, not just merely polygon rendering — but you can imagine what happens on a low-end graphics card. At some point, there are so many avatars in the same scene that the graphics card cannot simply keep up with the polygons. As a result, the frame rate drops — you get that “slideshow effect” instead of smooth, video-like motion. This is just your graphics card telling you that it has reached its limit. High-end graphics cards will have a way higher limit, and, for them, rendering hundred avatars with 10,000 ARC doesn’t make them sweat. The problem is, most of us don’t have such high-end graphics cards. So what actually happens is that most will experience a huge drop in performance when rendering too many avatars with too many attachments.
The important thing to remember is that this affects you only. You can tweak your Preferences so that avatars render with less polygons (yes, they will be ugly). You can be on a crowded sim with a hundred avatars with 25-30 FPS on a low-end graphics card (I do that every day!). But it means you have to deal with trade-offs. Typical trade-offs are using avatar impostors even at close range (avatar impostors are just a texture, they have no meshes, and thus, no polygons to render); having a very short drawing distance (keeping those avatars out of your field of vision!); turning off all shaders (bye-bye water reflections and gorgeous skies!); and so on. So… this is actually the reverse of what the ARC Nazis want: instead of lowering your settings so that you can get a good performance of your card (but probably an uglier SL!), they demand that everybody looks ugly in SL so that they can get better performance! But that’s thinking upside down: you should be the one to adapt your computer to what it can actually deliver, not the rest of the world that has to conform to your under-powered or misconfigured computer!
It’s pitiful when you look everywhere for sources of lag that don’t really exist — except on your computer. You can search and search, yell and yell, but the lag in your own computer will not go away. Unless, of course, if you kick everybody out of the sim.
Why?
Time dilation
There is, however, one thing that will definitely lag everybody on the sim. And the answer is actually paradoxically simple: more avatars will lag everybody, but not for the reason described above!Keep in mind that your goal is to render all those polygons 25 times per second to get smooth performance. Now, to keep with that goal, the sim will need to feed you with data, at least also 25 times per second. But — here’s the catch! — it has not only to tell you where everybody else is in the sim (and what they’re doing, e.g. what they’re saying in chat, what animations their AOs have activated, etc.), but it has also to send you the textures for your SL client to render content.
So if you push up the View Statistics window, you’ll see there is a section called “Simulator”. Under that section there is a subsection called “Time”. This will tell you what the sim is actually trying to do to keep up with all the requests.
For historical reasons, the sim will try to refresh everything in it 45 times per second (not merely 25), which gives it some headroom. This means that each “sim frame” is sent every 22 ms (milliseconds). Ideally, the largest value should be on “Spare Time” – meaning mostly that the sim has plenty of time left to do whatever it needs to be doing. Net time is related to texture download (and other assets) from other sims; Agent Time is for sending data about prims to avatars; and Images Time will tell the amount spent in actually transmitting textures to avatars logged on that sim – so, if anyone in the sim is downloading things, a slice of those 22 ms will be “wasted” on downloads and not on, say, tracking where avatars are (Sim Time – Other). The example on the picture shows a very healthy sim: half a milisecond is spent every frame to track avatars down, deal with textures, and so on. But most of the time, the sim is just idling away. This means — zero lag on the sim.
What happens when suddenly a lot more avatars start entering the sim? Well, first, more time is spent to track them down, and this grows exponentially. That means that to track down 10 avatars, you have to send a hundred times more messages! Tracking a hundred avatars means ten thousand times more messages. If we wished to have a thousand avatars per sim, that would mean a million messages exchanged to keep all avatars in sync — but there is no technology sufficiently fast these days to handle that and still be able to deal with calculating each frame, 45 times per second.
But things get worse very quickly. Sim Time – Other (tracking down avatars) is actually one of the quickest things to do, in the sense that it doesn’t require much time to send updates. Texture data is another story, because a full texture requires several seconds (thousands of “frames”) to download, and while the texture is being transmitted, the sim momentaneously fails to track down where avatars actually are and what they’re doing (from your point of view, this is not very serious, because the SL client interpolates — it tries to figure out where other avatars were the last time, where they were moving to, and what animations they had loaded, so it can pretty much give you a reasonable display of what is happening until they get fresher data).
But now imagine that a hundred avatars are all requesting texture data (because they’ve just arrived to a huge event at the same time). Suddenly, all the sim is doing is sending textures everywhere. But in most cases, the textures might not be loaded on the current sim (imagine all those attachments and clothes that came from other sims!), so first the sim has to request them all — wasting time and bandwidth. At this point, the sim might simply begin to fail tracking down avatars. These will request new position updates, all at the same time, but the sim might simply not be able to send them all the required data in less than 22 ms. So here is where strange things start to happen: your avatar starts to “walk through treacle” or suddenly hiccuping and appearing a bit ahead or below of what you expected. This is just because the SL client is expecting some data that it never receives.
In the mean time, the sim starts to receive some texture data. Since all hundred avatars require the same textures, now comes the moment where one texture received from a remote server suddenly turns into hundred uploads to as many avatars. So if texture retrieval from a remote sim was already painful, now it’s a hundred times worse.
But it doesn’t stop here. Once you’re missing a lot of positioning information, you cannot feed the physical engine with accurate information on where the avatars are. Like the SL client, the physical engine can work on guesstimates — “well, this avatar was moving northwards a second ago, so it’s safe to assume it’s still going that way”. Sadly, you never know what’s in the path. Other avatars might become obstacles; the path might suddenly end; there is a stair in front of the avatar and so the physical engine has to calculate the new position based on where the “ground” now is.
When the amount of computation by the physical engine is too high, and it cannot deliver an accurate prediction on where the avatars are supposed to be, we enter “slow motion mode”. What you will see is that the value of Time Dilation, which is usually 1.0 (that means: events happen in real time) might suddenly drop. A drop to 0.5 means that the physical engine is now operating at half the speed of real time, i.e. that all actions that avatars start taking twice as long. A very overburdened sim will quickly get worse and worse — when Time Dilation is at 0.10, that means that everything happens ten times as slower, and so on.
What does this slowdown mean? Well, the SL client can compensate for the lag (what literally lag means: things are not happening in real time any more) to a degree. It doesn’t need to update the avatar position so often, for instance, because the sim tells the SL client that it can’t keep up anyway. You’ll see that for relatively high Time Dilation values (until 0.7 or so) you might not even notice the lag: sim and SL client work in tandem to compensate for the lack of available processing power on the sim side. Usually, this should not happen often: it’s designed to deal with “spikes” (when all of a sudden a lot of people drop in the sim, but quickly disperse, each going their own way).
The trouble starts with a very intense and long event (say, an hour or so) where avatars are constantly in pretty much the same spot — which is what actually happens at almost all events That’s why they lag all the time. The sim cannot keep up with so much information to transmit to all avatars; the physics engine is constantly working to keep up with the amount of information it needs to calculate everything, and never “catches” up. The event is usually laggy from the begin to the end. At the very end, as avatars start to leave, the physics engine finally catches up, the sim finally can track back all avatar positions, and at last, “slow motion” becomes real time again, sometimes all of a sudden.
So how can you prevent this? The short answer is, you cannot. You can’t tell people to stay away from events — which is the only thing that actually creates sim-server lag. The mere act of connecting to a crammed-full sim creates lag. The amount of prims on your 10,000-ARC hair is pretty much irrelevant. Just the tracking down, the physics engine, and the few textures that it’s constantly downloading from other locations and feeding to all avatars in the sim, is more than enough to bring it to its knees. What the Lag & ARC Nazis do not realise is that all this happens independently on what you’re wearing or attaching to yourself.
But doesn’t it help? After all, if you’re not wearing 200-prim-hair, you will have less information to transmit, right? So it will surely help a bit? The short answer is no — the difference is almost impossible to measure. As said, 200-prim hair is usually just two or three textures to download. If your SL client doesn’t ever get them, that’s all right, they’ll just remain grey, but that doesn’t “lag” you. Remember that a sim with Time Dilation of 0.5 is two times slower than real time — and 0.10 is ten times slower. If the overall difference of having everybody wearing 200-prim-hair is 0.01 on time dilation (probably it will be far less), that is hardly important. The sim will not recover from lag even if everybody detach their hair, shoes, and HUDs. Avatars will still be requesting data; the physics engine will still be having a hard time to calculate where avatars are. No, the only way to deal with a sim crammed full of avatars — is to get rid of them. But that’s not an option!
The conclusion?
Etiquette dictates that you ought to conform to other people’s rules when you’re a visitor, and should accept their insane superstitions, just out of politeness, even if they don’t make any rational sense. If the Lag & ARC Nazis request that you detach your things, out of politeness, you should do so. But you should also be aware, if you’re hosting your event, that it makes people angry to impose superstitions on your guests. Blaming your guests for completely the wrong reasons is as rude as ignoring your host’s requests — in fact, I would even claim that some cultures view it as much ruder. As in the example earlier, it would be far more rude for the host to offer not-kosher food to Jewish guests (and insulting them for their superstitions) or blaming them for having to be forced to serve something you dislike just because they have a silly religious rule.In almost all cultures in the world, hospitality is important, and a part of being hospitable is to be nice and welcoming to your guests, and accepting their differences and ideas. Also, in almost all cultures, guests also try to comply with their host’s reasonable demands, if their motivation is a good one. My grandfather, who was a Jew, would not engage in drama if someone would offer him a ham sandwich; he’d just smile, eat a bit not to offend the guest, and later explain that unfortunately his religion forbade him to fully enjoy the sandwich, but still thank the host for the effort in doing a nice sandwich just for him. A polite host would offer their apologies to my grandfather and remember not to use pork ham but stick to chicken ham on sandwiches next time.
Similarly, a polite host in SL would probably request guests not to use high-prim attachments and turn off their HUDs because they believe in the myth that these create lag. Insulting and yelling at your guests is very rude — specially well-informed guests that would kindly point out that this lag myth has no grounds whatsoever. On the other hand, specifically ignoring your host’s request, and wearing the highest-ARC hair you can find, attaching a thousand flexiprims on your scripted skirt, using all kinds of particle effects and sounds on your shoes and bracelets, just to provoke them, is also very, very rude.
A good compromise can be met: there are less primmy hairs around which still look good enough; you don’t need to wear earrings if you have a very dense hairstyle (nobody will notice them anyway); and wearing jeans instead of a high-prim skirt is sexy and fashionable too, and a lot of prim shoes just have one sculpty and still look great! You can also turn off your avatar radar on a very crowded place, since it won’t work properly anyway (as explained, scripts will run so slow that the sensors used by the avatar radars will never really find all avatars around you).
What we call “lag” is basically split among two categories: server-side lag, which you can’t avoid in crowded areas, since it comes simply from having a lot of avatars in the same place, which require a lot of time to compute their positions and what they’re doing. Attachments will have little relevance to lower lag. The other category is client-side lag, and that one can be dealt with — both by the event hoster, who can design the environment to take advantage of the so many tricks that the SL client does to keep a good performance, but also by the visitor, who, even with an underpowered graphics card, is always able to tweak their settings to adapt to an avatar-intense event. Sure, that requires that you experiment a bit with the settings, but it’s within your power to effectively turn down your client-side lag if you’re willing to do some tweaking — instead of blaming others!
What will definitely not work is to stick to superstitions and myths, assuming that things work by “magic”, and being rude to your visitors who are better informed and are not willing to get insulted.
...got it bitches ?
