i love island sims (or more research into lagging)

if you create 128 prims with the "listen" script (included at the end of this post), an empty sim will go from 11,000 Sim FPS to 6000 Sim FPS. Surprisingly, this is even if they don't have anything to listen to (i.e. no one is saying anything). And even if all the objects have something to listen to, the Sim FPS only goes down by an additional 500.

if you create 128 prims with the "sit" script (included at the end of this post), an empty sim will remain at 11000 Sim FPS.

if you create 1024 empty prims, an empty sim will remain at 11000 Sim FPS.

"listen" script:
integer myListen;

default
{
on_rez(integer start_param)
{
llResetScript();

}

state_entry()
{
llListenRemove(myListen);
myListen = llListen(0, "", llGetOwner(), "";
llSay(0, "Hello, Avatar!";
}

touch_start(integer total_number)
{
llSay(0, "Touched.";
}

listen(integer channel, string obj, key ID, string message)
{
llSay(0, obj + message);
}
}


"sit" script
default
{
on_rez(integer start_param)
{
llResetScript();
}

state_entry()
{
vector mySize = llGetScale();
rotation myRot = llGetRot();

rotation sitRot;

sitRot = llEuler2Rot(DEG_TO_RAD * <270, 0, 270>;

llSitTarget(<0.0, mySize.y / 1.37, mySize.z / 5.5>
, sitRot);

}

}

Listens are extremely horrible for simulator performance. One very recent example of this is my Image-Transfer Device's grid. The grid is composed of potentially hundreds of prims when fully rezzed. When pixels are rezzed, they listen on a channel for image information. With the first versions, this listen handle remained open throughout the life of the pixel. This made the simulator Run Tasks skyrocket and FPS plummet. The newest version removes the listen as soon as it possibly can, so, when the image is fully loaded, even 1800 prims all packed together, each with a script, provide an almost immeasurable performance drop in the sim.

I was going to ask about removing listens. Have you experimented with this His?

With the Deus Via game board, I linked as many of the tiles together as I could resulting in four sections. One listen in each section and link messages to control te color and texture of the tiles.

Here's something to test... 128 tiles listening to the same channel vs. 128 tiles listening on 128 different channels. results when both idle and when actually listening to something.

128 objects with the "timer" script (included at end of post)

Sim goes from 11000 Sim FPS to 6000 Sim FPS.

please note: when i took the sim FPS measurement the timer had not gone off yet


"timer" script:
default
{

on_rez(integer start_param)
{
llResetScript();
}

state_entry()
{
llSetTimerEvent(1000.0);
}

touch_start(integer total_number)
{
llSay(0, "Touched.";
}

timer()
{
llSetTimerEvent(1000.0);
}
}

so adding one agent to a sim with only one agent already in it drops the Sim FPS by about 500 FPS.

128 prims with "particle" script

does not lower the Sim FPS

which makes sense since particles are rendered on the client

"particle" script
default
{
on_rez()
{
llResetScript();
}

state_entry()
{
llParticleSystem([
PSYS_PART_FLAGS, 0
| PSYS_PART_EMISSIVE_MASK
| PSYS_PART_INTERP_COLOR_MASK
| PSYS_PART_INTERP_SCALE_MASK
//| PSYS_PART_FOLLOW_SRC_MASK
| PSYS_PART_FOLLOW_VELOCITY_MASK
,
PSYS_SRC_PATTERN, PSYS_SRC_PATTERN_ANGLE,
PSYS_PART_MAX_AGE,2.00000,
PSYS_PART_START_COLOR,<1.10000, 1.10000, 1.00000>,
PSYS_PART_END_COLOR,<2.0000, 2.00000, 0.00000>,
PSYS_PART_START_SCALE,<0.10000, 0.40000, 0.10000>,
PSYS_PART_END_SCALE,<0.10000, 0.10000, 0.10000>,
PSYS_SRC_BURST_RATE,0.200,
PSYS_SRC_ACCEL,<0.00000, 0.00000, 0.00000>,
PSYS_SRC_BURST_PART_COUNT,8,
PSYS_SRC_BURST_RADIUS,.2800,
PSYS_SRC_BURST_SPEED_MIN,0.10000,
PSYS_SRC_BURST_SPEED_MAX,0.300000,
PSYS_SRC_TARGET_KEY,(key)"",
PSYS_SRC_INNERANGLE,1.000,
PSYS_SRC_OUTERANGLE,6.283000,
PSYS_SRC_OMEGA,<0.00000, 0.00000, 0.00000>,
PSYS_SRC_MAX_AGE,0.000000,
PSYS_PART_START_ALPHA,.500000,
PSYS_PART_END_ALPHA,0.000000
]);
}

}

128 physical prims causes the Sim FPS to drop from 11,000 Sim FPS to 6,000 Sim FPS

Anything over 1,000 is abnormal and just about anything will disrupt that perfect idleness a great deal. Maybe put enough scripts or avatars in there to slow the sim down to something aproaching normal and get it drive gear insead of neutral... THEN start testing.

not yet. just getting some baseline values first.

His have you tried your listen experiment with LinkMessages?
I have heard people say that linkmessages in object with many prims cause alot of FPS strain, So it would be interesting to see the results. Of course you'd probably have to send linkmessages and note the differences in FPS, since they aren't always on like listens.

not yet.

Fascinating stuff, keep up the good work.

i used to think that alpha channel textures were really bad for the sim. turn out that's not that case. though it may still affect the client

512 prims with alpha texture - no effect

128 prims with the "link_message" script

no long term effect on the sim

i'm not convinced that this test signifies in anyway.

"link_message" script:

default
{
state_entry()
{
}

link_message(integer sender, integer number, string message, key id)
{
}

}

Is there any difference using the Transparency setting on the Texture tab? I was told (back in beta) that this was more computation intensive than using an alpha texture.

using the transparency tab and using an alpha texture have the same effect on SIM FPS - negligible to none.

after 8000 prims fully rez, they do not cause any appreciable decrease in sim FPS (~9500 sim FPS to aroudn 9400 sim FPS).

trying to delete this many objects at one time... well that's a BAD THING.

lol Thank you for the last post His =)

I would like to add something to your computations about Linked Messages. At the telehub in Kumori I have a giant map of the world which uses listens and linked messages. There is not very much else in my sim right now hehe. However I have discovered that the FPS drops merely because there are 900 scripts in a single place. NOT because of the linked message use =) llMessageLinked has saved my llListen life lol Channels are great and all, but they still lag the hell out of the server compared to llMessageLinked. I will update you on my findings for sure when I update the map to version 2.0, which is written but not implemented yet. Higher number of scripts but less prims and processing. Stop by the island if you'd like to chat about it =D

Just to add some perepective...

Just because something reduces Sim FPS, doesn't mean that it will adversely affect Avatar experience or cause problems in the sim.

The sims are smart enough to reduce the processing time of things like timers, by itself. If you requested a timer to "fire" every 100ms, the server may not service your request but every 250ms. So the effect on sim fps is measureable, but does it affect everything in the end? Probably not much at all.

Now, texture or color updates on the other hand may reduce sim fps, but may also affect the avatar experience adversly. Notecard reads may cause just as much sim fps drop as timers, but may be harder to throttle as the sim is under heavier and heavier load.

I just want to caution against vilifying something that may reduce an empty sim's fps, but may not actually contribute to perceived or actual lag with respect to the avatar's experience (movement, sim border crossing, client fps) or the successful execution of other scripts.

Edit: typos

no one thing (object, script, etc) alone causes sim or client lag.

however, in aggregate, it adds up to lag.

it behooves people to know that every little thing contributes to lag. and that they should consider what is contributing to lag.

this is not to say that people should not do things that cause lag.

this is to say that perhaps people should consider if they need to leave their scripted objects active while they aren't around.

or if there is a more lag friendly way to do something, maybe the should do it that way.

* * *

the general attitude among individual residents is that "my one little <whatever it is> don't cause notice able lag." but all those individual items cause lag in aggregate. lag does not come out of the ether; it is the aggregated consumption of server resources spread out across many objects, scripts, and avs.

* * *

- avs are the number one source of lag.
- physical objects in motion are the number two source of lag (but shows up in the physics fps more than the sim fps)
- scripts are the number three source of lag

there's not much the players can do about av related lag.
reducing the number of physical objects helps.

but the scripting problem is subtle and mutli-faceted. there isn't any one problem that is the source of lag, it is the accumulation of small amounts of lag here and there that needs to be addressed. not to say "don't do these things" but to say, "consider what you are doing."

in the end lag is a courtesy thing.

* * *

prim and texture lag happens more for the client side than the server side, fyi.

Don't get me wrong. I think this is a great and necesary battery of tests to do. I'm just pointing out from my programming experience outside and inside of SL, that just because something uses server resources, doesn't mean that it causes lag.

Take a high-intensity, low priority proces like Seti@Home. It is designed to use the processor at the fullest, but it is low priority. If *any* process on the system needs to use the processor, the operating system will give less and lesss processor time to Seti@Home. No effect at all on the other running processes.

Similarly, with Windows Timer Messages on a Windows OS system. Windows Timer Messages can add up, and use 90 or even 100% of the system. But, Windows Timer Messages are the lowest priority on the sytem. Even lower than painting windows. If anything on the system needs the processor, the Windows Timer Messages will simply be delayed. No effect at all on the other running processes, even if the timers were utilizing 100% of the processor time before.

I only bring this up in that running these tests might not actually tell us anything about what is actually causing harmful Sim FPS reductions. Reductions that the simulator server may or may not be able to fix on its own.

Just some thoughts. I wish a Linden would give us some more information from their tests. I'm just bring what I know as a RL and SL programmer to the table, in hopes that we can understand more about lag, and how we can all work together to share server resources as best we can.

as someone who used to do qa and performance testing on back-end and middle-tier servers, i will dispute this with you.

granted that what you say is theoretically true, my experience tells me that it's not true in practice.

i do not have hard numbers to back anything up yet, and i many never have the number considering the amount of work that entails (i'm not getting paid like i used to do this tedious kind of performance testing). but even so, the behavior here suggests that processes here aren't like seti@home in that they do not appear to yield their resources gracefully.

and even if they did, the sheer number of scripts in sl would causes different problems relating to context-switching, threading, multi-tasking, etc.

* * *

again, i emphasize that it isn't any one thing that causes lag. nor is it even that scripts cause lag, it's that all the scripts together cause lag.

selecting the most lag friendly methods is a matter of courtesy.

* * *

i forget who, but someone said that some scripters were inconsiderate because they don't choose lag friendly coding styles. i think they just don't realize the small cummulative impact of their choices; that's not inconsideration so much as lack of information.

* * *

to some extent none of this is about reducing lag. why? for the same reason that when sysadmins add more disk space then that disk space rapidly fills to capacity. so as server resources are freed up by whatever anti-lag measure are discovered, then the number of scripts may increase, or the complexity of existing scripts may increase use up the released resources.

but maybe people will turn off unused scripts. or perhaps they will write more lag-friendly scripts. or not.

but writing scripts that use fewer resources also means that those scripts will generally run faster because they are competing more efficiently for limited system resources.

i was looking at the ll website and they are trying to hire a qa manager. given that they don't have a qa manager, i seriously doubt they have much in the way of performance numbers that are fine-grained. yet.

Thank you His, I think what you are doing is great. I'm just trying to caution against assuming that something that make a 1000 fps drop in an empty sim is the same thinga as another thing that makes a 1000 fps drop in an empty sim.

The one thing may be easy to throttle back, such as timers. But the other thing, such as maybe requesting something from the dataserver or causing an update to a prim color/texture/size/cut/etc. may be harder to cut back.

I'm just suggesting that reductions in an empty sim's fps isn't as good a measure as Time Dilation effects or Run Tasks.