Babbage Linden - Limit scripts PER PARCEL

If you need more resources you can buy a fulll sim or a private isle.

Why with a small 512 plot people are able to lag an entire mainland sim? Resources are more important than prims if I need 30 seconds to rez a cube in my land.

i allready know it will break some of my creations i spent weeks on.
(prim animations with puppeteer)

can we have a new animation system for prims then at the relase day of this change with bones? ( i allready know the answer )

another motivation killer...

ty LL

I thought that mono scheduling was going to be a problem, from my experience with real-time interpreted languages. The higher performance you get from an interpreter, the less you can micromanage its resources.

Moving the lag inducing objects from the 512 to somewhere else on the sim won't prevent the lag.

so does someone on a 512 plot using a lot of scripts lag the region more than you using a lot on your presumably bigger parcel then ?

My opinion to why it wasn't implemented long ago is because they didn't see such a growth..
Most times when Phillip Linden speaks about SL ..He speaks about how it's not this or that that holds them back but that they can't get anymore power than they have for the grid.

So pruning certain things as it grows or is going to grow more than likely has to be done at some point.
I don't look at these things as something to improve the current grid..I look at it as getting ready for something to come..
Growth hasn't really slowed much so something has to give or it's gonna be unusable i would think in time to a lot of people..

More people joining means more people buying and using and making things with scripts..

I have a feeling a lot of things i was taking for granted are just gonna be dust bunny catchers..

My main concern for me is will my Rezzer that can rezz a full sim build gonna be no good now?
will any rezzer be too much at the start up on the drop to rezz?
if not i guess rezzing and piecing link sets will have to be the way..
it will just take a bit longer so thats not really a problem for me..i'm used to zoning out on building anyways hehehehe

i just hope this does not impact the economy like gambling did or other things..
i have a tendency to hope for the best but plan for the worst..so hopefully it won't be the worst for people that depend on these things for their companies..
i know there will probably be some..i just hope there is an alternative adjustment for them if it is a major change..

tht is just my guess or $.02 or $2L on it lol

so my suggestion would be to stop making more and more land available for sale until the system can adequately handle what there is and give those currently paying value for money...

anything else is just greed surely ?

This will help reduce that considerably (but only regarding script-memory-induced lag, not physics issues, avatar count, etc.)

The amount of land has nothing to do with this issue. The amount of land per simulator does, but that would be disastrous to try to chage (and as the servers get faster, this aspect improves anyway).

You see, a typical server handles 4 regions. Each region runs on one of the server's 4 CPUs, sharing the computer's memory (possibly with memory partitions per region, possibly not, no doubt someone knows). In any case, these CPUs are what power our scripts. If they add a new region, that adds more land and more CPU power and memory for the scripts. It does not reduce the amount of memory available for scripts on other servers.

What this really is about is making it so that if you own a parcel of land, you're guaranteed your allotment of script memory, avoiding the possibility that a neighbor can hog all the resources at your expense.

By limiting you, it also limits others' ability to screw you.

The idea behind this is to stop script memory from suffering "the tragedy of the commons". See http://en.wikipedia.org/wiki/Tragedy_of_the_commons for more info. Overuse of shared resources is the major cause of lag in SL. This is an attempt to address one of them. Yes, there are many more, and no doubt we'll see attempts in the future to address them as well.

Ideally, each parcel would get its own virtual server with resource limits proportional to its size or cost, with access to shared resources (e.g., asset servers) throttled on a per-region basis. With such an architecture, you'd never be lagged by your neighbor. However, I doubt such an architecture would be efficient enough with today's technology.

well chances are it could be adjustment for that new continent we are getting and the future population expected..

i've only been here since 2006 so i don't know how SL ran the first couple of years..
but i'm sure at times it was pretty laggy..i know 2006 it was like..oh no i can't go they they have lag..
now i just judge it by what has the least amount of lag..
i think we were in the teens on population back then..i remember hitting 30k and thinking ..omg how are we gonna move around now lol

things just move so fast in growth in SL..i don't know anything that really grows like it on any platform other than the internet itself..

if it ever for some reason dropped back to 30k we would be moving around at the speed of light lol

i think the second they stop making room or land for people wanting room is the day they start to go backwards..so i don't think it is really greed..i think it's not wanting to stop growing..
if they ever find a resource that lets them open up more then it's gonna get very big around here..i think this is why Phillip Linden is such a pusher of Solar power as a main power grid..
it has to really suck that you know you have the ship to blast off and the take off power..just not enough fuel for a successful trip..

that helps in understanding the move in that direction..so it is sim related or server related i should say more than grid related..
that should still help the grid run a bit smoother i would think..or is that population that affects that..or both?

As a scripter, and as someone responsible for one of the bigger memory users (MLPV2, like any menu-based pose system), I see this as a good thing.

This is most likely to hurt owners of shops with lots of heavily scripted items, such as sex bed stores. It may cause them to adopt a different sales model, where they have an example of each engine for sale, and menuless examples of each bed on display, and a delivery mechanism that delivers you the model you want with the pose set you want. At first it'll be a big hassle for them, but later they'll find out it makes menu system updates much easier since they're not embedded in the floor models.

As I mentioned above, this helps us avoid the "tragedy of the commons" with respect to script memory. That's a good thing.

I also like the way they're discussing this first so we can prepare, and introducing it in phases. The first phase will break some content, since today, Mono scripts can temporarily exceed the 64K limit (currently, the system only checks when the script is swapped out: between events or sleeping). The first phase will disallow this, so we can find and fix those scripts. (I'd prefer a warning message now and failing the script later, to give us time to respond.)

The next phase will give us measurement tools, so we can see what we're really doing, and can discuss these issues with metrics based on actual usage in the grid.

After that, they'll choose and institute limits. Again, I hope that at first, they use a warning message, and after a decent interval (months) change the warnings to errors.

All of us want LL to make SL more robust. IMHO, this is a significant step in that direction.

OK- maybe i just don't understand this stuff enough- but wouldn't they be able to solve it by just using more servers and less regions/sims per server? If the norm now is four- i think i understand that- one per processor? can the need not be spread say two over the four total? Sorry- not techie at all- I'm just glad the damn thing turns on.

At first glance, Amaranthin, it would be sufficient simply rise the amount of memory per server, but...

This have costs, and;

This would not prevent people to make/use more memory hog scripts, and soon we would be seen the same situation again.

Since i joined SL, in January 2007, I've ever complained, even not being a scripter, just curious in the matter, that we do not have a tool to compare two similar scripts to see what one is more efficient in the use of resources.

Completly agree. Script limits by parcel better be on a switch for private islands/ estates. I am one of those crazy people who actally maintains and monitors my estates performance. I don't need this to force larger parcels for store plots.

On a different note if they get this right they are taking a huge advantage away from estate sims. Since you will be able to judge srcipt performance *anywhere*,I see this as one less reason to waste cash on private sims. Sure there are other reasons people own islands, but top scripts is a bigy for me.

Well, nothing is simple.

This change focuses on local impact, not resources shared between sims.

All kinds of things use shared resources, including avatars and scripts and even simple objects. When an object gets placed inworld, the sim needs to get info about the object from asset servers. When an "online indicator" sign's script checks to see if it's avatar is online, it's using a shared resource. These are just examples, and there are many, and it's not easy to make good generalizations, other than "more stuff uses more resources".

These global resources aren't addressed by the proposed change.

Sometimes, global resources are the ones causing the lag. Usually this is clear because the problems are happening everywhere.

Other times, lag is specific to your region. That can be caused by lots of different things: too many avatars, too many hoggy scripts, too many objects in motion, too many textures in the build, the list goes on.

This dovetails with the Adult continent thing and the observations that a bunch of highly-scripted sex places would end up sharing the same sim.

If LL has delayed doing anything about allocation of resources over a sim, then the soon-to-be Adult mainland sims will have forced the pace.

The script/memory limit/allocation issues are totally contained within each individual sim. They have no effect whatsoever on the overall grid.

Perhaps LL are - intentionally or unintentionally - ahead of the resident screams/demands on this one.

Excellent point, and I hope that LL takes note of this.

Lear, the link to Babbage's office hour transcript that you posted in the other thread is worth pulling in here:

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

It has a bit more info and discussion context than the blog referenced in the OP of this thread.

One thing I noticed was that pre-existing LSL2 scripts will continue to claim 16KB and Mono 64KB or more--but apparently never less (which differs from how I thought Mono scripts loaded currently). All but my big workhorse scripts will run fine in LSL2, so now I'm wondering if I've just been profligate with other people's memory by recompiling them to Mono on the chance they might demand less CPU that way.

Yes, or parcels with lots of menu-driven animation furniture. You know, Lear, one thing I did recently was graft some version of MLPV2 that I had lying around onto my little sim-wide animation server, so I could pull all the anims out of the MLPV2 furniture, make as many copies as I want in the sim and animate everybody with one copy of each animation. (Sort of "MLP meets Dance Ball." For that experiment, I just left all the pose information intact in the MLP-scripted device, but another option would be to also outboard all that to one sim-central location and only (if necessary) store instance-specific overrides in the local devices. Might save a ton of memory in multi-pose furniture stores, or for heavy multi-pose end users.

One product category that I suspect will need serious overhaul is texture organizers. There are some real beasts out there, with a gazillion memory scripts and general sim-lagging design that just aren't going to work anymore.

As others have noted, I too am a little concerned that vehicles aren't getting the special attention they need, at least judging by their absence in that office hour discussion. It's borked enough that vehicles still hit "parcel full" conditions for prims; that would simply be unacceptable for scripts.

Wonder if we can get some Linden comments on this ....

more important that all this 'adult/mature sim tosh'...

If he pay the same land fees he can lag a region using only a 16 sqm plot

so lagging a region with scripts is only okay if you have a lot of land and a lot of money

Yes if you need something you have to pay. I pay for lagged prims becouse resources are free.

Actually not entirely accurate. This is what the change is trying to fix. Right now scripts can push a single simulator to the point where the other 3 simulators on the same server are all lagged. Per Qie's link:

"[4:32] Babbage Linden: the reason this is being worked on is that currently you can use as much memory as you like for scripts
[4:32] Babbage Linden: where regions have lots of scripts running, they cause simulators to swap
[4:33] Babbage Linden: which destroys the performance of all regions running on that simulator host
[4:33] Babbage Linden: in order to avoid lag we need to limit the size of the simulator processes
[4:34] Babbage Linden: it only enforces per script limits currently
[4:34] Babbage Linden: which is both annoying (because you can't make a big script)
[4:34] Babbage Linden: and useless (because you just add more scripts, memory usage is not limited)
[4:35] Babbage Linden: once we have parcel and avatar memory pools we can actually limit script memory usage
[4:35] Babbage Linden: (which stops the simulators swapping)
[4:35] Babbage Linden: and we can allow scripts to use more memory"

And tying those comments back into the 16 sqm comments, you can end up with a 16 sqm parcel lagging an entire server and 4 simulators.

so as long as you pay what youre saying you have more right to lag other people ??