Babbage Linden - Limit scripts PER PARCEL

I wonder... is there any way to buy a clue as to how much memory a Mono script is actually using? Is llGetFreeMemory() even relevant, and if so, any less brain-damaged than it used to be?

I've got lots of scripts that fit tightly in LSL2--but they fit. I'm guessing they're filling up a lot of that 64KB under Mono, but I don't know how to measure that effectively. (I suppose I'll know eventually, come the day I can compile to a specific memory limit.)

It actually is kindofa big deal. Though I'm not sure I'd go for double the RAM, I think it's unlikely that they'd just slap another GB in there. No idea what these machines are like but they may not have any extra DIMM slots and/or have requirements on what they can put in there. There's also a probably-lengthly qualification process that they'd want to go through. And, of course, the act of physically installing the memory and testing that works on 5000 servers isn't trivial.

Would I love to see the whole grid get a memory boost? You bet!! I just think it's probably a pretty significant effort to make it happen..

Considering the manpower expense of upgrading hardware, I doubt they'd want to do it until they plan a significant increase, like rolling out class 6 servers. The cost of the memory is a small ticket item.

Whats wrong with LL are they complete idiots? first they are scamming people with this above adult relocation program to buy more land now they are scamming people with this limited memory BS! SL is already struggling its about to take a nose dive with these idiots at the helm. Anyone suggest a decent open sim? SL is about to die

I had a feeling this was coming.They started logging script use on avatars . Did they say how much the memory pool would be? I am sure they wont rape everyone too badly.Or will they?.
But when a user comes in a place with over 200 active scripts.. is a little over kill.. Times that by 40 and 80 users on a region and it pushes the active script level over the top

But then again they wouldn't have to do this if they didn't want to pack 4 full regions on 1 piece of hardware..

Do they think this will ease lag off regions?? I doubt it when an avatar is sporting 1,000 prims lol
When my region is full, I will disable scripts. and no performance change lol
Avatars prims use a lot more memory I think

Script limits will make SL better, not worse, by making it far more stable, and keeping us from shooting ourselves in the feet. It's a trigger guard that really should have been instituted long ago.

Currently SL allows us to run so many scripts we bog the server. They're putting a stop to that. This is a good thing. Yes, it will be a pain in the ass to adjust, but we will adjust, and SLife will be better as a result.

They haven't said how big the memory pools will be, because they need to gather data first. Furthermore, they're keeping us all in the loop throughout this process. They're really working very hard to do this one in the best possible way, and nobody among us has proposed a better plan.

If anyone can think of a better way, speak up now rather than waiting for them to complete the process and then complaining!

Dilbert, a server has 4 CPUs, so it does make sense to have it run 4 regions. Perhaps you think the regions should have been smaller? I think you'd get a lot of greif trying to suggest that, but that would be the only way to get more processing power per region.

Fortunately, hardware keeps getting faster. I'm looking forward to class 6 servers.

The biggest problem in a region is that we cram it with too much stuff (yes, including the avatar attachments -- no argument there!)

I believe LL when they say that there is a significant and demonstrable problem with thrashing caused by script memory overuse. It may not be happening in your sim, but it does happen and does need to be fixed.

I look forward to most scripting on LL grinding to a halt. Where has LL EVERY gotten anything right without 10 or 15 iterations and a huge amount of pushback from the players.

If LL follows form on this, it'll roll out with settings so low you'll be lucky to get llSay(0,"Hello World"; to run, then after a week or so denying there is a problem (remember their first fix to sculpty LOS? Where they were blobs unless you cammed damn near into them) and players screaming here and JIRA, they'll ratchet it up to let a few small scripts run, footdrag and deny, then increase it again and again. We'll end up with a (quasi) functional system maybe 3 months after they roll it out.

It SOUNDS like a good idea on paper, but to all the folks estatic about it I say 'be careful what you wish for'...With Lindens implementing it, I see far, far too many possible ways to screw it up and antagonize the players / hurt inworld business / break content. You know, SOP for the lab.

Lear 4 CPUs is pretty much worthless with only 2 gigs of ram. one region using 512? heh as memory runs out, you start to get CPU swapping.. It will look for more memory/processing from the other CPUs

These hosts need 4 gigs ..

They have 4G. Babbage said that each region gets about 800M of RAM. 800M*4 is 3.2G, and with OS overhead and the address space lost to the I/O page that's about as much as you would expect.

That would be all the stuff you never heard about, because it just worked. Not that they haven't goofed, but they've done lots right or there wouldn't be nearly so many of us in the grid all the time, pushing the system to its limits.

Even if they do the best possible job on this, they'll get a hailstorm of criticism, because it will be a change, and change causes upset.

Well, I remember when 64KB was a LOT of memory. But, I agree, we'll all be happier with more memory. Unfortunately, it'll require 64-bit OS and software, so a fair amount of that gain will get eaten up by bigger object code (at first, anyway).

However, there'll be a relatively unexpected gain, which Intel could have given us long ago. As it turns out, when you run a CPU in 64-bit mode, it gets more general purpose registers. The compilers take advantage of this and provide better optimization. (I suspect this helps dramatically for 64-bit floating point as well.) So, code that doesn't even need more memory often runs faster.

Hardware resources (processing power, memory, bandwidth) are the kind of things that no matter how much we have, we'll always want more.

The limits in themselves I don't mind so much, but if you "have to have enough free memory in the pool to rez the script", is that going to mean the script inside an object will be omitted (as in missing from contents) when rezzed? Just not allowed to run? or will the whole object refuse to rez along with the script?
Can see a lot of creators getting annoyed with cries of broken product when a product is not really broken.

The object will not be allowed to rez.

Thanks.. that would be better than the alternatives.

PRAISE THE LORD AND IT'S ABOUT TIME.

Now sim owners can have at least some type of control over thier sim and agents can't come in and suck down all the resources with thier attachments and scrits.

THANK YOU THANK YOU THANK YOU

When do we get object to object communication that's not in the clear (channels everyone can listen on)???

please?

Dear Lindens

I have a few questions for you which I hope you can answer in detail.

Question1: What should we sellers creators do when customers complain when your scripts changes cause our products to break and they want a refund? Will you pay them or explain to them that you caused the problems?

Question2: If these script land changes are so important as you say why have you not done before?

Question3: Many people are cynical and think you only want people to buy more land - is it really all about money to you?

Question4: How many people do you expect to cancel their accounts ?

Question5: What about new accounts and people with only 512 sqm of land - any ideas on how many scripts they will support.

Question6: Script memory is a bad guide to the lag generated by a script - one with many Listens can be very laggy - instead why not restrict a user's time slices?

Qustion 7: How do you think the builders and scripters will react when they've invested so much time on their job and you break it, do you think they get upset?

They already do. The problem they are trying to solve right now is caused by script memory use.

Yeh those are memory leachers ...

Can everyone else in the sim get a refund from "sellers creators" when they discover your product is in the top 1% for memory usage and has been lagging the sim for all these years?

I know LL has a history of representing a plan one way and implementing it another but all the details we have right now indicate that this is absolutely the right move to prevent script abuse.

Yes, it's a bitch. Change causes upset. Remedies are better taken sooner rather than later, so why not do this now rather than years from now?

If LL had done this a year ago, your objection of "why have you not done [it] before" would have been just as valid then, and just as beside the point as it is now. (The obvious answer is, "We should have, but we were busy with what we thought were more important things."

Yes, this is going to be a hassle, but it's a necessary one, unless you love lag. Script abuse has grown significantly in the last couple years, unfortunately. Rolling out faster servers would only encourage more abuse.

You have lots of pointed critical quesitons. What would you recommend to solve the problem? If you have a better solution, we'd love to hear it.

I wish people wouldn't refer to scripts that use a lot of memory as "script abuse". Yes, it's a problem, and scripts need to be limited, and SOME people have been really careless about memory use... but demonizing them by using terms like "script abuse" is probably not helpful.

Memory usage doesn't necessarily equate with lag.

I write chess computers in sl and half a dozen can be playing at once with very little script lag. Yet some simple scripts with lots of Listens and a very small memory footprint can severly lag a sim.

What you should do is say the following to your customers:

"The product broke because of my poor scripting skills. I did not code that product in the most efficient manner possible, and it consumed far more memory than it needed to. I made a mistake, I am in the process of fixing the product to make the scripts more efficient, and I will give you all free updgrades when I do so."

And then you should do exactly that, updgrade the product to be more efficient and send copies to your previous customers.










Many people are still capable of thinking ridiculous things. But to answer your question, the fact that they're considering per-avatar script memory limits as well ought to tell you that this isn't just about land.






If this does, by some chance, force hundreds of incompetent, inefficient scripters to cancel their accounts because they are incapable of scripting an object that does not drag a sim to its knees, I will dance in drunken naked revelry through every single sim in SL.

However, I highly doubt that this will happen. Instead, these incompetent scripters will blame LL for their inability to code efficiently.







You are correct that there is far more to script-generated lag than just memory usage. Scripts can cause lag when they consume too much processing power as well....although believe it or not, listens are not the biggest sim-killer. Linked-message communications between large numbers of scripts can be far worse than listens, for the simple reason that they can generate far more script events than listens would.

Limitations based upon EPS or script time (preferably EPS, in my opinion) would also be welcome. However, understand that this would be done to solve a different problem than the one being addressed here. While scripts that cause excessive processing load are probably a more common cause of lag than excessive memory use, the consequences of excessive memory use can be far worse, especially since they extend across all regions running on the server. Thus, memory probably does need to be dealt with first.

Additionally, limitations on EPS or script time would break many objects as well. Now, my personal opinion is that these objects are already broken...after all, they're incredibly inefficient if they're overusing these resources....but it is important to remember that those limitations would damage content as well.






Most of the scripters I know are ecstatic about this upcoming change. Sure, we're a bit cautious and concerned that it might not be implemented correctly, or that there might be some bug that causes these limits to operate incorrectly or that the limits might accidentally be set far too low. However, if these new limits are implemented correctly and in the manner that has been discussed so far, this sounds like a very good things,and most scripters should be quite happy about it.

Granted, some scripters will be pissed off. These are the scripters who find it necessary to put color-change scripts into all 200 prims of a shoe or hair, rather than using llSetLinkColor() in a single script in the root prim. These are people who probably should not be scripting. I'm sorry, it had to be said.


If these proposed limits encourage scripters to code as efficiently as possible, then it will be very good thing.

Isn't SL just like a host provider on the "internets"? LL is the host provider renting space on a server.

So why not pay for what you use in SL just like you would if you rented part (or all) of a server to host your website(s)? If your website is hogging the resources of the server it shares with others, you get charged more. You either correct your design or pay for what you're using. Or find another host.

This is definitely a good move on LL's part. Bravo.

Well, no, actually they can't. If they're completely unfiltered channel 0 listens, each such listen() event will get a little bit of processing each time somebody speaks in open chat. Otherwise llListen is just another event handler, exactly like all the others.

And right now, extensive memory usage *does* equal lag, even if event processing is very infrequent. Servers are thrashing because of script memory usage, and lagging every sim hosted on that server. So even if lag seems acceptable for a sim with chess computers on it, they may be causing rubber-banding on three other sims that share that server.

But all that is not to say there was something wrong with scripting with a large memory footprint before this problem surfaced. As Argent says, "script abuse" is not often a justified term. Scripters just optimized to a model that no longer applies: pre-Mono, one could quite responsibly burn memory to achieve performance, because performance was incredibly dear; now that trade-off has shifted very far toward needing to conserve memory.