[Opensim-dev] New Opensim features and minimum hosting hardware requirements

[Melanie]

I am actually planning on making things like the AO's fast timers 
superfluous. XEngine uses timer even coalescing to prevent the 
script from queuing up more events that can be processed, e.g. 0.1s 
timers. From observation, SL does the same, not guaranteeing that a 
timer event will run after the time set, and also not guaranteeing 
that a timer of 0.1s will result in 10 events per second. In 
practice it results in more like 5.

Shutting down scripts in unoccupied regions would be 
counterproductive in 99% of the cases. I'm not saying that some 
might not wish it, but I believe the majority will not. Sure, some 
scripts do stupid things, like texture cycling. But other scripts 
are never run again after the initial event anyway (prim rotation 
and texture animation come to mind), and many are avatar event 
driven (doors) and don't do anything without avatar action.
Those, however, which do things, usually need to.
Vendor networks would break apart and cease to function of a region 
has no avatars in it for a full day and scripts were disabled 
because of that.
Anything using email would lose it's email, as that queue can't be 
allowed to grow arbitrarily large, and the assumption from SL is 
that email is 100% reliable.
Vendor servers would stop delivering items.
There are probably many more things I can think of.

As for attachments, the client already provides a per-parcel setting 
which prevents scripts from running. This also applies to 
attachments, except those scripts that have taken an agent's 
controls. Blocking those may render the agent unable to move, 
therefore they are allowed to continue.

That seems to cover most common use cases. Additionally, I have 
written a scripting permissions module, which allows to restrict 
scripting in a region to certain users,and I am looking into an ACL 
system that would, in the first step, limit the languages a user can 
use. In the next steps, it may introduce per user script limits, or 
per user time-quantums.

So, you're not alone with your concerns, but the brute force 
shut-down approach is likely not going to fit most people's bill.

Melanie


Dahlia Trimble wrote:
> On Thu, Aug 21, 2008 at 6:45 PM, Mike Mazur <mmazur at gmail.com> wrote:
> 
>> Hi,
>>
>> On Thu, 21 Aug 2008 16:08:25 -0700
>> "Dahlia Trimble" <dahliatrimble at gmail.com> wrote:
>>
>> > [Comments about OpenSim performance vs hardware vs scripting features]
>> >
>> > While I've enjoyed being able to host several OSGrid regions on
>> > minimal hardware up until now, I may have to ration what new features
>> > are available in my regions or consider upgrading to more capable
>> > hardware. I have the feeling others will also, and I suspect that the
>> > prices some of the grid operators are offering will need to rise
>> > unless they can successfully ration features as well.
>>
>> I agree with your concerns. Naturally as more demanding features are
>> added and used, this will push hardware utilization limits.
>>
>> Are you suggesting a system for limiting the items below?
>>
> 
> Possibly, and I believe some controls exist already in the land options. I
> was more interested in initiating conversation about the hidden costs and
> usefulness of these features and how so much development effort seems to be
> going towards making sure everything is 100% SL compatible without regard to
> the hidden costs. I realize 100%  compatibility is important to some and I
> don't want to discourage it, especially if the code is being shared with the
> rest of the community. What I personally don't want to see is an expectation
> by anyone who teleports to every region that all their high resource
> demanding (and possibly frivilous) attachments have to be supported at the
> expense of the region owner. Currently the SL model *cannot* prevent
> attachments from using resources no matter what the wishes of the region
> owner may be, other than banning avatars. Along the same lines, an
> expectation that scripts will continue to run when the region is not
> occupied could also raise the expense of operating the region.
> 
> Given the increasing popularity of Opensim and the rate at which these
> features are being implemented, I think now may be a good time to address
> some of these concerns and also to attempt to influence user expectations if
> some alternatives may provide a better experience at a lower cost.
> 
> 
> 
>>
>> > * How many scripts are continuously running in a region
>> >
>> > * How many scripts an avatar is allowed to have in attachments and
>> > how often they do expensive operations
>> >
>> > * How many prims are in a region and how complex they are
>>
>> I'm sure such a system would be beneficial. Besides the performance
>> considerations, it would also grant region owners pretty fine grained
>> control over what they allow or disallow to occur in their regions.
>> That could be very useful.
>>
>> (A real-life example of giving region owners control over their region
>> that comes to mind is giving cinemas the ability to block mobile phones
>> in the theater.)
>>
>> Mike
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev