During an Office Hours discussion, Babbage Linden laid out what appears to be the future for managing scripts in SL. From this and other discussions, it is evident that the issue has been causing concern within Linden Lab for some time now, and was likely to have been the kick-off point for the recent OpenSpace sim debacle – even if they opted to “leverage” that situation for different purposes…
In a nutshell, and bearing in mind I’m not a techie – the problem is that there is obviously finite memory available on each server that runs SL sims (4 sims per server in the case of “full” island sims; 16 in the case of the current OpenSpace sims). This means that each sim gets around 800Mb of memory in which to run residents’ scripts. Up until now, if there are more scripts on a sim than available memory, the sim has “swapped” memory with the other sims on the server in order to meet the needs of all the scripts it has running.
While this hasn’t been a “major” problem in the past, it has impacted performance (lag). However, because we are all natural script hogs (in the same way we are all prim hogs), the memory swapping situation is approaching epidemic proportions and seriously impacting overall grid performance. Thus, it is fairly evident something must be done.
Linden Lab’s preferred approach to solving this problem is to allocate memory space to sims in much the same way as prims are currently allocated: a finite amount of memory is “given” with the sim, and (like prims) this is divided across the sim in accordance with how the sim is parcelled. Therefore, if you own a sim and divide it into two parcels, each parcel gets roughly 50% of the memory space available to the sim. Divide the sim into 4 parcels, and each parcel gets roughly 1/4 of the memory allocation…and so on.
I say roughly, because at the same time, a “resource pool” on each sim is set aside for Avatars that will enable all the myraid of in-world attachments we all tend to carry around to work.
On the surface, both of these apporaches do actually seem reasonable, although it has to be said – as in the comments given by those quoted in the extracts published by Dari – that there are potentially better solutions. Further, this whole idea raises a plethora of questions, many of which LL have yet to answer – of which by far the most important is how will user awareness be handled?
Right now, we all expect that, no matter what we purchase, when we get it home, it will work. OK, so sometimes it may run a little slowly, but it will work. With the new limitations, this will no longer be the case…if you’re on a 1024 sq m parcel and your new left-hand widget wongler takes you over your resource allocation it won’t work until you sort out which items you currently have rezzed must be returned to your Inventory in order to “make room” for the widget wongler….
It gets worse. Prims are relatively easy to understand. They are finite units, irrespective of their relative size. Thus a prim is a prim whether it is 0.5 x 0.5 x 0.5 or 10 x10 10. Scripts (in terms of memory use are not. Some scripts run in a few Kb of memory space, other require the (current) maximum of 64Kb (thus gobbling more memory). Therefore, thus judging whether the next purchase will work at home or require other things get “put away” to “make room” for it is not simply a matter of counting the number of scripts it contains…
And what about those already exceeding the (currently unspecified) limits on resources? The day before the caps are implemented, they’ll see everything running fine. The day after, there is a good chance they’ll find things are not working at all, leading to a potential outcry as beloved household items suddenly have to returned to Inventory or swapped back and forth with other items, thus making a mockery of having a “home” (when was the last time you had to put the sofa into storage to make way for the television set in rl?).
Unless communications prior to the event are handled clearly and passed to ALL members of the SL community, there is a danger that those getting lambasted for perceived failures with objects will not be Linden Lab….but the creators of the objects themselves. This would be grossly unfair on content creators.
There are many other questions that need to be addressed on the issue – how will protected land work for example (particularly where it is protected to provide prim bonuses to other parcels – will the memory allocation be available to provide a similar “memory bonus”); how will malls work, if memory is not only tied to land size, but land ownership?
Then there is the potential impact of the “resource pool” for Avatars. Again, at the moment it makes no difference memory-wise as to how many agents (Avatars) are on a sim – the CPU will simply start memory-swapping to accommodate until the nominal Agent Limit is reached. Practically this does mean that where the limit is being approached, things get bad on the sim in terms of lag (and on the other 4 sims sharing the server for than matter).
While a resource pool may prevent the latter problem of the other 3 sims on a server being impacted, the fact that resources available to Avatars will be capped means that the numbers of Avatars able to enter popular venues in future could be seriously impacted: get a dozen Avatars on-sim blinged up to their eyeballs, all wearing (God-awful) “clickety” shoes and scripted hair with Chimeras attached to heads / shoulders / butts, as well as two or three other “heavy” attachments – and one can see a sim’s “pool” of Avatar resources quickly drying up, with the result that while others may be able to Tp into a sim, they’ll find that “nothing works” when they get there.
No-one can doubt that when we have finite resources available to all of us, then something must be done to ensure those resources are fairly managed and distributed – and that the reasons for such controls, how they will work and what it will mean to SL users is clearly communicated. Further, it is also necessary to ensure that reasonable tools / facilities are put in place to enable people to husband their available resources wisely.
But given LL’s inability to keep its left hand informed about what its right hand is doing, let alone actually communcate with its user base clearly, concisely and openly, can we really believe they’ll shoulder the responsibilities inherent in introducing such fundamental changes to SL wisely or constructively?
If things do go in this direction, then I, for one, will not be holding my breath.