Script limits per parcel, and per total attachments, may be in the pipeline

You know, I'm not a big scripter. I can make a box say "Hi Avatarrrrrr" but thats it . For me, alot of the changes I have heard about coming up, or have been here to witness myself(in SL since 09/06) I have either hated, or just got used to them.

This whole limiting scripts and stuff I think is going to be a good change. I honestly don't think they're gonna make this limit so harsh that you can't even wear one ugly blinging boot. I heard through the grapevine, or here they're putting a 255prim per body part limit. If thats the case I tend to think personally the limit on scripts and usage is going to be fair also.

I saw a few people in here talk about the Top Guns of scripting and I agree. This should help clean out the people that walk out their backdoor, cut through the neighbors yard, around the block, just to get their mail...instead of walking out the front door to get it.

I also heard through the grapevine the Lindens are looking to get some high powered full of knowledge outside help to spiff SL up....finally!...finally!!!!!!!!!!

Oh, last thing, please, please, destroy bling scripts

And you think that's a reasonable limit? o_O

Despite that I suspect I'll get hit due to MLPV2, I see this as a good development, avoiding the tragedy of the commons regarding memory.

As mentioned above, it won't solve the tragedy of the commons regarding script CPU time: if someone uses cpu-intensive scripts, it'll still slow down all the other scripts in the region. Noted, that's not nearly as bad as causing the server to thrash, affecting all aspects of SL in 4 regions.

One resident shouldn't be able to hog all the sim's resources and force it into a state where it's totally bogged, which is the current state of affairs. The least LL must do is to limit total script memory per region, but that would still allow one resident to hog all the script memory.

Sure, it's going to cause us problems. But these are problems we need to face. Rather than whine about it, we need to help LL identify forseeable problems. A few have been mentioned on another thread about this issue:



Since it's generally best to discuss a subject in a single thread, I recommend folks use that one.

That's always been the limit. At least, since Oct 2006 when I joined. You can't link more than 255 prims, and you therefore can't wear more than 255 prims per attach point.

Now, if they are going to limit it to 255 prims per *full avatar*, that would be news.

I'm curious on if this will really help "lag" as they are calling it. From what I've read and know, it seems to be more about cpu cycles then about memory. Granted page filing would definatly slow something down, but is that REALLY the problem with laggy sims, or is it that scripts are dominating cpu cycles?

We all say the same thing, sensor's are a hard hit on a sim, but they aren't memory intensive, compared to the cpu usage for them. I would think that looking into how much a script is computating would lead to less lag then it's memory.

I could be totally off base, and if so, let me know. Also, will we get information on exactly how much memory is used for each event call, each function call, if a function passes a variable by reference or not?

I like this idea of theirs, but I worry about not knowing how to best effectively implement on the creators end. Like llListFindList, which I think passes by reference, but does llListReplaceList, it would just be nice to get more info on the internal workings of the provided LL functions.

As I understand it, this is intended to deal with the case where sims start thrashing, and all four sims on a server become inexplicably laggy.

One I'm curious about... as I understanding, bytecode-identical Mono-compiled scripts only keep one instance in RAM. So, does this mean additional instances of the same script will not require extra script memory (presuming that there are no expanding lists, etc.), or will we get dinged for each copy even though it's not hitting the server? Or do I not get this at all?

Scripts are already throttled for cpu cycles, actually scripts are bottom of the pile server wise with textures, physics and everything else having priority. Take a look at ms Time. If you read both of Babbage's transcripts then yes, this is a really bad problem, especially since it is a shared resource. It would be bad enough on full sims with just 4 being affected but I could see it being disastrous for something like OS with 16 on a core. I was just wondering to myself last night if this is what was the actual root cause for the change in the OS policy and if it could have been averted by implementing this at that time.

With the upcoming UI change showing how much memory is used by a script or object (not clear on this until it is released) it would be easy enough to work backward to see what is using memory, function or process wise. I know I will probably spend a couple hundred hours in Aditi once the UI hits there.

Only code space, not data/stack/heap space, is shared between instances of a script with the same key (copies of a script compiled once). So your variables, list or not, are always copied. Otherwise you'd have a problem.

one question i have, is this grid wide, or only linden owned land?

Right: according to Babbage, with script memory unbounded, it can cause scripts to use so much memory that the servers "thrash", which is too-frequenty swapping between CPU memory and disc cache. When this happens, we get all kinds of nasty lag. Something does indeed need to be done.

Grid-wide. One possibility for escape from this would be if a private owner owns all 4 regions on a server, they might be allowed to disable it (but I wouldn't hold my breath hoping for that). Alternatively, an estate manager might be able to disable per-parcel limits, but be held to the equivalent per-region limit. Again, I wouldn't hold my breath on that.

Babbage did say that it would work just like prim limits in that you'd get an amount related to your region size.

You mean parcel size?

If it's exactly proportional to parcel size, without allowing overcommitment, then either the limits on sub-512 parcels are going to be ridiculously low, or the region limits are going to be too high to be effective.

/327/d5/312790/5.html#post2365334

Referencing the post you linked, 256mb for scripts isn't unreasonable, in fact I would expect more. You have to keep in mind, there will also be some script memory set aside for avatars visiting the sim, who don't own land at all there.

According to Babbage, the TOTAL memory available for the sim's working set is only 800M. 256M is almost 1/3 of that.

of course if the rest is strictly av's (assume max load of 40, even though some sims have higher limits), that leaves 13.6M per AV.... then again, how many 512 plots are in a sim? I'm to lazy to do the math.

Um, no, that 800M includes all the rest of the simulator software, including the web cache, physics engine, playing pass-the-parcel with llEmail and llHTTP and avatars and groups and the sim next door, all the prims in the sim, the whole ball of wax. And for OpenSpaces, the overhead is proportionally even higher.

Understood, Hewee, but my variables are usually pretty small compared to my bytecode. So the question remains if I'll get dinged twice for the bytecode.

True. That IS a good question.


I don't see this as a necessary solution to that problem. If they know a lot of disk paging is occuring, then they should focus on a strategy that will limit the lag to scripts alone. They should manage more of the disk access themselves and implement a threading model that will put scripts needing data from disk on a wait queue. That'll cut down on overall server lag but lag the scripts that are causing the problem without just cutting them off and possibly clipping out important user functionality without giving the owner the chance to intercede.

This would require either implementing a capability based operating system (such as the Burroughs design from the '60s, or following the path of Intel's failed iApx32), or emulating paging in the application similarly to the way Photoshop did on Mac OS in the '90s (with accompanying performance issues and embarassing OS dependencies that led to them engaging in brinksmanship with Apple that held up the release of Rhapsody/OSX for 2-3 years).

No, let's not. The wheel might have a few bumps in it, but at least it's round.

I disagree. Remember that we're talking about a virtual machine here, with plenty of application-level hooks. There are lots of solutions that require neither OS-level support nor hugely over-engineered manual memory allocation schemes.

It's a just-in-time compiled virtual machine that Babbage has already wrought miracles on. I've written real-time interpreters and added the hooks to dynamically compiled database engine (one where we took the table schema and generated table-specific C code to speed up access) to support lockless shared memory, and I'm impressed with what he's done so far. I didn't think he could get Mono to be even as real-time as it is. Putting in all the checkpoints necessary to do software virtual memory would cut the performance of the scripting engine by at least a binary order of magnitude, and possibly a decimal order of magnitude.

There's a REASON we're using the philosophical descendants of Honeywell/GE Multics, and not Burroughs MCP.

whoops, misread.

Are you sure he didn't mean 800 was what was left *after* accounting for the services running? Traditionally software running under *nix are pretty small. I lease a webhost and after accounting for 6 instances of Apache, 1 instance of php, several POP/IMAP servers, SendMail, and a whole slew of other little bits, it only uses about 150Meg of memory. Considering LL's server is running of a modified version of Apache 2, I would assume it's just as small. Most of the memory would be used for Scripts/Objects/Avatars it would seem to me.

If not, what is using up that 200 meg? Shouldn't each host have 1 gig on a 4 gig machine?

I did the same calculations earlier and came to about the same results as Babbage.

These servers have 4GB of RAM. Of that, 256M to 512M is taken up by the I/O page. That leaves 3.5GB. The kernel and various daemons, and a reasonable allowance for the buffer cache (SL is memory *and* disk intensive), can easily be another half a gig. That leaves 3-3.5G free.

800M * 4 = 3.2GB. Right in the middle.
Slacker! I ran 2 instances of Apache, qmail, listserv, and four MUDs in 4M of RAM on a 486!