UNANNOUNCED Scripting Limits? ARE YOU KIDDING ME?????

Yea there is a couple of people just arrived in the photo garden and one has 1.5 milliseconds of script time. sim TD dropped to 30 when they piled in. If he doesn't leave pretty soon i'll tell him and his girlfriend that is wearing a demo hair wig with the demo sun burst thing transparent to gtfo. Probably copybotters anyway.

I would say the hard cap on these LL coded regions needs to be no more than 10 avatars. I stated months ago that the effective number of avatars drops on every rolling restart and by mid 2010 LL regions will no longer even function with one avatar. Looks like things are continuing to degrade in that direction. Klingdon best be hiring a new separate autonomous development staff to operate independently in a different location and see what is going on and if the degradation is intentional.

Spare time is always around 16ms on my homestead,but i agree most places i go in sl have 0 spare time

I am looking at a Homestead sim and am a little puzzled at what I see.

Time Dilation: 0.95
Sim FPS: ~43
Physics FPS: ~43.9

Frame time: 23.5
Physics time: 0.2, occasionally 1.8 (there's a cat wandering around)
Script time: 5.5 to 7.5
Spare time: 15.3

Why is the Frame time consistently over 22 AND the spare time is consistently over 14?

Interesting because the last place I expected to find spare time was on my homestead, but like the last two respondents on spare time on homesteads, mine is around 16.

Because thats not the only things a simulator does, it also handles data communications. When a new arrival shows up with a lot of attachments, it needs to send that to everyone in the region, which can slow it down, even though scripts and physics are not taking all the available frame time.

Once an hour the server does a region backup also, which requires a lot of data transfer.

And the other three homesteads you share that core with could be causing a slowdown.

Thanks, Daniel. There are two avatars in the sim, and no one arriving or going. I'm wondering about two things:

-- Should the "Script Time" target be lower for a Homestead?
-- This sim is very atmospheric, has quite a few objects doing looped sounds (by my standards at least; I see around 15 of them). Could that be causing issues?

The time dilation is consistently below 1, and sim frame rate consistently below 45, and both of those worry me.

Maybe there's an elephant in the room/sim..

....saying "I just make these numbers up."

The code that collects and reports the stats would be as fragile as al the rest of the code in the server.... and ....

I never take an error message from a system as gospel. I see it as
1) an indication that something has gone wrong
2) a general indication of whre the problem might be
The thinking is that if a system is broken, it can't always be trusted to report the percise nature of the brokenness.

In the case of homesteads, maybe there's a constant in the code that assumes a normal sim, so homesteads would never ring the alarm bells.

I'm seeing this same thing on my Island right now and also wondering. Of course there are only three of here right now. How do the stats that you see in the Statistics bar relate to the usage of other Regions on the same sever? Are there any tools or way to find out who you share server space with?

I know one of the mistakes the I make is in assuming everone else gets the same performance that I do. I have three different computers that I use for testing and setting up animations. I take it for granted that textures are loading fast enough but this is probably a result of them already cached. Might be why I get so little trafic. First time visitors may just never materialize

I have had homesteads for almost 2 years now and i have always found them lag free,except for that problem sl had about a month and a half ago,lag is non existent and spare time is always 16ms

I mentioned that this was the case on another thread and someone told me I didn't know what I was talking about. It looks like whoever originally told me that SL does indeed have script limits that are a "secret" until things stop working did in fact know what they were talking about...and they are in a position to know.. It evidently went into affect right after the last price increase when the land types changed. .

I think the OP's experience pretty much closed the speculation over this.

But. .but.. given the way SL lights work, you really would be far better off providing the illumination from one invisible prim light source that flicks on and off rather than messing around with with several different ones that will only interfere with each other.

In my experience, it really is best to treat separately the appearance of visible light sources and the light they apparently cast -- that's not to do with lag, particularly, but just that it's simpler, easier to control, and will generally end up looking far better.

Ok it's not some set "script limits" it's more like "grief fences". Sets of rules that can set off "countermeasures".

I've had this happen on my PRIVATE sims where I keep scripts WAY down.

There are tons of sims /severely/ overburdened with scripts and they do not get turned off all the time.

There are all kinds of griefing fence rules in place and have been for quite a while. They are continually added as new tactics are developed as well and they are always kept pretty secret.

I don't know this for absolute but I would bet 99% that there is a limit to some simultanious spike in script or physics use that causes them to be shut off automatically.

The level would be VERY high though as it is a VERY rare event. Being mainland I would guess that a grifing attack or one nereby would be the most likely explaination...

Spare Time 0:00 I think that says more about the loaded-up condition of the grid than that of the Spare Time stat being invalid. However,


Each of those statistics can be somewhat subjective and need to be weighed against all the others. All the times continually fluctuate in a busy region. I can spend up to an hour scanning (Region/Estate/Debug/Top Scripts) a single region -refreshing the numbers to get a fair overview of what is happening due to what seem like random time spikes.

A Homestead can take a good 30 minutes to thoroughly scan. Refresh refresh refresh those top scripts. I think the numbers Nika Talaj gives for Homesteads are reasonable I just hope you have access to Region/Estate tools Nika.. .
My hours scanning, tweaking performance, even if not removing very high scripts just maintaining equilibrium add up to around 15 hours per week (30 regions - mix of commercial, residential normal 15000 prim and Homestead sims) Interesting numbers when you also consider discussions and dialog between myself and the owner of the script wanting to know exactly what happened and why......on a mainland scale for LL to manually achieve the same result ....= big numbers something like 3000 hours per week? Automated script limits are inevitable in place of faster, better server hardware.

Similarly, I remember an occasion when I submitted two separate support tickets three days apart and the ticket numbers had a difference of 15,000 between them. Realistically - how much of a detailed explanation can we each expect for every personal circumstance that arises due to a system overload and limits being reached and systems being switched off.

Parcel owners on well managed private islands may not suffer at all when the script limits are brought in if they are routinely scanned for the best performance. I would like to think that the "subjective" overall amounts of resources will be permitted to apply to a parceled private region, as in, a controlled amount for a "managed whole region" rather than parcel size equals x amount of script time. The mainland however, must be destined for automated shutdown of scripts per parcel per sq.m owned. I presume an associated response will be included stating the reason why an object has been unable to rez or returned to the owner. Hopefully Group settings, roles and abilities will also be incorporated to support script time sharing. Let 's hope that individual parcels or avatars can be isolated rather than whole regions being affected.

Should objects be required to be script time tested or performance rated before they are set for sale or given away to an avatar that does not "own" a large enough parcel. How can an avatar be protected from buying a scripted object which they may not be able to use. Buyer beware or seller declare the performance?



I also wonder if high Avatar Render Costs will be limited ?- if so, it may get back to how sellers can represent the performance to make it sellable. It does seem intentional though, to allow avatars to decide on their own render cost. The true cost of feeling or looking great is often (needlessly) unintentionally high. It could be technical reasons or maybe there is high level support for allowing avatars to be who they want to be regardless of performance and express themselves with scripted attachments etc. It keeps them spending money and engaged with their own (perceived) visual superiority

I've been waiting for this final quarter of 2009 in which LL will be testing the future of script limits. Finally we should get some concrete performance numbers to work with - especially for Homesteads

was just told that last night on our homestead..thats not full...and not loaded up with scripts (weve just trashed it and are rebuilding slowly so its pretty emptyish) the scripts were turned off. My partner assumed id done it in error...but i hadnt.

What effect on a sim's performance do you say someone's ARC might have? I can see how it causes problems for someone's graphics card if it can't handle it and the user hasn't thought to turn on avatar imposters and turn down the number of visible avatars, but what does it do to the sim?

My understanding is that the current LL plan is to attempt to relate the amount of script memory available to the area of land.

What happens at the moment is that if the collection of scripts in a sim try to grab too much memory, the sim server responds by swapping memory between the server and the hard disk. This severely degrades performance not only for the sim but for all sims hosted in the server box. That's 3 other sims for normal sims and 15 other sims for homesteads.
This is the main driver for the plan to impose some limitations.

Any resulting reduction on script load on a sim would be an *indirect* effect of limiting script memory. We could still have a small number of scripts that consume most of the processing power. However the odds are that if a parcel - or parcels in a sim having the same owner - can only support so much script memory then the number of scripts running will have some limit, depending on how much memory they use individually.

Linden Office Hours transcripts generally don't make for user-friendly reading.
Here's an easy read summary of one in which Babbage Linden talks about the issues:
http://www.vintfalken.com/babbage-linden-on-openspace-script-limits/


What this might mean for the OP and the neighbours is "no change".
If the animal scripts are not big consumers of memory individually, then there would be nothing to stop many of them from running - flying - on the land. All of the issues raised by their physics and the sim script time expended on dealing with the physics would remain unchanged.




ETA:
A more recent Office Hour with Scouse standing in for Babbage. Always interesting to see another mind:-

http://wiki.secondlife.com/wiki/User:Babbage_Linden/Office_Hours/2009_08_05

ARC, per se, is just a client-side measure, but it can hint at disastrous effects an avatar can have on a sim or especially *arriving* in a sim. ARC is affected by the number of prims, and every time a boatload of prims plops into a region, the sim has to rez them all and tell all about them to any other viewers who might be interested. And some of those prims are likely to be scripted, which means those scripts have to get loaded into memory, slotted in the scheduler, and may even *do* stuff, the updates from which must be sent to other viewers. (Note that even scripts that are set "Not Running" still get loaded into sim memory, and those that are running despite having no active event handlers--e.g., bling with only a state_entry handler--nonetheless get slotted in the scheduler.)

ARC is not much of a hint, since it's more effected by textures and prim attributes that have no effect on the sim at all.

The biggest difference your arrival on a sim can make is whether you're running Mono scripts or not.

Right, I understand that, and I'm very aware, now, of Argent's point about Mono-compiled scripts in attachments, but what I'm trying to get a handle on is how much strain someone's high ARC hair or clothes put on the sim, as opposed to the strain placed on it by scripts -- whether compiled in Mono or LSL -- it may or may not contain.

I can see how it makes a difference -- though how much, I just don't know, and maybe someone can explain -- when I arrive or (I guess) when someone else arrives and the sim has to tell them what I'm wearing. But how much difference does it make when no one's coming and going, particularly if we're all just sat on dance balls and, from the sim's point of view, not moving around much?

If you have 100 attached high-ARC prims, that means the sim has to copy into your agent object a list of those prims and their parameters, and in the process check if they have scripts in them. That's up to... maybe... a few hundred bytes of data per prim, let's call it 10k total. It doesn't have to rez them, examine their geometry, read their textures, any of that... it just has to set it up so the client can download those parameters and fetch associated assets.

If it was a vehicle it would have to actually rez up to 30 prims into the sim, rebuild their geometry, and so on. But since attachments are non-physical and positionless (all prims in all attachments are dimensionless points in the center of the avatar as far as the sim is concerned) there's pretty much nothing for the sim to do other than making sure that the unpacked prim data gets into the client interest lists.

If you have one mono-compiled AO then it has to walk 64k of code and data, recompile the CIL code to machine code, rebuild the data structures... well, it completely swamps the prims. Even an LSL compiled script is 16k of data that has to at least be copied, that's a lot of prims.

Edit: Also... what Qie said below. Long term, unless the scripts are really atrocious it's the number of scripts and how much memory they use that matters more than anything else. Every script has to be checked in the main event loop, even if it's doing nothing. Scripts take up main memory, 16k for each LSL script, up to 64k for each Mono script. A small simple script like a poseball is best in mono, because it'll probably take up no more than a couple of K of RAM. Anything big, unless it's really compute intensive, is better in LSL.

I'm not disagreeing with Argent at all. The primcount is really only a very poor hint that there may be scripts hiding in those prims, and that completely overwhelms the effects of the prims themselves. The distinction I started out trying to make (and then distracted myself) is between the effects at avatar arrival time, and those that are steady-state as long as the agent remains in the sim. The Mono vs LSL effect is (mostly) an arrival-time thing; once they're running on the sim, it's a crap-shoot which script flavor is more damaging. And after the avatar and attachments have downloaded to all interested viewers, the prims themselves have no sim-side effect at all (well, until a new agent arrives on the scene and its viewer needs to know about all the other avatars' prims).

It is very easy to generate a very high ARC without having any measurable effect on sim performance. I think most furry avatars are a good example of that. On the other hand, if Missy Blingtard shows up with hundreds of resize-scripted prims in their hair and another thousand in those primmy boots and neko belt and run-once-and-forget bling jewelry with maybe a few channel 0 listeners, they'll probably come with a very high ARC.

Or, guests may be wearing texture organizers as HUDs; they could have single-digit ARCs and bring sim performance to its knees, invisibly, just by being there.

But...but... I sell lamps, so I have to have them all able to light the area - not particles

Someone posted on another thread that with 1.23 viewer, an older graphics card will now only see 2 local lite sources rather than 6....not good for lamp sellers

Since not everyone has state of the art hardware, that doesn't bode well either for those older card users who "upgraded" (LOL) their viewer.

Then you will see the problem with having several Christmas lights all acting as light sources on their own.. Yeah, I take the point about lamps, but lamps aren't Christmas lights.

Actually, when I'm trying to furnish an interior I almost always end up disabling the light from any lamps, candles and fires I've bought rather than made myself, and do the lighting with invisible prims. Otherwise it always ends up looking weird as the different lights interfere with each other because of where I want to put the objects that emit the light -- I bought them, after all, to furnish the room rather than illuminate it.

Sorry, and all that.. no disrespect to your lamps intended.

I just read about that in another thread and there's nothing I can do about it. But it's the same for all sellers of lamps so it's even. It's the buyers who are on the wrong end of it if they are unable to see that some of the lamps actually shed light. I hadn't even thought about it before but it's the same as always, except the number of lamps that can be seen to shed light is smaller.