Babbage Linden - Limit scripts PER PARCEL

/me wonders if this will make it more difficult to be a dog in SL. If so, what will canines and others with non-standard avatars do??? Descend on Linden-owned parcels and attack?? I'd rather give dog kisses than dog bites, but if necessary, I'm prepared to do what I need to do to defend my right to exist.

In addition, this makes me even more angry that mainland parcel owners can't see top scripts. How am I supposed to know if what I'm using is going to be a problem when this comes about?

It's coming, well actually something much more useful and soon:

http://wiki.secondlife.com/wiki/User:Babbage_Linden/Office_Hours/2008_12_03

Start reading around 8:27

EDIT: Before anyone asks......................
I say "much more useful" because if you have ever had access to the Estate Tools and Top Scripts it is kind of clunky. You have to repeatedly poll Top Scripts to try to get the peak usage of a script. To measure attached scripts you have to sit on a box with a script in it and again repeatedly poll. For attached scripts while moving you are out of luck. Being able to read the memory usage of your scripts will be a much needed improvement. We will also be able to start listing on Xstreet for example the memory usage of what you are looking at and if you would be able to use it. This will also finally shine a light on the scripters who are the better coders and who have always taken into account sim resources when scripting. Don't know what the numbers will be but if you are looking at two comparable products and one has a memory usage of 100 and the other has a memory usage of 1300............................................

They need to implement some of the JIRA suggestions that will let people reduce total script usage. For example llGetLinkPrimitiveParams().

Yes, there are no rational arguments against implementing llGetLinkPrimitiveParams. The old argument of it making it easier to steal content is ludicrous in the face of just stealing it using the much easier methods.

Sure, but at least the way HTTP In is *supposed* to work, it should be more robust than the current approach to vehicle *prims*... or at least that's how I read it.Yeah, for sure. It's been making me think more and more about wanting to set other linked prim properties other than llSetLinkPrimitiveParams(). For example, I'd love to be able to set llParticleSystem() from a script in another linked prim; same for llTargetOmega, texture animation, looped sound, etc. (Yeah, there's llRemoteLoadScriptPin() but that's gotta be a ton of overhead, and sleeps the calling script for 3 seconds.)

I don't see that. The only time vehicle prims are applied to parcel quota at this point is when you cross a sim boundary, and that's acknowledged to be a bug.

Somewhere I proposed "llSetEffectivePrim(integer link);" which would make all the prim-relative operations effect the indicated prim until you called "llSetEffectivePrim(0);". Perhaps it should also reset when you change state?

I've seen you say this before, but are you sure that's really the only time? I've been testing a (very fast) vehicle lately, and I sure have the impression that I've been hitting full parcels deep inside sims. I'll have to pay closer attention; it's kind of distracting when one has basically orbited oneself.
That sounds exactly right (with or without reverting at state change). We need to get something like this contemporaneously with the memory limits (or even before: this would equip us to reduce memory use, with or without limits).

It's because the vehicle status isn't maintained as part of the object state, and the vehicle and the rider are transferred separately so when it's seen on the other side of the sim boundary the receiving sim doesn't know it's a vehicle. If you're traveling fast enough, you may well be in an internal parcel by the time it checks, and this is EXACTLY the kind of bug that would screw up any other limits on a vehicle.

One ramification to this is that it'll force us scripters to optimize memory rather than CPU time. As programmers know, there's quite a lot of flexibility to do tradeoffs between memory and CPU time.

For example, memory-limited designs for menu furniture read the config for a menu when that menu is entered. This means that people have to wait, and the scripts take considerably more CPU time.

Still, this is needed, and we need to focus on forseeing issues to be resolved rather than moaning about the problems.

Can you please clarify what you mean here?

First, I assume/hope that script memory limits will work similarly to prim limits, in that if you own multiple parcels on a given sim, you can use your allotment in any of your parcels without worrying about the boundaries.

There's still an issue when some parcels need to be group-owned. Also, the question as to wether an estate manager should be able to override the allocations or disable the limits.

Is that what you're talking about, or am I missing the point?

It's quite funny really

We stand around the alter, examining entrails and reading signs.
Office Hours are a really bad way of transmitting this sort of technical information.
Don't these guys ever do White Papers?

I examine the entrails, follow an interesting tube and find Babbage referring to parcel *ownership* in this regard. This probably(?) means that they see the limits being controlled in the same way as prim limits.

Here's a 'worst case' for a vehicle:

It's very common to see sims with a small 128 sq.m triangle of Linden Protected land cut out of the corner. That sort of thing is extremely common in the water parts of the mainland.

Enter a scripted vehicle with a driver and x passengers.
There's only a 128m parcel to support all of that.
We assume that the worn scripted attachments of driver and passengers will be supported from their own memory pools, which in turn are allocated from a section of sim memory dedicated to the maximum number of avatars allowed in the sim.....
What memory pool are the vehicle scripts supported on?
Would there need to be a vehicle pool?

The vehicle would have been originaly rezzed as an object on a parcel that could support the prims and the script memory.
The moment it got sat on, it became a vehicle.
The moment it moved outside the parcel, the prims depend on the support of the new parcel, and the scripts depend on .....?

Perhaps vehicles could draw on the memory pool(s) of the driver and maybe passengers? If so, what happens when one or more unsit for a time less than the autoreturn time of the parcel?





Here's another common thing for vehicles.
Rezz a vehicle on build-enabled land.
It can't be driven over to a nearby Linden road/waterway, so use Edit to pick it up and move it.
The prim management works as it always did.
What happens about script memory when this scripted object enters the Linden land? It's not a vehicle until we sit on it.
The work-around once aware of the issue would be to sit on it before editing to move it onto the Linden land, leaving us with the issues above.

Overcommitment quotas allow you to have a much lower (and thus effective) global quota without breaking "small players". So, for example, let's say you want to allow 2MB of scripts on a First Land, that would mean you'd need to allow 256MB of scripts on a server. That's about 1/3 of the total space available for a server! If you allow scaled overcommitment, though, you can allow 2MB of scripts on a 512, 3MB on a 1024, 4MB on a 2048, 6MB on an 8192, 8MB on a 16384, 12 MB on 32768, and 16MB of scripts on the whole sim. This means that if EVERY parcel on the sim is using its full quota and they're all 512s, you'll start hitting the sim limit first... but in practice that's not what happens... most of most sims is empty, with only a few hotspots, so if the hotspots are limited (say, two 4096es each at 4MB) you still have plenty of resources for the rest of the sim.

I don't really understand scripting language. How do you tell if a script is more efficient? Especially if you are purchasing a scripted item?

Does anyone have tips on this?

There's no simple answer, unfortunately.

Before you buy the item, there's almost no way to tell.

After you buy the item, if you're an estate manager, you can run the script and look at "top scripts" display in estate tools Debug section. Of course, that only tells you about CPU usage, not memory usage. And you'd need to understand what's reasonable for a given purpose.

In addition, you'd need to understand the special case issues, such as, worn objects' scripts don't appear at all unless you're sitting on something, in which case they get counted for the object you're sitting on.

For open-source scripts, you can ask in the Scripting Tips forum, and get lots of (often contradictory) opinions.

After this change, hopefully you'll get more data. You'll at least be able to get data about script memory usage as a parcel owner, which is helpful. I hope they add CPU time to this display as well! And they're in the process of improving the worn/sitting confusion mentioned above.

Really? I didn't read that part. This is something mainland people will be able to do or will it still require that you're an estate manager to get at that sort of info?

Here you go:

http://wiki.secondlife.com/wiki/User:Babbage_Linden/Office_Hours/2008_12_03

Looks like for everyone.

Hm.. Still not seeing where he says that mainland parcel owners will be able to see what scripts are doing on their land.

Wish I could assign Babbage to SVC-835...

I'm sorry, but we're in the 21st century now. The days of counting CPU cycles and charging for mainframe execution time are long, long gone. There are many better ways to handle shared resources. Welcome to the modern day of computer ENGINEERING.

Which script is going to get only 300 bytes of memory because you're close to the limit? We're going to get memory errors all over the place that require manual script resets. Some scripts CAN'T be reset this way because of object permissions. Are we going to be able to prioritize which of our scripts we want to run if a limit is reached? I'd rather a dance ball get stuffed than that a banking system, wouldn't you? In a virtual world where you've allowed people to build up a decent economy and some serious business, it'd be nice to treat their data as important, and allow them to at least help prioritize their assets if you are going to torch some of them. Honestly, a hell of a lot more thought needs to go into this. People may be annoyed by griefers and thoughtless residents running a crud-load of intensive scripts, but I don't think they are thinking through the full consequences of this change.

Example strategies: schedule a script for execution in inverse proportion to the amount of memory it needs, and the frequency with which it accesses it. Store script memory to disk with a fair scheduling policy, placing scripts that need to pull memory from disk on a wait queue and servicing their requests with low-priority threads that'll wake them when their data is ready to be accessed. We have a fair idea of the number of prims and scripts that can run on a simulator, so scale your hardware resources enough to keep up. Hey, with the huge drop in resident-rented simulators due to price increases, LL should have plenty of hardware to salvage to shore up the performance of its existing servers, eh?

None. You haven't read the proposal.

Not literally, but there will be plenty of concerns like that. Functionality will be hampered significantly, as far as I can tell without any real recourse for the owners. Very little or no control. I don't see this as a positive change in any regard., and I certainly share concerns about abusive and thoughtless residents. Heck, I spend most of my SL time contributing to organizations and systems that help educate folks and combat the abuses.

There are about a billion other things that should be implemented before this, and will help alleviate the need for this kind of restriction. Plenty of security enhancements, for example.

[8:27] Babbage Linden: the code to measure script memory is now in QA
[8:27] Babbage Linden: and will probably be in 1.26
[8:27] Babbage Linden: we'll be working on the UI to display the currently used script resources early next year(my note: this was from December 0
[8:27] Babbage Linden: and will measure script use across the grid then
[8:28] Babbage Linden: then we can talk about what the script limits will be
[8:28] Babbage Linden: and you'll be able to use the UI changes to find out whether you'll be affected

While not directly stating per parcel, the assumption would be that it would be worthless if we could not tell on a parcel. Somewhere I also saw, I think in that transcript, it mentions being able to see and post on XStreet for example what the memory usage is for items.

Oh.. OK. I did see that bit..

/me hopes they do indeed make it visible to mainland parcel owners!

TY!