DriftWood Resort: LGTB and Straight friendly resort for the nudist and swinger in Second Life

Lots of things cause lag. Impossible to list them all. No one thing, or one person (usually, unless it's a griefer) is the cause of it, it's a cumulation of many many factors.

Some of it is client-side, meaning that the lag is personal to each individual's SL client. The primary cause of client-side lag is that the person has their Draw Distance set too high for their Internet connection and video card to handle quickly, so they get lagged (have "rubber banding") when trying to walk or move) while images are sent to their monitor for display. Another factor can be particles -- if they have their particle level set too high then they might get lagged if they get near a lot of particles.

Client-side lag is ALWAYS the responsibility of the person having it. It's not anyone else's "fault" and nobody should have to modify their behavior to reduce it. It's each person's job to tweak their OWN client so they personally experience less lag. Telling somone "turn off the damn particles" for instance is foolish. The particles aren't causing the lag, each individual can turn down particles if it's lagging them.

Of course, it's irresponsible for builders to use too many (or any) high-resolution textures on their products, as everyone's viewer has to work double-hard to make the textures rez. However, policing that is next to impossible so people just have to lower their expectations for sharp images if their current system can't handle a glut of high-res textures. (shrug)

------------------------------

Server-side lag, on the other hand, is lag that affects everyone on the entire server (and cumulative server lag ultimately affects the entire grid) and IS the responsibility of everyone on that server. It can be caused by many things, and all of them are controllable by the individuals and the region owner. It's not possible (or desirable) to reduce the lag on a region to zero. To do that you would have to remove all scripts from the region and kick all the people off (including yourself) and let it sit empty. Not much fun! FUN = LAG, so lag is not unavoidable, just annoying. ;-) However, it's always possible to reduce it.

Among other things server-side lag can be from:

1) Well, we all know, too many avatars on the region cause the server to lag. The server software has to keep track of every avatar' position, has to keep track of every avatar's relationship to every other avatar as well as to all the non-phantom prims on the region, and has to animate each avatar when requested. On top of all that, the server has to pump the images of all the avatars (and everything they are wearing) moving in relation to each other and all the objects near them out to whoever is looking at them in-world (this is why prim hair and prim-heavy attachments are a bad thing in crowds -- the server has to render the image of EACH PIECE of everyone's hair to everyone else! and change the positions too, as the avatars move around! Wear a hat, dammit! (lol)). The more avatars there are on a region LOOKING at things and each other, the more work the server has to do sending all the constantly-changing movements out to everyone who is looking!! So all of that "relational" tracking is server-intensive. That's why avatars will crash a server faster than anything else. And remember, the SL architecture is outdated, so modern gaming performance isn't possible and can't be expected.

By the way, did you know that a "SIT" is an animation, even if it's dead still? The normal default position of a still avatar is standing quietly. Sitting on a poseball or any other sit-object is forcing the AV to stay in the chosen position while it (technically) is trying to return to it's default standing position. So, a group of avatars who are sitting are more lag-producing than a group of avatars standing. You can see this in your Region Owner scripts panel -- watch the script time being generated by an avatar that is standing, then have the same avatar sit on some furniture or a pose ball and watch the numbers go up. :-)

2) Related to that, collisions can cause server lag. In fact, too many collisions can crash a region (griefers use mega-collisions to crash sims sometimes). It takes a LOT of collisions to crash a region though -- thousands and thousands at once -- so minor collisions are trivial. The way to reduce collision lag is:

A. Make as many things on the region PHANTOM as possible. Anything that does not require "solidity" to function properly (of course, things like floors and walls need to be solid) should be turned phantom whenever possible. That includes all plants, rocks that are for decoration only (and not standing on), furniture, decorations, pictures on the walls, everything. As soon as something is phantom then the server only has to collect and send out the image of the object, it can totally forget that object exists otherwise -- it no longer has to calculate the object's location and whether or not an avatar (or other moving object) is "colliding" with it. I make all the furnishings in my homes phantom. Not only does it reduce region lag, it's much easier to get around AND you never get that being thrown into the air business when you dismount a sit.

B. Reduce the number of colliding objects on the region. This usually (but not always) means animals that wander around bumping into things. It can also mean unattended vehicles that are stuck bumping into a wall or things like that. Of course, with the new pathfinding abilities now built into the server software, up-to-date objects that utilize pathfinding don't crash into things, they go around objects ... but older, non-pathfinding objects still collide. When it comes to animals, they are fine walking around when the owner is home enjoying them, but the other 99% of the time they should be de-rezzed, or parked in their beds so they don't wander around (kind of silly for a pet to be walking around with no person to enjoy it anyway, in my opinion -- they aren't alive, the are scripts! lol).

3) Scripted attachments on avatars. This is a biggie. The more active scripted objects an avatar is lugging around with them the greater their demand on the server in addition to what was already mentioned above. Scripted items not only talk to the server (wasting cycle time) they use up region RAM. A region only has 300MB of RAM available. That's a lot, but when one person is, for example, using up 30MB of RAM all by himself that is too much! As the region runs out of available memory it slows down to swap RAM out to a disk cache (same as Windows uses a swap file to handle overload). Cached memory is WAY slower than RAM, so the more resources that are gobbled up by scripted attachments the slower the region will run.

There is no set in stone rule for scripted attachments ... just the rule, "the fewer the better." Depends on the region and the needs of the residents. On a combat region, for example, everyone is going to be wearing combat and/or magic HUDs to play. Can't be helped. On the other hand, they should not be wearing those HUDs while they go out shopping, or go to a club to dance, or visit a friend, etc., because they are lagging everyone on the region. You get the picture. People need to take responsibility for being as script-light as possible. It's generally accepted that under normal circumstances no one person should be using up more than 2MB of region RAM (and that's generous ... 1MB is more reasonable) ... but you will see in many places people using as much as 30, 40, 50 or MORE megabytes of RAM. Amazing.

There are gadgets you can buy that count the number of scripts on people and display them in public (I have one that can be both a display and also an attached HUD). Of course, these gadgets are themselves scripted scanners, so they cause some lag too. Heheh ... you can't win. Anyway, this helps, but only if the laggers are also gotten after to reduce their impact by whoever is in charge. Most people are defensive and won't reduce their scripts, even if everyone can see they are overloaded, until they are spoken to by a manager (club manager, sim manager, whatever). My never-ending aggravation in clubs is the people who come in covered in scripted hair, clothing, wearing their dance hud, their sex hud, their combat hud and then throwing in a radar hud. GAH! ;-)

4) Active listens. An active listen is a script that is actively waiting for someone (or another scripted object) to "say" something to it. If it is scripted poorly it listens continuously, 24/7. This is bad and bad scripting. Properly scripted objects only activate temporarily (usually when clicked, or chosen on a menu) and listen for only a short time, then time out and shut down. I'm sure you have seen this many times, when you don't say a command fast enough the item will shut off. Generally the worst offenders are pose balls, or objects with poses in them, that activate upon verbal command. For example, pose balls that are always waiting for someone to say "Hide" or "Show." The better option is for an object to be dormant until it is manually clicked ... like pose balls that give you the option to sit on RIGHT click, but hide themselves on LEFT click. By the way, the infamous "chat lag" is when there is too much activity on Channel 0, which is the open chat channel. In past years a sim that was full of poseballs all listening on Channel 0 for someone to say Show/Hide slowed down chatting to practically zero. :-)

Properly scripted animation packages (like cuddle rugs, or sex beds, or dungeon furniture, whatever) will always have two lag-reducing options. One of them is the STOP button and the other is the SHUTDOWN button. Responsible residents will use these, and NOT leave active poses sitting out in-world after they stand up from using them. When someone is done using the poses they should click the STOP button which de-rezzes all the scripted pose balls and puts the object to sleep so it is using minimal resources (mostly RAM). Clicking the SHUTDOWN button takes the whole process one step further and completely shuts down all the scripts, so the object is basically inert. Shutdown should be used when an object is used only rarely but needs to be kept rezzed in-world for appearances (of course, taking something back into inventory is the ultimate de-lagger). For example, I have a coffee table from N4RS. 99.9% of the time it's just a coffee table, so I have it always in shutdown mode. When I want to activate the animations I can turn it on by double clicking it, then shut it down when I'm done, but all the non-use time is totally lag-free.

------------------

So, the two things that are hidden from view generally are the region RAM that is being used, and the calls to the server that are being made. There are many things that MUST call the server to function properly. That's a given. Intermittent calls are fine, and normal. This is why many things you buy give you the chance to talk to the server LESS often, and the less often the better.

One example is security orbs. In order for the orb to see if there is an intruder it has to scan the area. This costs a server call. So an orb that is scanning every 2 seconds (ridiculous) is way more laggy than one that is only scanning once every 30 or 60 seconds. Another example, I have a slide-show panel. When a picture is transitioning to the next image the device has to call the server to feed the images to the viewer of the person looking at it. Another factor is how often the picture is changed. Once every 5 seconds is way more laggy than once every 60 seconds, etc. In the settings I can adjust the frequency of the changes and the "smoothness" of the transition. The smoother it looks the more calls it has to make, so the right thing to do is set it to where it's just barely smooth, which I have done, so it only calls the server in short bursts intermittently.

The problem is not individual objects but rather when multiple objects call the server continuously, in a steady heavy flow of server requests. This is bad. The reason is script concurrency reduces available processing cycles, which is measured as Time Dilation on the Statistics panel. The busier the server is the lower the Time Dilation number goes. A perfectly lag-free environment will show a Time Dilation of 1.00 (or 100% real time function). Any busy-ness of the server will proportionately reduce the TD momentarily. If the TD gets low enough the server (and/or the resident's client) will crash. In all cases, when the TD goes down, everyone on the server is lagged at the same time. It affects everyone.

Bear with me, because I'm going to use the analogy I always gave the renters who didn't understand why all their laggy items mattered. It was to help them visualize concurrency (so excuse me if it sounds like talking down, because usually I was!) ;-)

Think of the server as a star, or the Sun. All alone it shines bright and hot. Then think of all the scripts and avatars on the region as planets circling the star. Some are big and some are small, but all are orbiting the star at completely different and random rates. And there are (on a busy region) hundreds to thousands of them. At any given moment two or more of the planets will align somewhere around the orbit. This happens randomly depending on the configuration. Every time two or more of the planets align the sun dims momentarily. The more align at once, the dimmer the sun gets, then flares back up again. These are lag spikes ... when the Time Dilation takes a nose dive. If enough all align at the same time, the sun will go out ... crash.

So, the ideal thing to do is reduce the number of calls to the server. The fewer there are the lower the probability and frequency of alignments. Simple.

Active calls to the server can be turned on in anyone's viewer by pressing CTRL-ALT-SHIFT-U all at once (U is for "updates"). It can also be activated by first displaying the DEVELOP menu on the top toolbar (CTRL-ALT-Q), then choosing "Show Info" then "Show Updates to Objects" from the drop-down menu.

Items that are intermittently calling the server are fine and normal and don't cause a problem ... but anything that is pouring out a heavy continuous barrage of server calls is increasing the probablility of concurrency and therefore lag spikes, so the fewer of them on the region the better.

Shutting up now. :-D

Friday, February 15, 2013

Things To Do at Driftwood: 7seas

Sunday, January 6, 2013

New to the GA Dance

Friday, January 4, 2013

help fight the lag

Tuesday, December 25, 2012

Driftwood Mission and Rules