Thursday, September 5, 2013

Resident Resource - "Lag! Every script counts"

This tutorial is available at: Resident Resource - "Lag! Every script counts".


The story behind this class


If you don't want to read my rambling, click here to jump to the class content. However, if you want to learn the full picture and understand why almost all the material from that class is nowadays outdated, but still, I've taken the effort of working to publish it... Keep reading :-)

During Autumn 2010, I witnessed often arguments in group chats about scripts causing/not causing lag. I remember 2010 as a year when resizer scripts in no modify objects replicated like mushrooms in a forest. The scripting function llSetLinkPrimitiveParamsFast did exist then, but it wasn't widely used (First time I taught it was October 2010, and many of the students were astonished about the ability of controlling a whole object with a single script. Loyal to my taking things seriously, I titled those classes "One script... To rule them all!")

Instead of using this (powerful) function, these resizers used one script per child prim. That meant, a hair having 200 prims, would also have 200 scripts (actually, 201, since there was a separate main controller). That of course, if creators didn't add texture changers to the mix, in which case, the number of scripts could easily duplicate. I have seen hair with more than 500 scripts. That's more than a quarter of the total scripts I currently have in the store sim. I sell scripts and scripted items, so you have a basis for comparison (right now I'm still below 1800 - full region).

The arguments, then, were between a few people that dared saying "scripts cause lag", and a loud majority that refused to be held accountable by the server lag issues due to script usage, which used to scream "that's your opinion" to the people that tried to explain the facts.

From all the fallacies one can use in an argument (thanks for that link, Pynsent!), "that's your opinion" as a synonym of "lalalala, I can't hear the facts you're presenting me", is one I have little patience with. However, my experience was telling me that I shouldn't waste my energies arguing in group chats. It was very clear that my technical reasons would be dismissed too with a quick "that's your opinion".

What to do, if I wanted to bring some sense about the matter?

Wasn't I teaching? Then that's what I would do! Instead of wasting my energies in arguments that would lead to nowhere, I decided I would prepare a class about the topic. I would explain the facts and answer the questions, in hopes that, the more people with knowledge about the subject, the more people would be prepared not only to help reducing server lag, but also explaining to many others that I could never reach, why and how to do the same.

Looking back, I'm glad I took that decision. Things sure have changed since. Some things could be done better, but we aren't as bad as we were back in 2010 and 2011, script-wise. I'm also glad I endured with all the insults, threats and verbal abuse coming from many students because of another decision I took.

My classes wouldn't start until everybody was using 20 or less scripts. Some "slaves" preferred to miss the classes rather than detaching their collar and accused me of taking from their lives a chance to learn. Others accused me of creating a prejudice against people using many scripts and sworn that I would pay for making them be now a "ghetto". Of course, the word "nazi" was used too, and often. Since I was the teacher, I couldn't use the "mute" button lightly. I had to learn to ignore all those awful people while keeping peace at class (for they also annoyed the hell out of the rest of students and I couldn't tolerate that).

Following my example, other instructors joined, and began to demand from people to take scripts off, using the meters I distributed to everybody that wanted them. It's good to see that nowadays many viewers have included this script count as a function on the right-click menu :-)

Linden Lab have also worked on their side, so some issues I mentioned in that class, aren't a problem anymore. This, and the fact that people are nowadays more conscious about the relevance of scripts in adding to server lag, made me wonder for a long time if I should rewrite this material, updating it to the current "state of the art". Truth being said, nowadays, server lag because of an excess of scripts isn't as much of a big deal as it used to be.

So I've decided to leave here the class text as it was, as a testament of the situation back then, and because some concepts are still valid, and people may pick valuable suggestions from them.

If you are a creator, you should anyway check this other link, which corresponds to another class I used to teach about the subject. With creators in mind, that class covered several important concepts that will help you reducing the total of scripts in your objects for sale. Please don't skip it, and my thank you if you use any of the tips I explain there :-)

The rambling finishes here. The (slightly polished) class text follows. My apologies to all the technical people if some things you read aren't completely accurate. My purpose with that class was to reach everybody, whether they had technical knowledge or not, so I had to do some concessions for the sake of making the point clear.


LAG! EVERY SCRIPT COUNTS

Welcome everybody. I am Auryn Beorn and I'll be your instructor for this class.

"Please, detach any scripted item you may be wearing..."

How many times have you listened that in class? How many times have you been asked for your Animation Override (AO), hair or shoes to be removed? Are you really conscious of the effects that a heavily scripted avatar has on the sim performance? Are you concerned and want to collaborate, whether you're a creator or not?

This class attempts to be informative and also formative: know what's the deal with lag, know how you contribute to it, and also learn how to make yourself the most script-clean possible without needing to look ugly or walking like a duck. It's really possible: I'll show you how you can collaborate, because every script counts.

Lag: What do we mean with that word?


Lag is the common word used to name a slow reaction time when we're using an online application, like Second Life, World of Warcraft... you sure can think of more examples :-)

The fact of existing a slow reaction time means that "something's happening", either at client side, or at server side.

"Client side? Do you mean that sometimes, what's lagging me, it's only lagging me?"

Yes, exactly that. So before start blaming the Linden and the unfairness of life (which might be relaxing, but sometimes is shooting to an innocent target... and it is, in itself, unfair), how about learning some bits of how Second Life works, what could affect from our side, and what affects from their side?

A brief on the Second Life architecture


For everybody having an idea of how Second Life works, we're not going into many technical details (these notes have links for further reference at the end), so let's simplify saying that, for Second Life working, we have:

  • Tasks that are dealt with in the server
  • Tasks that are dealt with in the client (our machine running the viewer)

Of course, "the server" is not an isolated machine, but a complete network. Some machines are devoted to work with the database (the assets server), some, with the information from users, others run the simulators themselves. These last ones are our interest here, now.

Each simulator runs one 256x256 meter region: a complete sim. There are usually 4 sims running per server, which means, for the current estimation of (about) 31000 existent sims, a total of (about) 8000 servers running.

I'm well aware that the numbers aren't like that. A server may hold more homestead sims than full regions. But the class gives a lot of data, and I didn't want to make people even more dizzy running into details that make no difference to get the point across.

Among other tasks, each simulator handles the following:

  • Object state
  • Land parcel state
  • Performs visibility calculations on objects and land, and transmits this data to the client (us)
  • It also transmits the image data
  • Handles the physics simulation with the Havok physics library
  • Processes chat
  • Detects the collisions (if an avatar hits a non phantom prim, should not pass through it)
  • Keeps track of where everything is (objects, avatars...)
  • Sends the updates to the clients only when needed

While the clients:

  • Handle the locations of objects
  • Get the information sent by the server regarding to velocity and other physical data, performing simple physics to keep track of what's moving where
  • Get other important data and render the effects

Client side lag: It affects only to you

Which reasons might lag only us, but not the rest of the people on the sim?

Our computer, and our Internet connection.

If our Internet connection is slow, then everything will rez slowly. Since it sounds as a logic thing, whenever you experience slow rez, check that your connection is ok before looking for further reasons :-)

The wiki provides us the following resource for doing several checks: http://wiki.secondlife.com/wiki/I_have_a_lot_of_lag._How_can_I_improve_performance.

2013 note. The link above now redirects to a knowledge base page, and the "Network" section is empty. You can still check what the linked page was like in archive.org, here. Also, the whole knowledge base page is a recommended read.

Then, the higher our graphic settings are, the more our computer (and specially the graphics card) will have to work.

Something that we should never equate is, slow performance of our machine because of the requirements of some graphical effects, to server side lag. This may lead to spreading prejudices like the long time running prejudice against flexis and ARC (Avatar Rendering Cost). Sure, if your computer isn't powerful enough, displaying flexis will make it cough, but in the side of the server, the server doesn't care if your prims are flexi or not. It simply sends the data to your viewer. It's the viewer the one rendering the flexis and their motion. If your viewer can't deal with all the flexis around, it's a problem on your computer: not powerful enough. High ARC, in server terms is not a problem for lag. It's a problem if your computer is an old one. Lower your graphical settings. You will lose detail, but at least, you'll be able of being inworld without that client-side lag.

2013 note: Nowadays you can also use the "Derender" (temporarily) function that some viewers have, and completely avoid them if needed. There are many options to help you if you have a slow machine. Study them :-)

Other effects are also rendered in the client, so it's pointless blaming them as the cause for server-side lag: particles, texture animations, target omegas (for non physical prims), avatar animations. The server simply sends the data. The client deals with the data, and renders.

What might cause then server side lag?


Anything that makes the server "too busy" as for slowing down the simulator frame rate, so there's no data loss for what's happening on the sim.

Like what?

  • Many physical objects in the region.
  • More users. Yes, the mere presence of avatars causes server side lag: the server needs to send the data for each one of them, so they can render the world in their viewer. More avatars, more data for the server to send: the server is busier.
  • Lots of changing textures (because the textures need to be sent to all the avatars in the draw distance each time they change).
  • Many 1024x1024 textures.
  • Many scripts running in the region.

There are several causes listed, but this class, for some reason, has made the scripts the main target.

Before going into "why this persecution mania against scripts" (it's not really like that, I'm sorry if some see it that way), I don't want to leave another detail without mention.

Among others, we've said that a simulator:

  • Performs visibility calculations on objects and land, and transmits this data to the client (us)
  • Sends the updates to the clients only when needed

Now, let me ask you all an innocent question. What value do you have set for your drawing distance?

2013 note: This question always caught people by surprise. Very few had 96 meters or less, almost everybody was between 128 and 256, and some were even in 512. Almost nobody knew why this could be a problem.

Do you know what that means?

That you're forcing the sim sending you the data from objects at that distance. Even if they're so far, that you can't see them. Plus, the updates, when needed (a box has moved? the sever sends the data again).

Do we really need to have such high numbers?

A drawing distance of 64 is good enough for many uses. If you lower it even more, before coming to class (or going elsewhere), you'll rez faster, as the server won't need to send you that much data... some of it, totally useless for your current point of view.

Take into account that when you double the drawing distance, you're telling the server that you want the data for a volume eight times bigger. Eight? How come, if we just are doubling the distance? Because we're moving in a 3D space. The drawing distance is not for a line, but for a whole volume. If you duplicate the drawing distance, you need the data from a 2x2x2 bigger volume to be sent.

2013 note: Actually a sphere, since we're talking about distance, so a bit less of eight, but then again, I had to sacrifice accuracy to get the point straight at class.

Reducing the drawing distance helps on not creating more server lag, as we're not making the server busy sending us more data than what we really need. It also helps on not creating more client side lag, for there's less geometry to render in our computers. Don't forget it.

Now, let's go back to what we were saying: scripts. Are they really that big deal for the server?

If we check now all the information regarding to what a viewer software should do, we find a lot of tasks for the viewer (client) to do:

  • The subsystem devoted to animation
  • To deal with the asset server, the profiles server, the error logging system, groups
  • Graphically represent the avatar appearance
  • Performs some optimizing algorithms to speed the rendering of the world
  • It actually renders the world
  • Fetches textures from the server and decodes them
  • Deals with the sound system

and many other tasks that we may find by reading the reference in the wiki (at the end of these notes), but have you noticed that there's no word in here about the client running the scripts?

Right: the scripts run in the servers.

Keeping aside the fact that scripts use process time (and it's important to keep that time to the lowest), there's one more detail about them: Scripts use memory. The more running scripts, the more memory used from the servers.

But we know that the memory for a computer (and a server is nothing but a computer) is always finite. So a lot of scripts can actually fill the memory of the server.

What happens when a machine runs out of memory?

It needs to swap memory by using the hard drive.

And what's the big deal with this?

That all the system slows down... very noticeably. Because working with hard-drive memory is not as fast as working with RAM-memory. In fact, it's quite slow in comparison, and slows down the whole machine until the swap to disk is not needed anymore.

Not just this. Think now in a heavily scripted avatar, with all those running scripts using memory... teleporting. When an avatar teleports, all the data for representing it and the scripts are transfered among servers. All those megabytes used, transfered. If you ever have downloaded a song, you know that the process is not instantaneous. In fact, it takes a while.

An avatar wearing 160 mono scripts might be using 10 MB. This is a lot of scripts for an avatar, but yet, even less than half (or a quarter!) than what's usually seen. Those 10 MB need a second to be transferred if we're not within a local network (and remember: about 8000 servers... not all of them are within the same local network), assuming that we're talking a really fast connection (translation: they might need more than a second).

Now multiply this second by four, or five, since there are lots of avatars around running 500, 700, 800 (unnecessary) scripts... We're talking about requiring four, five seconds... for all the data of the avatar while teleporting.

Have you ever noticed when the sim seems to simply stop for a few seconds, and when you finally can control again your avatar, talk in local chat... a new avatar is on the sim? Yes, that was it: a heavily scripted avatar teleporting.

2013 note: Fortunately, this happens no more! Linden Lab improved the transfer of data on teleport during 2011 while at the same time, people began using less scripts. If you've rezzed in 2012, probably you've never lived this, but it's true... A sim could literally halt for a few seconds because of an avatar teleporting in! (Remember how many people used to crash on teleport? It was all the same: the more data to transfer, the bigger the chances of a network failure, and in those cases, SL uses to log you out.)

Still, without numbers, this about the memory getting full seems a blurry possibility. Let's see how quickly this may happen. Let the numbers talk.

Take the realistic number of an avatar wearing 30 MB on scripts (resizers and texture changers in hair, jewelry, shoes, plus AO's and other HUDs), multiply it by 40 avatars (which is quite a moderate number of avatars), and see the result.

30 MB/avatar x 40 avatar

1200 MB

Am I serious? Really? 1200 MB of memory used by 40 medium-heavily scripted avatars? Am I really saying that a whole gigabyte of memory, and even more, could be filled... by possibly nothing useful once you've set the hair/clothes/shoes/jewelry as you want them?

Yes, that I'm saying.

Of course, now you can say "Ah! But sims run in servers! Servers have a lot of memory! I don't need to get concerned! I want my useless resizer scripts on!"

I'm sorry, but we all need a reality check here.

Servers may have more memory than a normal computer. Not that much, still. Perhaps a normal computer may have 8 GB of memory, perhaps a server has 32 GB on.

So if we're in this really good case, we can think "well, no big deal: 32 GB, minus the 1.2 GB, still are several GB to go".

But then I need to say "hold on: do you remember that a server runs not one sim, but at least 4?"

Yikes. That cuts down the total of GB available for a sim by 4, in a good case (the class-five sims). Which means, each sim in that server only has 8 GB memory available. TOP. Because we're forgetting important details here:

  • A server is a computer, and computers need to run an operating system. Operating systems need memory, so no, most likely we don't have 32 GB available for the 4 sims, but possibly, 30 or 31. Plus the memory required by several applications for monitoring everything.
  • What about the scripts running in the sim? Oopsie. We've forgotten about them. The sim could also be heavily scripted, and get to double the needed memory.
  • What about all the memory needed for storing all the data required for objects and avatars that the simulator has to keep track of, to send it to our viewers? Oopsie, again.

This proves that the misuse of scripts is a real problem, and not a whim. There's a real problem here, and we have responsibility on it.

I've heard people saying that what should be done for solving this problem, is LL buying new machines. That why we, the residents, need to care about.

Saying that is not just completely unrealistic about how an environment like SL works (for what we all have a better idea now), but also selfish.

Resources are never infinite.

LL may buy all those new machines, with lots of memory (assuming it's possible), and what will happen?

Yes, it will happen that unaware residents will continue abusing from resources that are very finite. Resources that LL wouldn't need to acquire, or that could have far better uses than simply keeping the memory of a hair with a resizer, if we, the residents, were aware that we also have a responsibility on the use we do for the resources we're given.

Education is far a better solution, and no matter what some say, we have a responsibility.

Nowadays, the upcoming Mono2 sounds promising. Memory will be treated more effectively, performance will be improved. But still, scripts will keep using memory and resources. So we, the residents, keep having a responsibility about.

2013 note: Indeed memory treatment has been improved. But this doesn't take the fact that we, the residents, are the sole responsible of the resources needed by the content we generate/use. That part of the responsibility will be always on us.

Time to do something about.

I'm describing now a process that we can follow as soon as we acquire a new clothing item, or to clean from scripts old items we already have.

Proceeding to remove resizer scripts


We're learning now how to do this, so our inventory has clean copies, ready to use, whenever we're in a rush for changing clothes/hair/shoes/jewelry and just leave. For this purpose, I've included two objects in the class supplies: a personal version of my (infamous) script meter, and a pose stand.

There's also a script meter, as the one you usually see at the classes. Unfortunately, the hover text is quite limited (shows a maximum of 254 characters), so the personal version is for you to see not just how many scripts you (and only you) have on, but also, the total amount of memory used.

2013 note: There's a copy of these objects included in the following free package I have in Marketplace: "Low lag scripts for builders". Feel free to share them if you wish. Also, keep in mind these objects were made by the end of 2010, a bit of "in a hurry". That's not how I work normally :o)

What you should do at your place is: rez the "Pose stand" and the "Personal Script Meter" objects.

Please sit on the pose stand, and follow these steps:

  • Click the personal script meter and check your script count. It will also tell you the memory used by the scripts.
  • Let's begin with the hair: check where in your inventory you have the hair you're wearing.
  • Create a folder named "originals with scripts".
  • Copy and paste the scripted hair in that folder.
  • Click the hair you're wearing. It shows a menu usually offering the options ["This prim", "All prims"].
  • Select "All prims". This shows a second menu. Resize your hair if you need so. Once finished, select "Delete".
  • Let's wait all a bit, for all the scripts deleting.
  • Check again now your script count. You don't need to come bald to class. You just need having done this first. Remember that the flexis don't add to server side lag, but the scripts do. Remove the scripts from your hair before going out. You can do that quietly at home when you finish shopping. Now you can't say you didn't know about this.

NOTE: Depending on the resizer script, the percentages can be shown in the first page or in the second page. But the menus have a similar structure: percentage, delete option. If your menu does not offer a delete option, you better resign using that item and contact the creator for a non scripted replacement. We should not suffer the consequences of the myth about "no modify objects can't be copybotted". They can be.

Repeat the procedure with the attached items for your clothes. Let's give some time here too. The shoes may be a bit special, we're going for them separately.

Ready with the clothes? Repeat with the jewelry, if you have any.

Shoes, of course, may have resizers, and we need to proceed the same way. But here may happen something more: that they contain a script called "Invisiprim", or similar, in each invisiprim intended for hiding our feet.

2013 note: Invisiprims are nowadays obsolete and they render incorrectly when shadows are turned on. Still, if you're curious to know what they are and what they were used for, the text of the "Low lag scripts for builders" class explains it. I've decided to keep that text because invisiprims could still be used by griefers, and I explain there how to locate them.

If the shoes are modify, go for them: edit, check "Edit linked parts", select the invisiprim (the one that hides our avatar feet), and DELETE the script called "Invisiprim", or similar. Is it called "New Script"? Delete it anyway.

We don't need this script, and what's worse, in a lot of cases, it's a laggy one, because not only it uses memory, but it also uses more resources, as the most popular invisiprim script used everywhere also has a timer, which forces the server also doing some work each 30 seconds (as if the server hadn't enough with a memory occupied that shouldn't be!)

What if the shoes have a texture changer and we don't have any option to delete the scripts once the copies are done, and set to our taste? Talk to the creator, and try not using those shoes in a crowded place. Have handy non scripted shoes if you go to a crowded place. At a class, take them off. It's ok if you go barefoot. At least, we've been able of cleaning all the rest. Barefoot is not as ugly as bald. It's a deal for class ;-)

We've finished with the appearance, but if we check the script meters, it's likely that we still have a lot of scripts on. Unless you are wearing a scripted RLV collar (Open Collar uses about 31 scripts, for having a reference), where on Earth are all those scripts coming from?

Time to check the HUDs we have on.

Here is where common sense applies: are we in a danceplace? Then most likely we don't need combat HUDs, vampire HUDs, texture organizer HUDs, multitools... detach all of that. Are we in a class? Then sure we don't need all those HUDs: Detach them before coming (remember the issues teleporting that you can avoid!)

Take advantage from the tools your viewer may have, like the radar or the client side AO that some viewers have.

Experience from previous classes has shown me that the AO is a topic that is never covered with time enough, so we'll learn in another session how we can create a script-cut version from our AO's (that, if not using the client side one that some viewers have, which is of course preferred).

May we do something else to collaborate?


Yes.

Show your concern and write to the creators you usually buy, if you notice that their items are heavily scripted. Tell them that there's likely alternatives which don't require so many scripts, and that even some of them can be removed once their job is done. Probably they don't know about this either. Always presume ignorance before malice, until you give the information and the facts, so don't talk to them as if they were guilty on purpose. They most likely were as unaware as you.

There are still some applications that, unfortunately, need from high script counts, like those playing sounds, if they require several sources, or texture organizers. The reason is a technical one that will be discussed in the "Low lag scripts for builders" session. I don't want to bother all of you anymore. We've seen a lot now: time to process and digest.

Make a good use for all what we've seen today, take the time for acquiring these simple procedures as an habit in your second lives, and be responsible. Really, it's not that much effort. Because every script counts, and if we don't want to collaborate, now that we know what we can do... lag is our fault, not LL's one.

-- Auryn Beorn

Additional Resources

Posted by at
Labels: , ,

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)