Late last week I was attending a Linden Office Hour, and a coming feature was brought up, Script Limits. Apparently the idea is to limit scripts by avatar and/or by parcel, although no further details were given.
So I ask, does anyone have more information about this coming feature, and as far as Script Limits go, what do you feel would be a reasonable limit A) per avatar, and B) per parcel?
Welcome to the Second Life Forums Archive
These forums are CLOSED. Please visit the new forums HERE
Script Limits: what should they be? |
|
|
Darien Caldwell
Registered User
Join date: 12 Oct 2006
Posts: 3,127
|
06-23-2008 16:22
_____________________
|
|
Qie Niangao
Coin-operated
Join date: 24 May 2006
Posts: 7,138
|
06-23-2008 16:31
News to me, and pretty hard to see how it's gonna work--or be effective. The first obvious question would be whether attachments count against the parcel limits. If so, this will be the best griefing opportunity evah: I'll just load up my avatar with no-op scripts and fly around to my competitors. And if not: Hey, bot time!
_____________________
Archived for Your Protection
|
|
Argos Hawks
Eclectically Esoteric
Join date: 24 Jan 2007
Posts: 1,037
|
06-23-2008 16:34
If they do something like that, I hope they do it by processor usage and not by number of scripts. I think a lot of problems could be solved by simply allowing people to see the script load of avatars. If you're sim was running at 22ms, and you could find the av whose attachments were taking up the processor time, you could help them figure out what attachments they needed to get rid of.
_____________________
Step 1: Create virtual world
Step 2: ??? Step 3: Profit |
|
Travis Lambert
White dog, red collar
Join date: 3 Jun 2004
Posts: 2,819
|
06-23-2008 16:43
This was talked about before - long, long ago. Its one of those features that have been in the queue forever.
If its the same as was discussed before, it involves allocating *script time priority* (Processor cycle priority) based upon how much land is owned in the sim, with a certain amount reserved for 'commons' (people just passing through). The theory behind it, is to limit the amount griefers can lag the sim by using heavy scripts, or how much owners of 16m ad farms can lag the rest of the sim. Its basically allocating simulator resources using a similar metric as prim resources are allocated. It certainly has its pros & cons - but personally, I think we'd all be better off with a system like this in place. Providing they allocated enough resources to the commons so pass-thru travellers aren't affected. _____________________
------------------
The Shelter The Shelter is a non-profit recreation center for new residents, and supporters of new residents. Our goal is to provide a positive & supportive social environment for those looking for one in our overwhelming world. |
|
Amity Slade
Registered User
Join date: 14 Feb 2007
Posts: 2,183
|
06-23-2008 16:44
It's a great idea, long overdue. There need to be limits to the amount of stress any one resident can put on the system. The only limit now is prims, and we see where that has brought us. I'd agree with previous sentiment that it would only be effective if tied to actual resource usage, rather than a simple limit on number. And scripts aren't the only currently unlimited kind of content that causes stress on resources; all kinds of content needs to be considered.
|
|
Qie Niangao
Coin-operated
Join date: 24 May 2006
Posts: 7,138
|
06-23-2008 16:56
If its the same as was discussed before, it involves allocating *script time priority* (Processor cycle priority) based upon how much land is owned in the sim, with a certain amount reserved for 'commons' (people just passing through). Slightly related: Do we know if they re-wrote the scheduler for Mono, or does some time still get used each frame for idle scripts--even those with only a state-entry handler? _____________________
Archived for Your Protection
|
|
Dana Hickman
Leather & Lace™
Join date: 10 Oct 2006
Posts: 1,515
|
06-23-2008 17:57
News to me, and pretty hard to see how it's gonna work--or be effective. If each scripts "processing weight" is tied to the parent object owners name and then totaled by owner name, that would limit land owners stuff and AV attachments. Add in a per parcel limit based on amount of land owned to handle land with multple object owners (potential loophole), and I think it could be effective. If the exception or overhead meant for vehicles and people passing through is smart enough to take into account the total number and what parcel they're over, that might severely limit sim-hogging by smaller clubs, malls, etc.. |
|
Gabriele Graves
Always and Forever, FULL
Join date: 23 Apr 2007
Posts: 6,205
|
06-23-2008 18:11
Conversely, depending on what limits are imposed it could introduce widespread breakage and actually stop some of the more creative uses of scripts that we see in builds today. Number of scripts are not usually the problem - it is what those scripts are doing that is in most cases the problem.
In a very memory constrained environment such as LSL there will always be multpile scripts used to split things up so that larger amounts of data can be handled or to parallelize calculations. If LL were to make more memory available per script perhaps the need for lots of scripts would lessen naturally. _____________________
 Trout Rating: I'm giving you an 8.2 on the Troutchter Earth-Movement Slut Scale. You are an amazing, enchanting woman, and, when the situation calls for it, a slut of the very best sort. Congratulations and shame on you! |
|
Viktoria Dovgal
…
Join date: 29 Jul 2007
Posts: 3,593
|
06-23-2008 18:29
This came up on the LSL scripting list. The first test will be with the http server on a prim stuff that is being played with. In that case, the number of available URLs will be rationed out according to land owned. A likely subsequent limit, if that goes well, would be on total script memory used, and nothing about how it might work is set in stone because it's still being played with. Also mentioned was that script IPS isn't strictly about script time, so it's not a great statistic.
_____________________
|
|
Vampaerus Wysznik
bad lurker
Join date: 12 Apr 2008
Posts: 1,011
|
06-23-2008 18:45
calculating a scripts "weight" is in and of itself a complex process. I wouldn't hold out for anything quite that sophisticated. You could end up spending more resources just on figuring out how to spend resources.
Breaking up sim time by parcel size makes good sense to me. On the flip side, I think the "common" slice should be divided by Av, not by script. It would make people more likely to police themselves if they only choke their own time by running umpteen scripts. _____________________
Small scale web hosting for your SL or RL. Payable monthly in L$.
|
|
Jeffrey Gomez
Cubed™
Join date: 11 Jun 2004
Posts: 3,522
|
06-23-2008 20:03
I thought we got a piece of this back in 1.7 when they implemented the "Script Scheduler."
Though script limits per parcel would be a good thing for static objects, and have been suggested for years upon years. _____________________
---
|
|
Darien Caldwell
Registered User
Join date: 12 Oct 2006
Posts: 3,127
|
06-24-2008 12:11
Conversely, depending on what limits are imposed it could introduce widespread breakage and actually stop some of the more creative uses of scripts that we see in builds today. Number of scripts are not usually the problem - it is what those scripts are doing that is in most cases the problem. Yes, this is my feeling. For example, I have a combat hud that has roughly 200 scripts in it. Most of these scripts aren't doing anything more than setting llSetText() on the Hud Interface, etc. I've measured the script time the HUD uses, and it averages around 0.3 mS, on par with most normal objects. Needless to say I won't be very pleased if it stops working because of some arbitrary limit on the number of scripts allowed. I"ve seen objects with 1 script use far more script time (as much as 3.0 mS). The fact is creators often have to resort to using more scripts than should be necessary simply to get around the self imposed limitations LL has forced on them. A script in every prim to set llSetText wouldn't be necessary if you could do that by link number, for example. So I am keen to hear the actual details of what is planned, but it seems the consensus is, nobody knows yet. :\ _____________________
|
|
Day Oh
Registered User
Join date: 3 Feb 2007
Posts: 1,257
|
06-24-2008 12:58
Yea it'd kinda make me sad seeing to see this happen before we could even make all linked prims move at the same time, stuff like that ;0
_____________________
 |
|
Ordinal Malaprop
really very ordinary
Join date: 9 Sep 2005
Posts: 4,607
|
06-24-2008 13:01
I wouldn't worry too much, nothing will happen.
Well, if something happens, it will be in the middle of the night, without warning or documentation, only tangentially related in the first place, and LL will either deny that it ever happened at all or say "oh didn't we tell you about that?" _____________________
http://ordinalmalaprop.com/forum/ - visit Ordinal's Scripting Colloquium for scripting discussion with actual working BBCode!
http://ordinalmalaprop.com/engine/ - An Engine Fit For My Proceeding, my Aethernet Journal http://www.flickr.com/groups/slgriefbuild/ - Second Life Griefbuild Digest, pictures of horrible ad griefing and land spam, and the naming of names |
|
Darien Caldwell
Registered User
Join date: 12 Oct 2006
Posts: 3,127
|
06-25-2008 12:03
hehe, well LL is now circulating a survey about what items they should work on next, and script limits is on the list, with a little more info:
1. Script Resource Limits: Ration script resources in a similar way to prim limits. Allow individual scripts to use all resources available in their current pool, rather than imposing arbitary limits on a per script basis. Each avatar is given a fixed size resource pool for scripted attachments and remaining resources are divided in to parcel pools based on land ownership. When all script resources in a pool have been consumed, no more scripted objects can be created using that pool. They still don't really talk about the size of the pool however. In a way it will be very inefficient, as large amounts of script resources could go underutilized. There's a lively debate about it on SLDev now. _____________________
|
|
Vampaerus Wysznik
bad lurker
Join date: 12 Apr 2008
Posts: 1,011
|
06-26-2008 02:04
the way that's worded, if a bunch of AVs storm your castle, your parcel scripts will come to a crawl. Seems the other way round was what was proposed earlier in this thread. The parcel quota should be dolled out first, then what's left divided amongst AVs. Or is there a reason it would be better to do AVs then parcel?
_____________________
Small scale web hosting for your SL or RL. Payable monthly in L$.
|
|
Haravikk Mistral
Registered User
Join date: 8 Oct 2005
Posts: 2,482
|
06-26-2008 04:21
Hmm, this is something I've been hoping for for a while, and if they can do it right it'll be great. I think the best system would be to give objects on land, and avatars a "guaranteed" slice of time to run their scripts in.
For example, let's say the scripting resources are divided up as 75% for land, and 25% for avatars/vehicles by default. If you own 1/4 of the simulator then you get a guaranteed allowance of up to 25% of the script time devoted to land (0.25 * 0.75 = 18.75% of total script time). This means if you need it you will be given that much script time, however, if you don't require it all then it will be given to others, but if you do suddenly need it again then it's yours. As a large land-holder you're entitled to that chunk of script time. This prevents the issue of a large land-holder being starved for script resources but a club on a small plot of land is hogging it all, which is starting to happen in the sim where my store is where I own over 6000 square metres of land, but small plots are wasting tons of script-time. My stuff isn't very demanding, but it's becoming less responsive as a result =( Similarly for avatars, if there are 10 avatars in the simulator, then you're entitled to a "guaranteed" 10% of the script resources allocated to avatars (2.5% of the total script time). Plots of land and avatars that under-utilise their share of resources have the excess "given away" to avatars or land that want more, however this is not guaranteed time and will be taken away if the under-utilising land/avatar suddenly requires more of its share. This is how I'd like to see the system working, it's currently possible to do this kind of thing with virtual machines in the context of web-hosting where you can get a "guaranteed" 200mhz of processing time from the server hosting your site, if you use less then it doesn't matter, and if you need more then you can get a chunk of excess processor time. I don't see why SL couldn't have this kind of system, as IMO it's the best way, but it is likely fairly complex to do, not necessarily in terms of system overhead, just in figuring out how to do it. There is a JIRA issue for this feature, but it hasn't seen much attention, it can be found at: http://jira.secondlife.com/browse/SVC-1245 _____________________
Computer (Mac Pro):
2 x Quad Core 3.2ghz Xeon 10gb DDR2 800mhz FB-DIMMS 4 x 750gb, 32mb cache hard-drives (RAID-0/striped) NVidia GeForce 8800GT (512mb) |
|
Tali Rosca
Plywood Whisperer
Join date: 6 Feb 2007
Posts: 767
|
06-26-2008 06:33
I am rather wary of the idea. I fear it will simply add additional bookkeeping, and result in end-user confusion as scripts start acting flaky based on obscure rules the average non-scripter is unlikely to educate themselves about.
There is also the general trend that the arbitrary limits in LSL tend to force people to make sub-optimal solutions to get around them, though I don't know if this would end up being such a case. On a tangent, and this may just be the areas I frequent, but pragmatically, it has never been the script time which has caused trouble when I've seen a sim pressed to it's knees, so the effort of making something "clever" here could perhaps be better used elsewhere. Hence, I gave this idea a low priority in the survey. |
|
Haravikk Mistral
Registered User
Join date: 8 Oct 2005
Posts: 2,482
|
06-26-2008 10:42
On a tangent, and this may just be the areas I frequent, but pragmatically, it has never been the script time which has caused trouble when I've seen a sim pressed to it's knees, so the effort of making something "clever" here could perhaps be better used elsewhere. Hence, I gave this idea a low priority in the survey. It's not really an issue of sims being brought to their knees, that's usually physics since scripts are throttled already, but more that one user can ruin script performance for everyone else by running a load of incredibly inefficient items on their land that they might not realise are laggy. I do agree that better tools to see which items are "laggy" is a good thing, but a system working to enforce limits on what a user can do to a simulator's performance is also important. _____________________
Computer (Mac Pro):
2 x Quad Core 3.2ghz Xeon 10gb DDR2 800mhz FB-DIMMS 4 x 750gb, 32mb cache hard-drives (RAID-0/striped) NVidia GeForce 8800GT (512mb) |
|
Argos Hawks
Eclectically Esoteric
Join date: 24 Jan 2007
Posts: 1,037
|
06-26-2008 10:51
I can see a real potential for a DISASTEROUS implementation of this. Right now, the sim's resources are split up among a lot of things other that scripts. A sim with no physical objects can run a lot more scripts than one with a lot of physics calculations. If you are going to divide up the amount of script processing, it seems to me like you would first have to allocate a subset of the total processor's capabilities to scripts. If you allotted have the processing power to scripts, current script heavy sims that have little else for the processor to do would break. You'd also break current physics heavy sims that have few scripts. And sims that are set up for large numbers of avatars while having very few scripts or physical items. Currently, the processor will work on everything, and only throttle scripts when needed. If you allocate processing power without knowing what the sim is actually trying to do, you could severely limit what can be done in a sim.
_____________________
Step 1: Create virtual world
Step 2: ??? Step 3: Profit |
|
Haravikk Mistral
Registered User
Join date: 8 Oct 2005
Posts: 2,482
|
06-26-2008 11:02
Argos I'm not sure that is an issue; scripts currently use up any time left-over from doing other things, if they try to use more then overall script performance is reduced/throttled. The result is that scripts usually get up to about 14ms of frame-time before all scripts start slowing down. If physics suddenly starts using more then script performance goes down till it finds a balance. The impression I got is that this new system would basically be sharing whatever time is available for scripts in a more intelligent/fairer way. So it'd be a way of slicing up the available chunk of time on a percentage basis, so it can vary with overall script time available.
_____________________
Computer (Mac Pro):
2 x Quad Core 3.2ghz Xeon 10gb DDR2 800mhz FB-DIMMS 4 x 750gb, 32mb cache hard-drives (RAID-0/striped) NVidia GeForce 8800GT (512mb) |
|
Argos Hawks
Eclectically Esoteric
Join date: 24 Jan 2007
Posts: 1,037
|
06-26-2008 11:04
Argos I'm not sure that is an issue; scripts currently use up any time left-over from doing other things, if they try to use more then overall script performance is reduced/throttled. The result is that scripts usually get up to about 14ms of frame-time before all scripts start slowing down. If physics suddenly starts using more then script performance goes down till it finds a balance. The impression I got is that this new system would basically be sharing whatever time is available for scripts in a more intelligent/fairer way. So it'd be a way of slicing up the available chunk of time on a percentage basis, so it can vary with overall script time available. If it's implemented in the way you've described, then it should be reasonably ok. I won't place any bets on what methods LL will use until they are done working on it and have announced what they've done. _____________________
Step 1: Create virtual world
Step 2: ??? Step 3: Profit |
|
Ciaran Laval
Mostly Harmless
Join date: 11 Mar 2007
Posts: 7,951
|
06-26-2008 11:15
Scrims! That's the name someone on the mailing list came up with.
I don't see how this is going to work from a resident point of view, you take your shiny new object home and it won't rez because it puts you over your scrim limit on that parcel. This has the potential to be a very big can of worms. Everything will need to be labelled for residents to understand what's going on, I think we're in "After the horse has bolted" territory here. Education, a long drawn out campaign of education would be better initially, and whilst that's going on they can get on with the more important issue of working on confirmation of delivery and transactions. |
|
Darien Caldwell
Registered User
Join date: 12 Oct 2006
Posts: 3,127
|
06-26-2008 12:27
Yes, there has been a lot of discussion about this on the Scripter's List, naturally, and it's still going on now. After reading the many, many comments by the remarkable Kelly Linden, I feel a lot better about what they are trying to do. Because of the complexity of it, I don't feel comfortable trying to condense, so here are the meatier comments by Kelly for you to peruse:
The limited resource case for CPU cycles is not a complete design at this point. The focus of thought and discussion has actually mostly been around memory usage. Even so the exact case of how a script gets more resource (more memory) is still not set in stone (do they need to ask for it, or just always get what they need?). For CPU cycles I suspect it to work extremely differently than stopping any scripts from running. Right now how scripts work is there is a fixed amount of time we run scripts each frame, if not all scripts were run that frame we pick up where we left off when it is time to run scripts next frame. So if lots of scripts are running and need lots of time it may take several frames for each script to get a chance to run. Given that, one possibility is to keep that model (highly likely) and then instead of 1 fixed amount of time to run scripts for the whole region, we divide that time up according to % of the region owned for the parcel the objects are over. On a parcel that covers half of a region they get half of the time to run. Now there is a lot of edge cases and fuzzyness here - what do we do if not all that time is used? We could just keep running those scripts again and again or we could let other scripts in the region go. There are lots of possibilities here, and I don't think any involve not letting scripts run. Avatars will have their own specific pool of resources, per avatar, for all their attachments. Those working will not depend on available resources for the parcels they are over. ----- Communicating to all residents the true resource cost of an object, in a way that is easily understandable and easily communicated, is indeed a hurdle, but it is one we need to address with or without the script resource project. Similar to how the rendering cost metric allows people to get insight into the actual load (on the client) of their avatar, we need to be able to see and understand that a single cube that uses 10mb of memory to run a complex vendor system is not the same as a single cube with a greeter script that takes a couple kilobytes of memory. In part the script resource project is about addressing this in as sane a way as possible. ----- If we think about that pattern in limited script resource world there are lots of options: * Give each pool its own time slice, apply the above pattern to all the scripts within a pool, each time slice. Keep running scripts in that pool until the time is up. or * Go through each pool with a maximum time to run scripts and have each pool attempt to run each script for a slice. If a pool finishes early move on to the next pool. If all pools finish early start again. Probably sort pools by size (largest first). This means if your pool is the only one with scripts you get all the time! However if the bigger pool has more scripts it will get more time. I think the first is your fear (strict enforcement of constraint), and the second is more ideal and still quite possible. Although maybe not your exact ideal. _____________________
|
|
Argos Hawks
Eclectically Esoteric
Join date: 24 Jan 2007
Posts: 1,037
|
06-26-2008 12:45
Thanks for posting that Darien. The way they are talking about doing things sounds pretty good.
_____________________
Step 1: Create virtual world
Step 2: ??? Step 3: Profit |