Script/Parcel/Memory Limits

[Stickman]

I don't know what the official name is, but it's either Parcel Limits,
Script Limits, or Memory Limits.

It's been a while since I've heard any official word about it. Last I
did hear, LL was gathering statistics and didn't know exactly how they
were going to implement it, let alone what the limits would be.

Has LL made any decisions, and would they be willing to share them?
More minds on the issue can spot any holes or problems that could
arise, and there's still some rumbling panic among the masses that
can't be confirmed or quelled since we don't know how it'll work.

Many thanks,

Stickman

[Ziggy Puff]

I was about to post a question on this as well - my wife heard about
that blog post (it's spreading pretty quickly among content creators, I
think) and so I took a look. I found some good info in 3 or 4 of Babbage
Linden's office hour chat logs. More details on the exact algorithms
would be very helpful. Some questions I had after going through the
material I could find:

* Is each script 'charged' 16K/64K, or just what it's using? Is the
check made on rez / parcel change, or periodically? Maybe this is a
meaningless question, but I thought Mono scripts could scale their
memory footprint up and down, in which case a script could have a small
footprint when it's rezzed.

* Avatar / attachment pool vs. parcel pool - if an av's pool runs out,
does an attachment try to take memory from the parcel pool?

* The GUI support for reporting script memory usage - will it show the
footprint of individual objects, like the 'Top Scripts' window? How
about individual attachments? I imagine the last object that would go
over the threshold will be the one that's not allowed to rez, but that
probably won't be the least efficiently scripted item the person is wearing.

Ziggy

Stickman wrote:
> I don't know what the official name is, but it's either Parcel Limits,
> Script Limits, or Memory Limits.
>
> It's been a while since I've heard any official word about it. Last I
> did hear, LL was gathering statistics and didn't know exactly how they
> were going to implement it, let alone what the limits would be.
>
> Has LL made any decisions, and would they be willing to share them?
> More minds on the issue can spot any holes or problems that could
> arise, and there's still some rumbling panic among the masses that
> can't be confirmed or quelled since we don't know how it'll work.
>
> Many thanks,
>
> Stickman
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting privileges
>
>
>

[Stickman]

Ping.

The comfort or early warning I expect is that we're going to get
better tools to see behind the scenes on scripts before the limits
actually show up. My fear is that it's going to be right when midterms
crop up and have a two week window to rewrite every script I've ever
written.

Can any Lindens on this project provide any information, or point us
to a magical page on the wiki that explains this? Or, at the very
least, give us a rough timetable so we know about what time is
appropriate to begin our panicked search for information?

Thanks much!

Stickman

On Sat, Dec 12, 2009 at 10:43 PM, Ziggy Puff <ziggy-***@public.gmane.org> wrote:
> I was about to post a question on this as well - my wife heard about that
> blog post (it's spreading pretty quickly among content creators, I think)
> and so I took a look. I found some good info in 3 or 4 of Babbage Linden's
> office hour chat logs. More details on the exact algorithms would be very
> helpful. Some questions I had after going through the material I could find:
>
> * Is each script 'charged' 16K/64K, or just what it's using? Is the check
> made on rez / parcel change, or periodically? Maybe this is a meaningless
> question, but I thought Mono scripts could scale their memory footprint up
> and down, in which case a script could have a small footprint when it's
> rezzed.
>
> * Avatar / attachment pool vs. parcel pool - if an av's pool runs out, does
> an attachment try to take memory from the parcel pool?
>
> * The GUI support for reporting script memory usage - will it show the
> footprint of individual objects, like the 'Top Scripts' window? How about
> individual attachments? I imagine the last object that would go over the
> threshold will be the one that's not allowed to rez, but that probably won't
> be the least efficiently scripted item the person is wearing.
>
> Ziggy
>
> Stickman wrote:
>>
>> I don't know what the official name is, but it's either Parcel Limits,
>> Script Limits, or Memory Limits.
>>
>> It's been a while since I've heard any official word about it. Last I
>> did hear, LL was gathering statistics and didn't know exactly how they
>> were going to implement it, let alone what the limits would be.
>>
>> Has LL made any decisions, and would they be willing to share them?
>> More minds on the issue can spot any holes or problems that could
>> arise, and there's still some rumbling panic among the masses that
>> can't be confirmed or quelled since we don't know how it'll work.
>>
>> Many thanks,
>>
>> Stickman
>> _______________________________________________
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/SLDev
>> Please read the policies before posting to keep unmoderated posting
>> privileges
>>
>>
>>
>
>
>

[Tigro Spottystripes]

Btw, will unfit script just not run or will the objects they are in
actually become unrezzable making scripts unfixable even by the creators?

Stickman escreveu:
> Ping.
>
> The comfort or early warning I expect is that we're going to get
> better tools to see behind the scenes on scripts before the limits
> actually show up. My fear is that it's going to be right when midterms
> crop up and have a two week window to rewrite every script I've ever
> written.
>
> Can any Lindens on this project provide any information, or point us
> to a magical page on the wiki that explains this? Or, at the very
> least, give us a rough timetable so we know about what time is
> appropriate to begin our panicked search for information?
>
> Thanks much!
>
> Stickman
>
> On Sat, Dec 12, 2009 at 10:43 PM, Ziggy Puff <ziggy-***@public.gmane.org> wrote:
>
>> I was about to post a question on this as well - my wife heard about that
>> blog post (it's spreading pretty quickly among content creators, I think)
>> and so I took a look. I found some good info in 3 or 4 of Babbage Linden's
>> office hour chat logs. More details on the exact algorithms would be very
>> helpful. Some questions I had after going through the material I could find:
>>
>> * Is each script 'charged' 16K/64K, or just what it's using? Is the check
>> made on rez / parcel change, or periodically? Maybe this is a meaningless
>> question, but I thought Mono scripts could scale their memory footprint up
>> and down, in which case a script could have a small footprint when it's
>> rezzed.
>>
>> * Avatar / attachment pool vs. parcel pool - if an av's pool runs out, does
>> an attachment try to take memory from the parcel pool?
>>
>> * The GUI support for reporting script memory usage - will it show the
>> footprint of individual objects, like the 'Top Scripts' window? How about
>> individual attachments? I imagine the last object that would go over the
>> threshold will be the one that's not allowed to rez, but that probably won't
>> be the least efficiently scripted item the person is wearing.
>>
>> Ziggy
>>
>> Stickman wrote:
>>
>>> I don't know what the official name is, but it's either Parcel Limits,
>>> Script Limits, or Memory Limits.
>>>
>>> It's been a while since I've heard any official word about it. Last I
>>> did hear, LL was gathering statistics and didn't know exactly how they
>>> were going to implement it, let alone what the limits would be.
>>>
>>> Has LL made any decisions, and would they be willing to share them?
>>> More minds on the issue can spot any holes or problems that could
>>> arise, and there's still some rumbling panic among the masses that
>>> can't be confirmed or quelled since we don't know how it'll work.
>>>
>>> Many thanks,
>>>
>>> Stickman
>>> _______________________________________________
>>> Policies and (un)subscribe information available here:
>>> http://wiki.secondlife.com/wiki/SLDev
>>> Please read the policies before posting to keep unmoderated posting
>>> privileges
>>>
>>>
>>>
>>>
>>
>>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting privileges
>
>

[Robert Martin]

On Tue, Dec 15, 2009 at 8:10 PM, Tigro Spottystripes
<tigrospottystripes-***@public.gmane.org> wrote:
> Btw, will unfit script just not run or will the objects they are in
> actually become unrezzable making scripts unfixable even by the creators?
>
what should happen is that some sort of precheck is done and the
object is not rezzed (or is rezzed with all scripts stopped) since
some objects will be horribly broken by some scripts not running an
example would be some anthro/Quad parts
--
Robert L Martin

[Tigro Spottystripes]

Not rezzing at all would be the worse solution possible (perhaps only
less worse than automaticly deleting the items in the inventory)


Robert Martin escreveu:
> On Tue, Dec 15, 2009 at 8:10 PM, Tigro Spottystripes
> <tigrospottystripes-***@public.gmane.org> wrote:
>
>> Btw, will unfit script just not run or will the objects they are in
>> actually become unrezzable making scripts unfixable even by the creators?
>>
>>
> what should happen is that some sort of precheck is done and the
> object is not rezzed (or is rezzed with all scripts stopped) since
> some objects will be horribly broken by some scripts not running an
> example would be some anthro/Quad parts
>

[Argent Stonecutter]

The object won't rez if the parcel you're in already has too many
scripts in it.

You would still be able to rez the object in a sandbox.

It is unlikely that you would have a problem unless you had hundreds
of scripts.

[Tillie Ariantho]

On 16.12.2009 14:43, Argent Stonecutter wrote:

> The object won't rez if the parcel you're in already has too many
> scripts in it.
>
> You would still be able to rez the object in a sandbox.
>
> It is unlikely that you would have a problem unless you had hundreds
> of scripts.

Scripted hair, scripted shoes ... fashion shows will be a mess. ;-)

Tillie

[Jesse Barnett]

On Wed, Dec 16, 2009 at 8:49 AM, Tillie Ariantho <tillie-nWP5+***@public.gmane.org> wrote:

>
> Scripted hair, scripted shoes ... fashion shows will be a mess. ;-)
>
> Tillie
>

Which is kind of the point and one of the main reasons this is having to be
implemented.

Jesse Barnett

[Carlo Wood]

On Wed, Dec 16, 2009 at 08:56:15AM -0500, Jesse Barnett wrote:
> Scripted hair, scripted shoes ... fashion shows will be a mess. ;-)
> Tillie
>
> Which is kind of the point and one of the main reasons this is having to be
> implemented.
>
> Jesse Barnett

Huh?

I thought the reason was to stop regions bogging down due to swapping.
Now the main reason is to cripple fashion shows? The very fact that those
fashion shows worked before means that there is something majorly
wrong with an implementation that make that NORMAL use of scripts
suddenly a worse experience.

If the server HAS the resources to do something before, then it should
not suddenly become impossible.

--
Carlo Wood <carlo-A8X2UORpUyHQT0dZR+***@public.gmane.org>

[Jesse Barnett]

Normal use of scripts are not affected. Hair and shoes with several hundred
scripts per avatar is what I am specifically referring to and should not be
considered "normal use". Go back and look at Babbage's meeting minutes to
see some of the outrageous script abuse going on.

[Laurence Brickner]

Something about "Where Angels Fear to Tread" comes to mind but.



As a community, we have become very tolerant of poor performance. I have
often heard the sarcasm "Lag is always with us." I wondered why. The
assertion that things are working right now isn't true. "Things" fall apart
often and that should be unacceptable. Truth is we often find ourselves on
the precipice.



So I see this as an attempt to do something before "Things" turn brown.
What can be wrong with that? The most likely outcome will be that we will
become accustomed to a better grade of system performance.



Let's not fight them. Let's help.



Shorahmin/Larry





_____

From: sldev-bounces-nHFbR+4dATNruOA+hsvTn1aTQe2KTcn/@public.gmane.org
[mailto:sldev-bounces-nHFbR+4dATNruOA+hsvTn1aTQe2KTcn/@public.gmane.org] On Behalf Of Jesse Barnett
Sent: Wednesday, December 16, 2009 10:36
To: Carlo Wood
Cc: sldev-nHFbR+4dATNruOA+hsvTn1aTQe2KTcn/@public.gmane.org
Subject: Re: [sldev] Script/Parcel/Memory Limits



Normal use of scripts are not affected. Hair and shoes with several hundred
scripts per avatar is what I am specifically referring to and should not be
considered "normal use". Go back and look at Babbage's meeting minutes to
see some of the outrageous script abuse going on.

[Carlo Wood]

On Wed, Dec 16, 2009 at 10:36:26AM -0500, Jesse Barnett wrote:
> Normal use of scripts are not affected. Hair and shoes with several hundred
> scripts per avatar is what I am specifically referring to and should not be
> considered "normal use". Go back and look at Babbage's meeting minutes to see
> some of the outrageous script abuse going on.

Normal use WILL be affected, because before you see no limits
until the server actually runs out of memory.

Now you will be limited long long long before the server actually
runs out of memory, because the server has to keep like 90% of
memory "in reserve" to serve the worst case of a full load on
all parcels happening and suddenly the maximum number of avatars
joining.

The mantra "Normal use of scripts are not affected" is a lie,
and it's easy to deduce why that must be the case. The way that
normal use of scripts would not be affected is when every server
will have 20 times more memory than they NEED on AVERAGE.
Last time I checked, LL was a business.

--
Carlo Wood <carlo-A8X2UORpUyHQT0dZR+***@public.gmane.org>

[Kent Quirk]

As Babbage's blog post said ( https://blogs.secondlife.com/community/technology/blog/2009/12/15/script-limits
):

"We're planning to make script memory usage along with our proposed
script limits visible to all Residents for an extended period before
enforcing any limits. This will give us time to gather feedback on the
proposed limits and identify any situations where we're going to be
imposing unreasonable restrictions and give will give you time to
compare your usage against the proposed limits, give us feedback and
have plenty of time to prepare."

You'll also have time to give us feedback on the enforcement mechanisms.

Q

On Dec 15, 2009, at 8:03 PM, Stickman wrote:

> Ping.
>
> The comfort or early warning I expect is that we're going to get
> better tools to see behind the scenes on scripts before the limits
> actually show up. My fear is that it's going to be right when midterms
> crop up and have a two week window to rewrite every script I've ever
> written.
>
> Can any Lindens on this project provide any information, or point us
> to a magical page on the wiki that explains this? Or, at the very
> least, give us a rough timetable so we know about what time is
> appropriate to begin our panicked search for information?
>
> Thanks much!
>
> Stickman
>
> On Sat, Dec 12, 2009 at 10:43 PM, Ziggy Puff <ziggy-***@public.gmane.org>
> wrote:
>> I was about to post a question on this as well - my wife heard
>> about that
>> blog post (it's spreading pretty quickly among content creators, I
>> think)
>> and so I took a look. I found some good info in 3 or 4 of Babbage
>> Linden's
>> office hour chat logs. More details on the exact algorithms would
>> be very
>> helpful. Some questions I had after going through the material I
>> could find:
>>
>> * Is each script 'charged' 16K/64K, or just what it's using? Is the
>> check
>> made on rez / parcel change, or periodically? Maybe this is a
>> meaningless
>> question, but I thought Mono scripts could scale their memory
>> footprint up
>> and down, in which case a script could have a small footprint when
>> it's
>> rezzed.
>>
>> * Avatar / attachment pool vs. parcel pool - if an av's pool runs
>> out, does
>> an attachment try to take memory from the parcel pool?
>>
>> * The GUI support for reporting script memory usage - will it show
>> the
>> footprint of individual objects, like the 'Top Scripts' window? How
>> about
>> individual attachments? I imagine the last object that would go
>> over the
>> threshold will be the one that's not allowed to rez, but that
>> probably won't
>> be the least efficiently scripted item the person is wearing.
>>
>> Ziggy
>>
>> Stickman wrote:
>>>
>>> I don't know what the official name is, but it's either Parcel
>>> Limits,
>>> Script Limits, or Memory Limits.
>>>
>>> It's been a while since I've heard any official word about it.
>>> Last I
>>> did hear, LL was gathering statistics and didn't know exactly how
>>> they
>>> were going to implement it, let alone what the limits would be.
>>>
>>> Has LL made any decisions, and would they be willing to share them?
>>> More minds on the issue can spot any holes or problems that could
>>> arise, and there's still some rumbling panic among the masses that
>>> can't be confirmed or quelled since we don't know how it'll work.
>>>
>>> Many thanks,
>>>
>>> Stickman
>>> _______________________________________________
>>> Policies and (un)subscribe information available here:
>>> http://wiki.secondlife.com/wiki/SLDev
>>> Please read the policies before posting to keep unmoderated posting
>>> privileges
>>>
>>>
>>>
>>
>>
>>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting
> privileges

[Stickman]

> As Babbage's blog post said (
> https://blogs.secondlife.com/community/technology/blog/2009/12/15/script-limits ):

He replied off-list. :( That's so not fair.

Thanks for pointing it out, Q!

That calms most of my fears on the issue. Basically: "Can't talk yet,
but we will soon, and we won't make changes without user input."

I'll add panicking to my agenda for a later date, then.

-Stickman

[Tigro Spottystripes]

please refresh my memory, did things come out ok in the last few times
LL delayed details and promised to listen to resis?


Stickman escreveu:
>> As Babbage's blog post said (
>> https://blogs.secondlife.com/community/technology/blog/2009/12/15/script-limits ):
>>
>
> He replied off-list. :( That's so not fair.
>
> Thanks for pointing it out, Q!
>
> That calms most of my fears on the issue. Basically: "Can't talk yet,
> but we will soon, and we won't make changes without user input."
>
> I'll add panicking to my agenda for a later date, then.
>
> -Stickman
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting privileges
>
>

[Stickman]

On Tue, Dec 15, 2009 at 9:18 PM, Tigro Spottystripes
<tigrospottystripes-***@public.gmane.org> wrote:
> please refresh my memory, did things come out ok in the last few times
> LL delayed details and promised to listen to resis?

I'm curious, actually. Maybe we can start a new thread and list every
major project that's been done in the last few years, and rate how
well we think it was executed, and if user input would/did/could have
helped.

Welp, back to studying for finals! Have fun!

-Stickman

[Kent Quirk]

First, sarcasm isn't the best way to get a positive response.

Second, we do listen -- not only this time, but many times in the
past. We hear a lot, including a fair amount of contradictory advice.

We listen, and then we decide based on all the evidence we have,
including factors like the long-term health of our technology and our
business. I can guarantee that not everyone will like all of our
decisions. If everyone agreed, they'd be easy decisions.

In this particular case, we are attempting to place known limits in a
place where we only before had unknown limits (it was not "unlimited"
-- nothing is ever "unlimited"). And we're starting by giving you --
and ourselves -- the data before we take action. I think that is both
fair and reasonable.

Q

On Dec 16, 2009, at 12:18 AM, Tigro Spottystripes wrote:

> please refresh my memory, did things come out ok in the last few times
> LL delayed details and promised to listen to resis?
>
>
> Stickman escreveu:
>>> As Babbage's blog post said (
>>> https://blogs.secondlife.com/community/technology/blog/2009/12/15/script-limits
>>> ):
>>>
>>
>> He replied off-list. :( That's so not fair.
>>
>> Thanks for pointing it out, Q!
>>
>> That calms most of my fears on the issue. Basically: "Can't talk yet,
>> but we will soon, and we won't make changes without user input."
>>
>> I'll add panicking to my agenda for a later date, then.
>>
>> -Stickman
>> _______________________________________________
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/SLDev
>> Please read the policies before posting to keep unmoderated posting
>> privileges
>>
>>
>

[Tigro Spottystripes]

It was an honest request, i wanted the facts to base my opinion instead
of having my potentially flawed memories biasing my interpretation of
how comforting "can't say much now, will talk with you later" actually
should be for me

Kent Quirk escreveu:
> First, sarcasm isn't the best way to get a positive response.
>
> Second, we do listen -- not only this time, but many times in the
> past. We hear a lot, including a fair amount of contradictory advice.
>
> We listen, and then we decide based on all the evidence we have,
> including factors like the long-term health of our technology and our
> business. I can guarantee that not everyone will like all of our
> decisions. If everyone agreed, they'd be easy decisions.
>
> In this particular case, we are attempting to place known limits in a
> place where we only before had unknown limits (it was not "unlimited"
> -- nothing is ever "unlimited"). And we're starting by giving you --
> and ourselves -- the data before we take action. I think that is both
> fair and reasonable.
>
> Q
>
> On Dec 16, 2009, at 12:18 AM, Tigro Spottystripes wrote:
>
>> please refresh my memory, did things come out ok in the last few times
>> LL delayed details and promised to listen to resis?
>>
>>
>> Stickman escreveu:
>>>> As Babbage's blog post said (
>>>> https://blogs.secondlife.com/community/technology/blog/2009/12/15/script-limits ):
>>>>
>>>>
>>>
>>> He replied off-list. :( That's so not fair.
>>>
>>> Thanks for pointing it out, Q!
>>>
>>> That calms most of my fears on the issue. Basically: "Can't talk yet,
>>> but we will soon, and we won't make changes without user input."
>>>
>>> I'll add panicking to my agenda for a later date, then.
>>>
>>> -Stickman
>>> _______________________________________________
>>> Policies and (un)subscribe information available here:
>>> http://wiki.secondlife.com/wiki/SLDev
>>> Please read the policies before posting to keep unmoderated posting
>>> privileges
>>>
>>>
>>
>
>

[Henri Beauchamp]

On Wed, 16 Dec 2009 00:35:27 -0500, Kent Quirk wrote:

> First, sarcasm isn't the best way to get a positive response.
>
> Second, we do listen -- not only this time, but many times in the
> past. We hear a lot, including a fair amount of contradictory advice.
> .../...

Not wanting to start a flame war or add more sarcasms, but I'm afraid
Linben Lab did not take very wise neither profitable (for both LL and
the residents) decisions in the past, thus why old-timers can only fear
more hasted and illogical/harmful decisions... Examples ? Here are only
a few:

- The new (well, now over two years old) decentralized groups system
(which used to work just fine as a centralized architecture before
the v1.17 viewer and correpsonding server were issued), which has proven
totally unreliable and unscalable (see the JIRA about "more than 25
groups", and all the complaints about group chat and group notices
failures). Note that this was an unilateral decision from LL and that
no discussion whatsoever occured prior to this change, and that LL
ignored all complaints since...

- The search system, which again used to work just fine and provided
both relevant and, most important, *fair* results before the web-based
search engine was forced down our throats, here again, without any
discussion whatsoever and is now universally recognized as a distaster
among all merchants and customers alike (by the day the official viewer
lost its "All(old)" search tab, my incomes as a merchant droped by a
whooping 50% !). Here again, LL did nothing to date to correct the
problems.

- The dramatic changes in sim pricing and prim support limits (and
the consequences with closed and reduced number of sims).

- The Adult segregation fiasco (again a drop for "Adult" merchants
incomes: 30% for me so far, thank you LL !). There has been a
"discussion" but it was pretty moot since LL had already decided they
would create an "Adult" continent and did not change a single thing in
their plan despite the vehement protests and numerous interesting and
viable counter-proposals.
The true solution was to make a PG continent, but of course, since LL
already decided and worked on the adult continent even before they
opened the "discussion" about the coming changes, it was too late...

The result ?... A user base which at best stagnates and actually goes
down (In now over two years, the "logged in last 60 days" figure on
the login screen went from a little over 1 500 000 in November 2007
(all times record) to under 1 400 000 nowadays), and merchants who
struggle to no avail and will soon leave SL "en masse" for greener
pastures (the next disaster to come for merchants is the new XStreet
policy about freebies which, curiously, will mostly impact non-
freebies ! LL's greed is simply infinite... and will kill their own
business !).

Well, I guess you got the hint...


Now, let's go back to the topic: scripts limits...

My dear Q, since you say you do listen, and since I'm ready to
believe you, here is an advice:

Do not do things the wrong way around. Before imposing *any* limit
on scripts, provide scripters with better functions. My own scripted
products are high quality with a lot of features, and they do use
a lot of scripts. Not so much because they need mega-bytes of
memory to run (I started programming back in the 70s, on 6502 and
6800 processors, with 1Kb of ROM and 256 bytes of RAM, so I think
I do know what optimization means), but simply because there are
no other way than to use slave scripts for child prims (and often,
in average you need one script per prim in the final object): with
the proper functions, I could easily reduce by 70% the number of
scripts, in turn lowering the load imposed on sim and asset
servers when an avatar with scripted attachments enters a new
region (70% less scripts to serialize in the departing sim, send to
the asset server, then fetch back from the asset server and finally
deserialize in the arrival sim)...

Many LSL functions could (should !) be added to avoid having to use
secondary scripts, such as llLinkParticleSystem(), llSetLinkText(),
llGetLinkDesc(), llSetLinkDesc(), llSetLinkName(), etc (in short, it
should be possible for a script in the root primitive to retrieve and
change all the parameters of any of its child primitives), and also fix
the broken functions (see https://jira.secondlife.com/browse/SVC-93
for example)...

These new/debugged functions should be made available to scripters
long (at least 6 months) before any limit is imposed to them, so to
let them enough time to adapt their scripts and for merchants to
update their products. Unless LL's new mission is to break existing
contents and bring features below what is already possible in OpenSim,
which would definitely hasten the "en masse" migration (for your info,
the ONLY reason why I did not myself completely migrate to OpenSim
grids is precisely because scripts are so much more reliable on SL)...

Regards,

Henri Beauchamp.

[Aleric Inglewood]

On Wed, Dec 16, 2009 at 2:21 AM, Kent Quirk <***@lindenlab.com> wrote:

> "We're planning to make script memory usage along with our proposed
> script limits visible to all Residents for an extended period before
> enforcing any limits.

This is doomed to fail, and well for the following reason:

The whole implementation is wrong: you have implemented FIXED
limits per parcel and avatar, while they should have been
dynamic. No matter what user feedback will be received, you're
not going to change this implementation; the user input will
only be used to decide on these fixed limits (if they can
be set lower I imagine, cause after the Ex-street disaster
I don't believe that user input will ever be used to say
"hey, maybe we should set the limits higher and add some
more memory to the servers").

I understand where they "limit per avatar" and "limit per parcel"
comes from:

In case of abuse, in case of actual being out of memory, SOMEONE
has to be responsible and THAT person has to be punished. That
means you need to be able to see who is using too much memory
which means per avatar, and per parcel (since then the parcel
owner is responsible).

However, in the case of homesteads we have four homesteads
on one server... So, rather than punishing parcel owners you
should punish the region owner...

Now here is the problem:

By not having dynamic limits, the limits need to be
*MUCH* lower than they could have been!

Assume the following variables:

Max server memory: S
Region memory used: R1, R2, ...
Parcel memory used: P11, P12, .. P21, P22, ..
Avatar memory used: A1, A2, ...

If all these are FIXED limits, then no doubt you will have
for homesteads:

S = R1 + R2 + R3 + R4

R1 = P11 + P12 + P13 + ... + A_pool

where A_pool is the avatar pool, the amount of memory
reserved for avatars.

If you do not want the NORMAL user to suffer (theKellz's said
on IRC that only the *extreme* cases would be affected and
normal users wouldn't feel a thing), then EACH of those
hard limits must be set pretty high (at the high end of
the normal curve of normal usage).

For the sake of simplicity, lets assume that such a high
limit is four times higher than the average usage (which
imho is on the low side), then that means that this system
will enforce an average usage of only 25% of the maximum
avaiable server memory, which is FOUR times lower than
what we have now. Since a lot of servers ALREADY run into
the max S currently, I predict that no matter what you
try with this system, LOTS AND LOTS of regions will MAJORLY
suffer.

Example 1:

Someone owns four homesteads, all running on the same
server. He doesn't really need that much prims for his
dancing, he needs memory and cpu time. He also liked
a few parks and sea around his dance island, so he
got himself four homesteads, put almost nothing in
three of them and used the memory of the server entirely
to run the heavily visited disco on the fourth.
This is legit usage of resources: he owns all regions
on the whole server, so he owns the server.
Once you put the limits into effect, he will suddenly
only get 1/4 for the disco region of what he had before
MINUS the parcel pool, for the scripts of the visitors
that visit. In effect, almost all visitors will suddenly
run into script problems.

Example 2:

Someone owns a full region. He does the same as above:
he devided the region into several parcels: one parcel
is HUGE, but empty. Other small parcels were created
because that way he could set different music urls:
one for each dance floor!
Once you put the limits into effect, the empty parcels
suddenly reserve a HUGE ammount of resources "just in
case" the "owner" will need it. No ammount of user
feedback can change the limits such that those parcels
can still donate their resources to the dancefloor
parcels... and the whole region breaks down.

Example 3:

As many land tycoons do... full sims are divided into
many parcels, and each parcel is rented out to individuals.
Those individuals are usually close friends (or they
wouldn't have rented on that sim (or even voted in there).
So, they often hang out in one spot. Sometimes in the
house of one of them, more often on the common beach.
And then they have parties. Before, it didn't matter
where they went: they used maybe 30% of the server
resources at all times and things worked just fine.
Then Linden Lab comes with their limits... suddenly
S = R1 + R2 + R3 + R4
and
R1 = P11 + P12 + P13 + ... + A_pool
and NO amount of user feedback is going to change
that, because if you'd change that '=' to '<'
then abuse would still be possible and swapping
could still happen, it simply isn't possible to
allow '<'.
However, that means that the resources of each parcel
is suddenly a fraction... with their 8 parcels and
residents, they suddenly can only have parties
with only 1/8 of the previous resources... and
30% being way larger... that was the end of their
parties.

How to stop this major disaster?
==========================

In order to stop this from becoming major disaster
number X, the whole limiting system HAS to be changed:

There should be NO limits on memory usage whatsoever
UNTIL the server resources are almost used up.

If S == 1.0, and R1 == 0.8, then that is ok as long
as R2 == 0.0, R3 == 0.1 and R4 == 0.05.

Ok, if THEN R2 suddenly wants to use 0.2, then
R1 is the one that has to be limited, BUT NOT BEFORE.

In other words: the limits must be dynamic and ONLY
be set once there is need to set them.

I didn't give an example where memory from the avatar
pool is needed for parcels or the other way around,
but that is exactly the same.

What you should do is make a LLMemoryResource class
and derive everything that uses memory from that class.
This class would enforce memory usage limits.

All those instances together, their ACTUAL memory
usage, added up should be less than the memory on
the WHOLE server (if you REALLY want not support
Example 1, so be it; in which case it should add
up to the whole region).

Lets say the limit of the server is S, then the limit
for EVERY object is set to S.

When a new LLMemoryResource is created, or an exiting
one wants to increase it's memory usage, you check
that the total sum is still less than S first. Once
it becomes larger than S (to sum of everything) THEN
you run an algorithm that sets actual limits.
Whatever that algorithm is, the estate manager must
be able to configure it! Ie, he must be able to say:
that parcel gets 90% of the resources; or the
avatar pool gets 50% of the resources (or 10%).

This would then result in some scripts not being
able to run anymore. They should print "Out of Memory"
in the script debug console and stop running (and
then free their memory usage). If one tries to set
such a script to running again, it would check if
that is possible due to it's limit and either start
or give an error message and refuse to run.

[Imaze Rhiano]

Aleric Inglewood kirjoitti:
> On Wed, Dec 16, 2009 at 2:21 AM, Kent Quirk <***@lindenlab.com> wrote:
>
>
>> "We're planning to make script memory usage along with our proposed
>> script limits visible to all Residents for an extended period before
>> enforcing any limits.
>>
>
> This is doomed to fail, and well for the following reason:
>
> The whole implementation is wrong: you have implemented FIXED
> limits per parcel and avatar, while they should have been
> dynamic. No matter what user feedback will be received, you're
> not going to change this implementation; the user input will
> only be used to decide on these fixed limits (if they can
> be set lower I imagine, cause after the Ex-street disaster
> I don't believe that user input will ever be used to say
> "hey, maybe we should set the limits higher and add some
> more memory to the servers").
> ---- CUT & CUT ---
>
There is some problems what I can see in dynamic limits:
1) If avatar rezzes attachments in region that have lot's of available
memory and then teleports to region that doesn't have enough memory for
avatar's attachments then either teleportation fails ("Not enough memory
in target region error message") or alternatively randomly some of
scripted attachments don't rezz in target region?
2) If avatar rezzes attachments in region that have lot's of available
memory and then logouts. What happens for her attachments when she log's
back and region doesn't have enough memory for attachments anymore? Is
avatar moved to some staging region or are attachment randomly removed
until avatar fits to memory limits?
3) Let's imagine that you are organizing some kind event that requires
you to rezz some scripted objects after participants are arrived. You
test that object rezzes properly before participants arrive - everything
seems to be okay. Then event starts - and there is coming much more
participants than you were able to dream of. When time comes, you try to
rezz scripted objects, but region is reporting back "Not enough memory".
4) You decide upgrade your parcel larger. You rent/buy empty parcel from
another estate. After rezzing your house you start rezzing furnitures.
Sofa to living room rezzes fine - but when you try to rezz bed to
bedroom - you get error "Not enough memory". You are wondering what just
happened? Everything was rezzing fine to parcel that was much more
smaller. After talking with estate owner: It turns out that your
neighbors are using most of regions memory already. Actually - tenant
who rented first parcel in region is using 80% of regions memory to her
chicken farm. Estate owner doesn't want to remove those chickens because
she is biggest tier payer, she is also having lot's of fun with her in
her bed and those chickens are from very valuable prize winning pedigree.
5) If I have understood correctly you can't choose homesteads that are
running in same server. Also you homestead might occasionally moved to
another server. Because of server maintenance or some geek in LL server
farm just want to play with his god powers.

I agree that there should be ways to set PARCEL memory limitations,
before limitations are going to enforced. For example estate manager
doesn't want to waste region's PARCEL memory to empty street parcels -
she wants to allocate all available PARCEL memory to building parcels
where her tenants are living and have their shops, houses and clubs.
AVATAR memory limits should be fixed - so that there is no problems with
border crossing, logging in or teleporting. However, estate manager
should be able to set maximal amount avatars in region - thus allocating
more/less PARCEL memory for scripts in parcels. But these shouldn't be
dynamic - that cause nondeterministic behavior.

[Aleric Inglewood]

Those are not problems with *dynamic* limits.

Dynamic here means that the limits are not enforced until
REALLY necessary (and then accordingly to how the estate
manager thinks is reasonable to devide the resources).

Fixed limits means that each group (each parcel and each
avatar only gets the memory that would be available if
everything else and all others would be using their MAXIMUM
resources. That will result in a limit that is a factor 4 to
8 LOWER than it can be on average, a limit that will be
MUCH lower than what you can have now most of the time.

So, let me rephrase your "problems"

On Wed, Dec 16, 2009 at 03:54:20PM +0200, Imaze Rhiano wrote:
> There is some problems what I can see in dynamic limits:
> 1) If avatar rezzes attachments in region that have lot's of available
> memory and then teleports to region that doesn't have enough memory for
> avatar's attachments then either teleportation fails ("Not enough memory
> in target region error message") or alternatively randomly some of
> scripted attachments don't rezz in target region?

With fixed limits:
The avatar rezzes attachments in region that have lot's of available
memory, but it fails nevertheless while before everything worked
just fine in this region!

What is worse?

> 2) If avatar rezzes attachments in region that have lot's of available
> memory and then logouts. What happens for her attachments when she log's
> back and region doesn't have enough memory for attachments anymore? Is
> avatar moved to some staging region or are attachment randomly removed
> until avatar fits to memory limits?

With fixed limits:
The avatar rezzes attachments in region that have lot's of available
memory, but it fails nevertheless while before everything worked
just fine in this region!

What is worse?

> 3) Let's imagine that you are organizing some kind event that requires
> you to rezz some scripted objects after participants are arrived. You
> test that object rezzes properly before participants arrive - everything
> seems to be okay. Then event starts - and there is coming much more
> participants than you were able to dream of. When time comes, you try to
> rezz scripted objects, but region is reporting back "Not enough memory".

That wouldn't happen if those objects use their fair share.
If they do NOT use their fair share, it also wouldn't work with fixed
limits. What you can do in this case is test in advance how much
memory your objects need in that parcel and then have the estate manager
allocate that amount. In that case you have the right for those resources
and what would happen if you rez the objects is that avatar scripts
(and then starting with those that run most scripts) will have their
scripts stopped. If a lot of the guests have 'scripted hair' then those
will the first to go, and since those scripts should really have been
deleted in the first place, nobody would really notice it anyway.

In the event that people DO notice it, then well - then you ARE overloading
the region with your event and should ask people to turn off scripts or
leave, because the region IS overloaded.

> 4) You decide upgrade your parcel larger. You rent/buy empty parcel from
> another estate. After rezzing your house you start rezzing furnitures.
> Sofa to living room rezzes fine - but when you try to rezz bed to
> bedroom - you get error "Not enough memory". You are wondering what just
> happened? Everything was rezzing fine to parcel that was much more
> smaller. After talking with estate owner: It turns out that your
> neighbors are using most of regions memory already. Actually - tenant
> who rented first parcel in region is using 80% of regions memory to her
> chicken farm. Estate owner doesn't want to remove those chickens because
> she is biggest tier payer, she is also having lot's of fun with her in
> her bed and those chickens are from very valuable prize winning pedigree.

Like I said, once the region runs out of memory, THOSE parcels / avatars
will be limited that use most memory of course. So, this would never
happen to you. What would happen is that your neighbors chicken farm
would stop working after you rez your bed. The neighbor would go to the
estate manager and he'd tell her that she was lucky that the estate
was empty before, but that from now on she'll have to settle with her
fair share of memory.

Note that she would have known in advance that this would happen,
because the tools will be (should be) there to tell her that she's
using too much resources (it just wouldn't be enforced as long as the
resources are available).

Compare this to how I run my sim:

I have 500 prims "reserve", they are not allocated to parcels.
Every parcel can rez prims till the region is FULL. There are no
limits. People keep track of what they MAY rez (what they pay for),
if they go over it for a longer period of time they are asked to
delete stuff (they never do in practise by the way).

However, it OFTEN happens that someone rezzes something temporarily
ie - "look at this"... or whatever, we have bike contest (each bike
is 100 prims!). Because of the reserve of 500, we never get "region
is full" when we want to play... just as long as you clean up
afterwards.

This situation iS WAYYYYY better than when I'd have set a FIXED
limit and had given everyone a slice of those 500 and enforced
that ... ie, everyone got 100 "reserve" prims and could never
rez more JUST IN CASE all the neighbors wanted to rez their 100 too.

Come on!

But that is exactly what LL is going to do :(

> 5) If I have understood correctly you can't choose homesteads that are
> running in same server. Also you homestead might occasionally moved to
> another server. Because of server maintenance or some geek in LL server
> farm just want to play with his god powers.

Then that is something that needs fixing too.
If someone wants to hire a server and run four homesteads on it
then that should be possible, of course. Hell, you're paying for it no?

> I agree that there should be ways to set PARCEL memory limitations,
> before limitations are going to enforced. For example estate manager
> doesn't want to waste region's PARCEL memory to empty street parcels -
> she wants to allocate all available PARCEL memory to building parcels
> where her tenants are living and have their shops, houses and clubs.

Yes, but this is orthogonal to NOT enforcing limits before they
are really needed (the server starts swapping). Although, if the estate
manager COULD change the memory allocation, then that would be pseudo
dynamic: in case of disasters (party has to be cancelled), he could
CHANGE the limits so that the bloody server wouldn't start to tell
people that it's out of memory while it's NOT out of memory.

> AVATAR memory limits should be fixed - so that there is no problems with
> border crossing, logging in or teleporting. However, estate manager
> should be able to set maximal amount avatars in region - thus allocating
> more/less PARCEL memory for scripts in parcels. But these shouldn't be
> dynamic - that cause nondeterministic behavior.

If you think that setting a fixed amount of memory PER avatar is
going to help then think again:

LL is a business... memory costs money. Why would they want to never USE
the memory that they put into the servers? What you want is to reserve
on EVERY server the amount of memory needed to serve the MAXIMUM number
of avatars (configurable or not) each using their MAXIMUM amount of memory!
So you can always teleport... right.

Lets see... Suppose that currently the average avatar uses x Megabytes of
memory. Lets also assume that if you use 10 times as much as the average,
it still isn't ABUSE, because their are very good reasons in some cases
to do that. So, the limit is set to 10x per avatar.

Furthermore, MOST regions are empty - but they COULD theoretically
host 20 to 100 avatars (haha, ok 20 -- officially it's 100 I think).

So, there you are walking around with your partner in an otherwise
empty sim using x MB each, and instead of having almost unlimited amount
of resources, the region tries to keep 180 * x MB in reserve --
THAT IS NINETY TIMES THE AMOUNT OF MEMORY YOU ARE USING! -- JUST
in case suddenly 18 others loaded with the maximum number of scripts
simultaneously wanted to popup next to you!
What does that mean? It means that this region effectively has MUCH
MUCH less memory available, and you will MUCH MUCH sooner seen those
"limits" take effect then you'd ever before.

I'll take lagging due to swapping ANYTIME (I'll just tp away) over
having to deal with "out of memory" non-stop in almost every region
that used to work fine before!

[Peter Leonard/Dante]

Just look at region Object Bonus. This is an example where a dynamic system
is already in use and works.

Object bonus allows EMs and the EO to allocate empty buffer parcels in order
to give other parcels more prims.

With object bonus on there is the posibility to rez more prims then the sim
allows and have the sim return random objects, yet it works, and LL chose to
give the estate staff the choice. Why can we not do this with script limits
as well?

[Peter Leonard/Dante]

In fact. I think this is an example where Script Limits will break content.
Imagine all the regions out there that use Object Bonus to pile all there
stuff into a few small parcels. These regions will be destroyed even though
it is legitimate use!

On Thu, Dec 17, 2009 at 2:54 AM, Peter Leonard/Dante
<danteferret-***@public.gmane.org>wrote:

> Just look at region Object Bonus. This is an example where a dynamic system
> is already in use and works.
>
> Object bonus allows EMs and the EO to allocate empty buffer parcels in
> order to give other parcels more prims.
>
> With object bonus on there is the posibility to rez more prims then the sim
> allows and have the sim return random objects, yet it works, and LL chose to
> give the estate staff the choice. Why can we not do this with script limits
> as well?
>

[Ambrosia]

Just to make a few things clear about memory limits and how they work:

* 300mb will be divided between land and avatars in each sim. Fixed
size per avatar, and per square meter.
* Each avatar will have their own memory pool for attachments
* Each parcel will have its own memory pool depending on its size
(it's basically memory per square meter)
* The script memory limit per script will be removed for mono scripts
* Scripts will be able to request memory with a new function. if the
memory in the pool is free, it gets reserved for that script.
* The first 6+ months, the limits will only be displayed, not enforced
* People will get script memory/time of scripts they wear and own in the sim
* Land owners will be able to get the info about all scripts on their parcel
* Estate owners will get the info about all scripts in the sim
* There will be an effort to add new LSL functions to make scripting
with less scripts easier. The definite batch for the first round of
additions: llGetPrimitiveParams/llGetLinkPrimitiveParams,
llSetPrimitiveParamsNoDelay/llSetLinkPrimitiveParamsNoDelay. Also
there will be a new PRIM_TEXT rule for those functions to set the
hovertext of linked prims remotely.

So, no, there is no danger of not being able to log in with your
attachments if you were able to wear them in the first place. No, one
parcel can't take away another parcel's memory. No, the limits will
only be displayed but not enforced so people can adapt during the
first six months.

And If only 20% of those 300mb should be spread onto avatars per sim,
40 avatars would get 1.5mb of script memory each. This is already a
ridiculously high amount for attachments, and the only people affected
by this will be the ones who are unable to script efficiently.

--Chalice Yao

[Argent Stonecutter]

On 2009-12-17, at 02:01, Ambrosia wrote:
> Just to make a few things clear about memory limits and how they work:
>
> * 300mb will be divided between land and avatars in each sim. Fixed
> size per avatar, and per square meter.

This is the bit that I think is an issue. It should permit
overcommitment for small parcels, by some scaled percentage, so long
as the sim as a whole is below (say) 75% of the limit.

[Lear Cale]

On Thu, Dec 17, 2009 at 3:01 AM, Ambrosia <chaosstar-***@public.gmane.org> wrote:

> Just to make a few things clear about memory limits and how they work:
>
> * 300mb will be divided between land and avatars in each sim. Fixed
> size per avatar, and per square meter.
> * Each avatar will have their own memory pool for attachments
> * Each parcel will have its own memory pool depending on its size
> (it's basically memory per square meter)
> * The script memory limit per script will be removed for mono scripts
> * Scripts will be able to request memory with a new function. if the
> memory in the pool is free, it gets reserved for that script.
>

I heard that this was now off the table. I also heard that all scripts
(whether mono or LSL) will be counted as
taking 64K. Does anyone know the facts?

Thanks
Jeff

[Stickman]

> I heard that this was now off the table.  I also heard that all scripts
> (whether mono or LSL) will be counted as
> taking 64K.  Does anyone know the facts?

Babbage's office hours on the 16th said they're thinking of imposing a
penalty for using LSO scripts, such as giving them a memory multiplier
for accounting. But as of that last meeting, they haven't decided for
sure yet. The goal of such a choice would be to encourage people to
move to Mono, so they could eventually stop supporting two VMs. As
mentioned elsewhere, you'll be able to specify how much memory you
want, like 4kb or a meg, so at least the 16k LSO footprint won't be
claimable as a reason to use it.

As for everything else -- it's ideas on the table. There will be
adequate time for us to dispute what will and won't work, and what's
the best way to do it, after they release the tools for us to see
what's actually going on so we can make informed decisions. I think
all the major ideas on how it could be arranged have been spoken for,
and I'm not sure which one LL is preferring at this point.

Since they said they'll be looking for user input after the tools are
out, I'm pretty sure everything LL says is ideas and plans, but not
paved walkways.

I'm just looking forward to my llSetLinkPrimitiveParamsFast(). Soooooo
delicious nom nom nom.

Stickman

[Ambrosia]

The idea of this was mentioned already in an office hour from earlier
this year. 64-128k
was the mentioned amount there.

As for the other items..Babbage is approachable, I don't think they
are off the table.
What I would personally suggest is to simply directly tie the memory
limit multiplier
to the prim multiplier, but to keep the total memory limit the
same..just like the total
prim limit of all parcels together in the sim stay the same for the
owner of the parcels.

On Thu, Dec 17, 2009 at 15:25, Stickman <stickman-***@public.gmane.org> wrote:
>> I heard that this was now off the table.  I also heard that all scripts
>> (whether mono or LSL) will be counted as
>> taking 64K.  Does anyone know the facts?
>
> Babbage's office hours on the 16th said they're thinking of imposing a
> penalty for using LSO scripts, such as giving them a memory multiplier
> for accounting.

[Ambrosia]

P.S. no, this increased memory count was supposed to only apply to LSL
scripts, as they want to ultimately fade them out. Mono scripts will
have their actual memory usage counted when it comes to the limits

On Thu, Dec 17, 2009 at 15:30, Ambrosia <chaosstar-***@public.gmane.org> wrote:
> The idea of this was mentioned already in an office hour from earlier
> this year. 64-128k
> was the mentioned amount there.

[Tigro Spottystripes]

But the limits should only be enforced when necessary, if there is a
bunch of scripts in a 4x4 parcel and nothing else int he rest of the sim
those scripts can use up all the sim script memory, if an avatar comes
in, then the avaiablememory is divided between the parcel and the
avatar, things like that


Ambrosia escreveu:
> The idea of this was mentioned already in an office hour from earlier
> this year. 64-128k
> was the mentioned amount there.
>
> As for the other items..Babbage is approachable, I don't think they
> are off the table.
> What I would personally suggest is to simply directly tie the memory
> limit multiplier
> to the prim multiplier, but to keep the total memory limit the
> same..just like the total
> prim limit of all parcels together in the sim stay the same for the
> owner of the parcels.
>
> On Thu, Dec 17, 2009 at 15:25, Stickman <stickman-***@public.gmane.org> wrote:
>
>>> I heard that this was now off the table. I also heard that all scripts
>>> (whether mono or LSL) will be counted as
>>> taking 64K. Does anyone know the facts?
>>>
>> Babbage's office hours on the 16th said they're thinking of imposing a
>> penalty for using LSO scripts, such as giving them a memory multiplier
>> for accounting.
>>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting privileges
>
>

[Ambrosia]

And the script instantly crashes because suddenly it holds more data
than it can when the avatar enters the sim? The alternative would be
for the script to keep the memory it uses..but that would defeat the
purpose of script limits, as now the sim would use up more memory than
the 300mb it is supposed to use as max.

That's the main issue why, no, there needs to be a defined, fixed
number per square meter and avatar, that scripts can rely on being
fixed and usable, no matter what else is going on in the sim's parcels
or avatars.

On Thu, Dec 17, 2009 at 15:37, Tigro Spottystripes
<tigrospottystripes-***@public.gmane.org> wrote:
> But the limits should only be enforced when necessary, if there is a
> bunch of scripts in a 4x4 parcel and nothing else int he rest of the sim
> those scripts can use up all the sim script memory, if an avatar comes
> in, then the avaiablememory is divided between the parcel and the
> avatar, things like that

[Tigro Spottystripes]

There should be a way for scripts to check how much memory is avaiable
int he pool for the sim, and for the parcel, and also how much memory
the script will be limited to under a worse case scenario, scripts that
can't be allowed to crash would check if they can still perform in worse
case scenario and inform the owner if not. Would work kinda like how it
is when one person owns mroe than one parcel in the sim, they can
redistribute the prim count, witht he difference of it not being
restricted to same owner. Scripts that are using more than it's quota
for the worse case scenario are beyond the safety limits, beyond whatis
recomended, they can crash and stuff, kinda like an overclocked CPU.


Ambrosia escreveu:
> And the script instantly crashes because suddenly it holds more data
> than it can when the avatar enters the sim? The alternative would be
> for the script to keep the memory it uses..but that would defeat the
> purpose of script limits, as now the sim would use up more memory than
> the 300mb it is supposed to use as max.
>
> That's the main issue why, no, there needs to be a defined, fixed
> number per square meter and avatar, that scripts can rely on being
> fixed and usable, no matter what else is going on in the sim's parcels
> or avatars.
>
> On Thu, Dec 17, 2009 at 15:37, Tigro Spottystripes
> <tigrospottystripes-***@public.gmane.org> wrote:
>
>> But the limits should only be enforced when necessary, if there is a
>> bunch of scripts in a 4x4 parcel and nothing else int he rest of the sim
>> those scripts can use up all the sim script memory, if an avatar comes
>> in, then the avaiablememory is divided between the parcel and the
>> avatar, things like that
>>
>
>

[Ambrosia]

But in your example, the script uses the max of the sim til the avatar
comes in. The script will crash, as the avatar takes his own share of
memory, and the script suddenly has less than it actually uses (not
what it -could- use but doesn't).

Scripts -will- be able to check available memory, that much has been
stated, and they reserve additional memory they need with another
function, but that available memory should not depend on factors of
what's going on outside the parcel or on other avatars aside of the
own.

Quite frankly, the only thing that makes sense for scripters and
content creators are hard numbers they can work with. Fixed memory
amounts. Every 512sqm parcel should always (normally) support X mb
max. Every avatar should normally support Y mb max. A solid api to
build scripts upon. Available memory depends on the scripts already
attached to the -same- avatar or on the -same- parcel, but a parcel's
or avatar's memory should -not- be dependant in any way on external
factors like other avatars or parcels. It makes things unreliable,
unpredictable.

On Thu, Dec 17, 2009 at 16:10, Tigro Spottystripes
<tigrospottystripes-***@public.gmane.org> wrote:
> There should be a way for scripts to check how much memory is avaiable
> int he pool for the sim, and for the parcel, and also how much memory
> the script will be limited to under a worse case scenario,

[Peter Leonard/Dante]

It cannot be fixed per square meter. There are hundreds of sims that fill
most of their land with nothing, trees and such to make it pretty. And use
parcel object bonus to stick most of there content into just a small parcel
in the sim.


If script limits are to be implimented as they are currently designed, then
the parcel object bonus feature must be removed. And this will ruin a large
percentage of private sim owners. The amount of money LL will lose if that
many people drop out is just crazy.

[Ambrosia]

Or, as I mentioned, the parcel object bonus has an influence on a
script memory bonus, that would work similiar the parcel bonus does.
Dependant on total land mass person X owns in the sim. The parcel can
hold more objects/Memory than it normally could, but it can't go above
the total objects/Memory the parcels by the person in the sim put
together would allow.

On Thu, Dec 17, 2009 at 16:32, Peter Leonard/Dante
<danteferret-***@public.gmane.org> wrote:
> It cannot be fixed per square meter. There are hundreds of sims that fill
> most of their land with nothing, trees and such to make it pretty. And use
> parcel object bonus to stick most of there content into just a small parcel
> in the sim.
>
>
> If script limits are to be implimented as they are currently designed, then
> the parcel object bonus feature must be removed. And this will ruin a large
> percentage of private sim owners. The amount of money LL will lose if that
> many people drop out is just crazy.
>

[d***@public.gmane.org]

Unfortunately that does not work either.

Typicaly the land is set up like this: Public no build land owned by a
group or the EO, used as buffer space. And all the other parcels owned by
various renters, who will be receiving the bonus in prims.

As you can see, in typical situations the land is not owned by the same
person.

On Dec 17, 2009 10:39am, Ambrosia <chaosstar-***@public.gmane.org> wrote:
> Or, as I mentioned, the parcel object bonus has an influence on a

> script memory bonus, that would work similiar the parcel bonus does.

> Dependant on total land mass person X owns in the sim. The parcel can

> hold more objects/Memory than it normally could, but it can't go above

> the total objects/Memory the parcels by the person in the sim put

> together would allow.

[Tigro Spottystripes]

If the owner expects the sim to never have more than like at most 10
people in it at any given moment, use up the memory that is left after
10 use up all their quota, no crashing unless more than 10 people get
in the sim at the same time


Ambrosia escreveu:
> But in your example, the script uses the max of the sim til the avatar
> comes in. The script will crash, as the avatar takes his own share of
> memory, and the script suddenly has less than it actually uses (not
> what it -could- use but doesn't).
>
> Scripts -will- be able to check available memory, that much has been
> stated, and they reserve additional memory they need with another
> function, but that available memory should not depend on factors of
> what's going on outside the parcel or on other avatars aside of the
> own.
>
> Quite frankly, the only thing that makes sense for scripters and
> content creators are hard numbers they can work with. Fixed memory
> amounts. Every 512sqm parcel should always (normally) support X mb
> max. Every avatar should normally support Y mb max. A solid api to
> build scripts upon. Available memory depends on the scripts already
> attached to the -same- avatar or on the -same- parcel, but a parcel's
> or avatar's memory should -not- be dependant in any way on external
> factors like other avatars or parcels. It makes things unreliable,
> unpredictable.
>
> On Thu, Dec 17, 2009 at 16:10, Tigro Spottystripes
> <tigrospottystripes-***@public.gmane.org> wrote:
>
>> There should be a way for scripts to check how much memory is avaiable
>> int he pool for the sim, and for the parcel, and also how much memory
>> the script will be limited to under a worse case scenario,
>>
>
>

[Tammy Nowotny]

One concern I have is that script limits could be turned around into a
griefers tool. You will undoubtedly have scripts designed simply to use
up all the bandwidth. And there might be more subtle exploits where the
griefer uses up all the capacity, and then releases some of it at just
the wrong moment to enable some nasty prank can be pulled which everyone
else will be powerless to counteract.

[Joel Foner]

This exists today - except that when the resources are exhausted an entire
region is slowed to a crawl or crashed. Wouldn't it be better to have the
effects of an inadvertent or purposeful attempt to run the system out of
resources to be contained to some degree?

Joel

On Thu, Dec 17, 2009 at 4:24 PM, Tammy Nowotny <TammyNowotny-***@public.gmane.org> wrote:

>
> One concern I have is that script limits could be turned around into a
> griefers tool. You will undoubtedly have scripts designed simply to use
> up all the bandwidth. And there might be more subtle exploits where the
> griefer uses up all the capacity, and then releases some of it at just
> the wrong moment to enable some nasty prank can be pulled which everyone
> else will be powerless to counteract.
>
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting
> privileges
>

[Melinda Green]

Perhaps a hybrid design might make for a reasonable compromise between
predictability and flexibility. Something like hard lower memory limits
that scripters can count on always being available, plus the ability to
request and receive provisional amounts beyond that which might get
yanked back at any time. If you go beyond the safe limits, you take your
chances. There may even be more gentle ways to deal with these
worst-case situations, for example by creating an LSL event that informs
scripts when they are about to lose some or all of the provisional
memory that they are using, giving them a chance to get back under a
safe limit and avoid getting shut down.

I suspect that Qie Niangao is right that some non-trivial optimization
logic is called for here. To me the situation feels like operating
system design. In many ways the simulators *are* simple operating
systems. Perhaps talking with some Linux kernel developers might
identify some libraries that can be used to manage script resource
allocations. I don't know because OS design is not my field but I
suspect that there are no simple solutions to this problem and that it
would not be smart to try to reinvent its solutions.

-Melinda

Ambrosia wrote:
> But in your example, the script uses the max of the sim til the avatar
> comes in. The script will crash, as the avatar takes his own share of
> memory, and the script suddenly has less than it actually uses (not
> what it -could- use but doesn't).
>
> Scripts -will- be able to check available memory, that much has been
> stated, and they reserve additional memory they need with another
> function, but that available memory should not depend on factors of
> what's going on outside the parcel or on other avatars aside of the
> own.
>
> Quite frankly, the only thing that makes sense for scripters and
> content creators are hard numbers they can work with. Fixed memory
> amounts. Every 512sqm parcel should always (normally) support X mb
> max. Every avatar should normally support Y mb max. A solid api to
> build scripts upon. Available memory depends on the scripts already
> attached to the -same- avatar or on the -same- parcel, but a parcel's
> or avatar's memory should -not- be dependant in any way on external
> factors like other avatars or parcels. It makes things unreliable,
> unpredictable.
>
> On Thu, Dec 17, 2009 at 16:10, Tigro Spottystripes
> <tigrospottystripes-***@public.gmane.org> wrote:
>
>> There should be a way for scripts to check how much memory is avaiable
>> int he pool for the sim, and for the parcel, and also how much memory
>> the script will be limited to under a worse case scenario,
>>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting privileges
>
>

[Tigro Spottystripes]

The problem with a fixed maximum guranteed memory per script is that it
doesnt' add a limit for more than one script, so several scripts could
be using the minimum guarantted and not veing capped.

My idea is to haev a fixed per meter and per avatar maximum guaranteed
memory, anything baove guaranteed. Scripts using more than that are out
of the safe limits.

We Need somthing like llGetSimFullMemory, llGetSimFreeMemoy,
llGetParcelFullMemory, llGetParcelFreeMemory, llGetOwnerFullMemory and
llGetOwnerFreeMemory. And i like the idea of an event to be triggered
before the script either looses some of it's avaiable memory or is about
to be shut down if it doesn't start using N less bytes of memory,
somthing like:

less_memory(float bytes_to_loose)


The sun wauts tgat evebt ti ebd fir a secibd ir si abd uf ut diesb't ebd
vefire tgatm ir uf after that the script still hasn't lost enough bytes
in it's ram footprint the sim will shutdown the script (perhaps save the
script state of not running scripts on disk and not on ram?)




Melinda Green escreveu:
> Perhaps a hybrid design might make for a reasonable compromise between
> predictability and flexibility. Something like hard lower memory
> limits that scripters can count on always being available, plus the
> ability to request and receive provisional amounts beyond that which
> might get yanked back at any time. If you go beyond the safe limits,
> you take your chances. There may even be more gentle ways to deal with
> these worst-case situations, for example by creating an LSL event that
> informs scripts when they are about to lose some or all of the
> provisional memory that they are using, giving them a chance to get
> back under a safe limit and avoid getting shut down.
>
> I suspect that Qie Niangao is right that some non-trivial optimization
> logic is called for here. To me the situation feels like operating
> system design. In many ways the simulators *are* simple operating
> systems. Perhaps talking with some Linux kernel developers might
> identify some libraries that can be used to manage script resource
> allocations. I don't know because OS design is not my field but I
> suspect that there are no simple solutions to this problem and that it
> would not be smart to try to reinvent its solutions.
>
> -Melinda
>
> Ambrosia wrote:
>> But in your example, the script uses the max of the sim til the avatar
>> comes in. The script will crash, as the avatar takes his own share of
>> memory, and the script suddenly has less than it actually uses (not
>> what it -could- use but doesn't).
>>
>> Scripts -will- be able to check available memory, that much has been
>> stated, and they reserve additional memory they need with another
>> function, but that available memory should not depend on factors of
>> what's going on outside the parcel or on other avatars aside of the
>> own.
>>
>> Quite frankly, the only thing that makes sense for scripters and
>> content creators are hard numbers they can work with. Fixed memory
>> amounts. Every 512sqm parcel should always (normally) support X mb
>> max. Every avatar should normally support Y mb max. A solid api to
>> build scripts upon. Available memory depends on the scripts already
>> attached to the -same- avatar or on the -same- parcel, but a parcel's
>> or avatar's memory should -not- be dependant in any way on external
>> factors like other avatars or parcels. It makes things unreliable,
>> unpredictable.
>>
>> On Thu, Dec 17, 2009 at 16:10, Tigro Spottystripes
>> <tigrospottystripes-***@public.gmane.org> wrote:
>>
>>> There should be a way for scripts to check how much memory is avaiable
>>> int he pool for the sim, and for the parcel, and also how much memory
>>> the script will be limited to under a worse case scenario,
>>>
>> _______________________________________________
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/SLDev
>> Please read the policies before posting to keep unmoderated posting
>> privileges
>>
>>
>

[Tigro Spottystripes]

wow, i usually re-read my emails before sending them and do ortographic
corrections, i have no idea what happened there 0.0

sorry :/

lemme try it again


The problem with a fixed maximum guaranteed memory per script is
that it
doesn't add a limit for more than one script, so several scripts could
be using the minimum guaranteed and not being capped.

My idea is to have a fixed per meter and per avatar maximum guaranteed
memory, anything above guaranteed. Scripts using more than that are out
of the safe limits.

We Need somthing like llGetSimFullMemory, llGetSimFreeMemoy,
llGetParcelFullMemory, llGetParcelFreeMemory, llGetOwnerFullMemory and
llGetOwnerFreeMemory. And i like the idea of an event to be triggered
before the script either looses some of it's avaiable memory or is
about
to be shut down if it doesn't start using N less bytes of memory,
somthing like:

less_memory(float bytes_to_loose)


The sim waits for the event to end for a second or so and if it
doesn't end
in time or if after that the script still hasn't lost enough bytes
in it's ram footprint the sim will shutdown the script (perhaps save
the
script state of not running scripts on disk and not on ram?)



there, once again sorry for the messed up msg :\







Melinda Green escreveu:
> That seems like the same thing that I just said except that your text
> and grammar are so messed up that it is hard for me to understand
> exactly what you are saying.
> -Melinda
>
> Tigro Spottystripes wrote:
>> The problem with a fixed maximum guranteed memory per script is that it
>> doesnt' add a limit for more than one script, so several scripts could
>> be using the minimum guarantted and not veing capped.
>>
>> My idea is to haev a fixed per meter and per avatar maximum guaranteed
>> memory, anything baove guaranteed. Scripts using more than that are out
>> of the safe limits.
>>
>> We Need somthing like llGetSimFullMemory, llGetSimFreeMemoy,
>> llGetParcelFullMemory, llGetParcelFreeMemory, llGetOwnerFullMemory and
>> llGetOwnerFreeMemory. And i like the idea of an event to be triggered
>> before the script either looses some of it's avaiable memory or is about
>> to be shut down if it doesn't start using N less bytes of memory,
>> somthing like:
>>
>> less_memory(float bytes_to_loose)
>>
>>
>> The sun wauts tgat evebt ti ebd fir a secibd ir si abd uf ut diesb't ebd
>> vefire tgatm ir uf after that the script still hasn't lost enough bytes
>> in it's ram footprint the sim will shutdown the script (perhaps save the
>> script state of not running scripts on disk and not on ram?)
>>
>>
>>
>>
>> Melinda Green escreveu:
>>
>>> Perhaps a hybrid design might make for a reasonable compromise between
>>> predictability and flexibility. Something like hard lower memory
>>> limits that scripters can count on always being available, plus the
>>> ability to request and receive provisional amounts beyond that which
>>> might get yanked back at any time. If you go beyond the safe limits,
>>> you take your chances. There may even be more gentle ways to deal with
>>> these worst-case situations, for example by creating an LSL event that
>>> informs scripts when they are about to lose some or all of the
>>> provisional memory that they are using, giving them a chance to get
>>> back under a safe limit and avoid getting shut down.
>>>
>>> I suspect that Qie Niangao is right that some non-trivial optimization
>>> logic is called for here. To me the situation feels like operating
>>> system design. In many ways the simulators *are* simple operating
>>> systems. Perhaps talking with some Linux kernel developers might
>>> identify some libraries that can be used to manage script resource
>>> allocations. I don't know because OS design is not my field but I
>>> suspect that there are no simple solutions to this problem and that it
>>> would not be smart to try to reinvent its solutions.
>>>
>>> -Melinda
>>>
>>> Ambrosia wrote:
>>>
>>>> But in your example, the script uses the max of the sim til the avatar
>>>> comes in. The script will crash, as the avatar takes his own share of
>>>> memory, and the script suddenly has less than it actually uses (not
>>>> what it -could- use but doesn't).
>>>>
>>>> Scripts -will- be able to check available memory, that much has been
>>>> stated, and they reserve additional memory they need with another
>>>> function, but that available memory should not depend on factors of
>>>> what's going on outside the parcel or on other avatars aside of the
>>>> own.
>>>>
>>>> Quite frankly, the only thing that makes sense for scripters and
>>>> content creators are hard numbers they can work with. Fixed memory
>>>> amounts. Every 512sqm parcel should always (normally) support X mb
>>>> max. Every avatar should normally support Y mb max. A solid api to
>>>> build scripts upon. Available memory depends on the scripts already
>>>> attached to the -same- avatar or on the -same- parcel, but a parcel's
>>>> or avatar's memory should -not- be dependant in any way on external
>>>> factors like other avatars or parcels. It makes things unreliable,
>>>> unpredictable.
>>>>
>>>> On Thu, Dec 17, 2009 at 16:10, Tigro Spottystripes
>>>> <tigrospottystripes-***@public.gmane.org> wrote:
>>>>
>>>>
>>>>> There should be a way for scripts to check how much memory is
>>>>> avaiable
>>>>> int he pool for the sim, and for the parcel, and also how much memory
>>>>> the script will be limited to under a worse case scenario,
>>>>>
>>>> _______________________________________________
>>>> Policies and (un)subscribe information available here:
>>>> http://wiki.secondlife.com/wiki/SLDev
>>>> Please read the policies before posting to keep unmoderated posting
>>>> privileges
>>>>
>>>>
>>
>>
>>
>

[Argent Stonecutter]

Another thought on my soft/hard limit suggestion: scripts could check
if the parcel they are in is over the soft limit, and release cached
information like lists of avatars or information read from
configuration notecards and go into dormant low-memory mode. Multi-
script objects could even remove extra scripts. That could even be a
selling point: "this script is memory safe... if parcel or region
memory use is high, your Wunderdawg™ will go to sleep using minimum
memory until it's safe to play again!"

[Darrius Gothly]

Pardon me if I'm just restating the obvious, but I just want to be sure I
understand what you're saying.

It really doesn't matter how the limits are set, the real thrust of these
ideas is that a Sim is not always equally loaded. Because of visiting
patterns of the residents and guests, at any one time the population on the
sim is concentrated .. usually in one parcel. When the other parcels are
empty, that one should get to use all available SIM resources. When others
come back into their own parcel, they can reclaim what's "theirs" just by
entering (and using some formula yet to work out).

If this is what you're saying then yes, I agree 100%.

[Argent Stonecutter]

On 2009-12-18, at 06:54, Darrius Gothly wrote:
> It really doesn't matter how the limits are set, the real thrust of
> these ideas is that a Sim is not always equally loaded. Because of
> visiting patterns of the residents and guests, at any one time the
> population on the sim is concentrated .. usually in one parcel. When
> the other parcels are empty, that one should get to use all
> available SIM resources. When others come back into their own
> parcel, they can reclaim what's "theirs" just by entering (and using
> some formula yet to work out).
>
> If this is what you're saying then yes, I agree 100%.

I don't know about 100%, but they should be able to use more than a
strict fraction of the available resources.

This shouldn't depend on who's in the parcel, or the sim, because SL
is a world of scripts as well as people, and if you're not using more
than your "hard limit" of resources you should be able to continue
doing so, whether you're there or not.

[Argent Stonecutter]

On 2009-12-17, at 09:17, Ambrosia wrote:
> Quite frankly, the only thing that makes sense for scripters and
> content creators are hard numbers they can work with. Fixed memory
> amounts.

Nah, a soft limit applied only when the sim is below 75%, and a hard
limit applied when the sim is stressed, is still pretty easy to
understand and much more practical for the spotty distribution of
scripts in SL.

If you keep your parcel below the soft limit, you would be guaranteed
resources. If you let it go over the soft limit, you would risk having
scripted objects returned. Maybe even have a landowner switch to allow
overcommitment on the parcel, so people running sandboxes and the like
could control it.

[Argent Stonecutter]

On 2009-12-17, at 08:37, Tigro Spottystripes wrote:
> But the limits should only be enforced when necessary, if there is a
> bunch of scripts in a 4x4 parcel and nothing else int he rest of the
> sim
> those scripts can use up all the sim script memory, if an avatar comes
> in, then the avaiablememory is divided between the parcel and the
> avatar, things like that

THe scaled overcommitment scheme I suggested over a year ago would
work well for this:

If the sim as a whole is over 75% of the limit, all parcels would be
restricted to strict limits.

Below that, scale it so that (for example) 50% of the sim could have
up to 80% of the limit, 25% of the sim could have up to 60% of the
limit, 12.5% could have 40%, and so on. The actual numbers would have
to be tuned, but this would allow you to have a party on your 512 in
an otherwise empty sim without blowing the parcel limits with the
dance balls, and without allowing a DOS.

You'd be able to tell if your parcel was over the soft limit, so you
could keep from having your pet dog frozen if someone else pushed the
sim over 75%.

[Aleric Inglewood]

On Fri, Dec 18, 2009 at 05:52:26AM -0600, Argent Stonecutter wrote:
> If the sim as a whole is over 75% of the limit, all parcels would be
> restricted to strict limits.

That is instable, you shouldn't shift the limit in a way that
it can start oscillating. Also, it won't solve my problem with
the "chick-shoot game":

Given, a region with 10 residents that are only there 1 hour
per day and seldom at the same time. Each resident uses a fixed
amount of scripts 24/7 but also keeps a reserve for own use,
for temporary events (like shooting chickens, say).

If any residents wants to start shooting chickens, they should
be able to use all available memory (for as long as it is available).
The "temporary use" reserve allows for -say- 100 chickens to be
rezzed.

Under the new system, only 10 chickens could be rezzed at any
time, because it keeps a reserve reserved for each and every
resident, just in case they might suddenly want to play this
game all at the same time in their own parcel (nonsense thus,
which is why this proposed system is so bad).
Your solution doesn't work either however: In your case I would
start rezzing chickens, and when I rez chicken 76, suddenly
the limits would kick in full force and 66 chickens would die,
only leaving 10 to run free. At that moment we'd be under the
75% again though, so my chicken rez object would start creating
new chickens again, until it again rezzes the 76th chicken...

> Below that, scale it so that (for example) 50% of the sim could have
> up to 80% of the limit, 25% of the sim could have up to 60% of the
> limit, 12.5% could have 40%, and so on. The actual numbers would have
> to be tuned, but this would allow you to have a party on your 512 in
> an otherwise empty sim without blowing the parcel limits with the
> dance balls, and without allowing a DOS.

Um, I cannot exactly follow this part ;)

Nevertheless, I applaude your ideas :)

THIS subject is what is the greatest fiasco with the new system.
Now if only the Lindens working on this were willing to admit it.

> You'd be able to tell if your parcel was over the soft limit, so you
> could keep from having your pet dog frozen if someone else pushed the
> sim over 75%.

I'm sure that the solution isn't simple. It's much easier to just
allocate a (very small) fixed amount for everyone and screw those
that complain about suddenly not being able anymore to do things
that were totally legal and good use of SL before.

[Da5id Kronfeld]

On 2009-12-18, at 4:10 AM, Aleric Inglewood wrote:

> On Fri, Dec 18, 2009 at 05:52:26AM -0600, Argent Stonecutter wrote:
>> If the sim as a whole is over 75% of the limit, all parcels would be
>> restricted to strict limits.
>
> That is instable, you shouldn't shift the limit in a way that
> it can start oscillating. Also, it won't solve my problem with
> the "chick-shoot game":

[cut]

> Your solution doesn't work either however: In your case I would
> start rezzing chickens, and when I rez chicken 76, suddenly
> the limits would kick in full force and 66 chickens would die,
> only leaving 10 to run free. At that moment we'd be under the
> 75% again though, so my chicken rez object would start creating
> new chickens again, until it again rezzes the 76th chicken...

While I'm still on the fence about dynamic limits, this oscillating effect can be mitigated by damping factor that doesn't allow the sim to return to an overcommitted state immediately following a script cull.

[Kelly Linden]

I'll be honest. I just really don't like the dynamic resource limits idea.
It is very neat and interesting in theory, and fun to design and discuss.
However I see a lot of value in knowing all my content will continue to work
and knowing what content I can use - In knowing that when I buy/rent/lease
land as part of that I am buying/renting/leasing a specific amount of
resources. I hate the idea of *any* of my content only sometimes working.

I place a high value on simplicity. I want to trivially understand where I
am, how much headroom I have, how close I am to what limits there are. I
don't want to code complex solutions with multiple behaviors based on the
state of the region. And yes, I know people already do this by monitoring
sim stats but it would be awesome if they didn't need to. "normal"
residents also need to understand these limits and be able to see where they
are. These limits will effect *everyone*, even if all you do is rent a
house and buy content to furnish it. You will need to know what will and
won't work and buying something that will sometimes work no matter what the
reasons is just going to be a nightmare. If I buy a fish tank it needs to
always work and always have fish and not have fish that sleep or disappear
when my neighbors decide it is chicken shooting time.

That said, I also understand the usage issues here, which mirror closely the
more generic web hosting problems. Resource usage patterns aren't equal or
consistent over time or space, this is obvious and known and is NOT
something we are ignoring. The general solution for web hosting is to
over-sell, rely on some rules of averages and be able to move things around
to accommodate users. Doing something similar is certainly a possibility,
and one I have pushed for. It isn't as trivial as just setting higher
numbers - we need to adjust and fix our infrastructure to more optimally
assign regions to hosts - but it is certainly not impossible, and indeed
such infrastructure changes would benefit everyone regardless.

Dynamic resource limits are just complicated by nature. They are fluid in
some respect, and they change based on time and usage - that is just what it
means. Unfortunately it is that nature that makes it hard to plan around
and hard to build content for and hard to understand. The system we use
needs to be as easy as prim limits are now, where you can see the cost of an
object and you can see how much you can support.

- Kelly

On Fri, Dec 18, 2009 at 9:13 AM, Da5id Kronfeld <da5idkronfeld-***@public.gmane.org>wrote:

>
> On 2009-12-18, at 4:10 AM, Aleric Inglewood wrote:
>
> > On Fri, Dec 18, 2009 at 05:52:26AM -0600, Argent Stonecutter wrote:
> >> If the sim as a whole is over 75% of the limit, all parcels would be
> >> restricted to strict limits.
> >
> > That is instable, you shouldn't shift the limit in a way that
> > it can start oscillating. Also, it won't solve my problem with
> > the "chick-shoot game":
>
> [cut]
>
> > Your solution doesn't work either however: In your case I would
> > start rezzing chickens, and when I rez chicken 76, suddenly
> > the limits would kick in full force and 66 chickens would die,
> > only leaving 10 to run free. At that moment we'd be under the
> > 75% again though, so my chicken rez object would start creating
> > new chickens again, until it again rezzes the 76th chicken...
>
> While I'm still on the fence about dynamic limits, this oscillating effect
> can be mitigated by damping factor that doesn't allow the sim to return to
> an overcommitted state immediately following a script cull.
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting
> privileges
>

[Da5id Kronfeld]

On 2009-12-18, at 10:13 AM, Kelly Linden wrote:

> I'll be honest. I just really don't like the dynamic resource limits idea. It is very neat and interesting in theory, and fun to design and discuss. However I see a lot of value in knowing all my content will continue to work and knowing what content I can use - In knowing that when I buy/rent/lease land as part of that I am buying/renting/leasing a specific amount of resources. I hate the idea of *any* of my content only sometimes working.

[ cut ]

> That said, I also understand the usage issues here, which mirror closely the more generic web hosting problems. Resource usage patterns aren't equal or consistent over time or space, this is obvious and known and is NOT something we are ignoring. The general solution for web hosting is to over-sell, rely on some rules of averages and be able to move things around to accommodate users. Doing something similar is certainly a possibility, and one I have pushed for. It isn't as trivial as just setting higher numbers - we need to adjust and fix our infrastructure to more optimally assign regions to hosts - but it is certainly not impossible, and indeed such infrastructure changes would benefit everyone regardless.
>
> Dynamic resource limits are just complicated by nature. They are fluid in some respect, and they change based on time and usage - that is just what it means. Unfortunately it is that nature that makes it hard to plan around and hard to build content for and hard to understand. The system we use needs to be as easy as prim limits are now, where you can see the cost of an object and you can see how much you can support.
>
> - Kelly

I tend to agree. I will also point out that aside from the complicated nature ( and unpredictable behaviour ) that dynamic limits generally imply, there is also the trend toward circumvention that has to be considered. In any system where the opportunity exists, people will find ways to "game" the system. Consider temp prims and the devices that people have devised in order to increase the effective number of prims they can use.

I also agree with Kelly's desire for predictable behaviour. Creating a situation in which content may suddenly stop working because of what other content is doing is an invitation to disaster. Non-technical users will not understand ( and shouldn't have to understand ) the way in which things work. My experience is that predictable lower limits are a *much* easier sell then unpredictable higher ones, because they make sense to the masses. If LL wants to explore dynamic resource allocation, then it may be that that could be explored on a smaller scale after script limits are in place on the grid as a whole.

It's worth keeping in mind that we already have a system of "(sort of) graceful failure" in that script memory overcommitment leads to paging activity that degrades the sim performance as a whole. This is (mostly) annoying. I can't imagine a situation in which running content stops working arbitrarily (in the eyes of the average user) as being perceived as anything other than a badly broken grid.

[Carlo Wood]

On Fri, Dec 18, 2009 at 10:13:36AM -0800, Kelly Linden wrote:
> I place a high value on simplicity.  I want to trivially understand where I am,
> how much headroom I have, how close I am to what limits there are.  I don't

The swimming pool
-----------------

Once upon a time there was a swimming pool that costed $100 per day
to run. Every day 100 people came to swim. Of course, they didn't
come all at the same time, thank God no! Imagine that... you'd only
have 1/100th of the water to swim in! No, sometimes there were
a little more and sometimes there were a little less people.
Not everyone stayed 24 hours per day, after all.

One day, one of the customers complained to the management of
the swimming pool, saying "Last Wednesday I could swim in my
own lane, but today it's way too crowded to swim! I wish I could
see how many people are inside before I pay the entrance fee!"
and he looked really mad.

Now the manager, Mr.Kelly, was a smart man and he found quickly
a solution that everyone would understand, and after which everyone
would have precisely the same area to swim in no matter when they
would come! He said: Although there come 100 people every day,
I think that at the most busy moments of the say I've ever
only seen 30 at the same time. That number might be changed a bit,
but lets say that's the maximum. Then we can garantee that you
have the same area to swim in at every moment by giving you
1/30 of the swimming pool. From now on, even if the pool is
EMPTY... or when there are only 3 people like on Sunday mornings,
you are not allowed to use more than 1/30 of the swimming pool
area. This way we have solved the problem of those griefer
school kids too that come here with 100 kids at once, just to
obstruct and annoy the other swimmers: as soon as there are
really 30 people inside, we close the doors :).

And so, everyone was happy-- because now they knew that whenever
they came, they would have precisely 1/30 of the swimming pool...
Well, except for about 90% of the customers, who were used to
having MUCH more space normally, but they were quickly convinced
that they only PAID for 1/30 (after all the math was such that
nobody could argue here). And yeah, the entrence price remained
the same too. One year later the swimming pool was broke.

The End

--
Carlo Wood <carlo-A8X2UORpUyHQT0dZR+***@public.gmane.org>

[Kelly Linden]

Ooooh! I love the completely ridiculous analogy game! Can I play?

Carlo manages an apartment complex. After renting apartments for years out
to just single families he realizes that significant portions of his
building are empty and not being used for significant periods of the day.
He can make more money by renting to more people if he can fill up that
space. Given holidays, work, school, errands, entertainment etc each family
is probably only in their space for 50% of the time. Heck if you consider
it on a per room basis and take into account sleeping time, there is even
more unused space! So he rents each apartment out to 3 families, which
should totally be fine and he continues to charge and allocate the space as
if each family had their own apartment. After all there are enough rooms
for everyone, for the portion of the time they are probably home.

Of *course* this is ridiculous, and of *course* the swimming pool example is
ridiculous and of *course* the SL resource problem doesn't directly map to
either. Though I think it may be closer to the apartment case than the
swimming pool example. When you rent or lease land you aren't buying
entrance to a theme park or movie or swimming pool. You are buying space to
live or work or whatever. You want to know that your TV will work whenever
you want to use it and that your bed will be available to you. The pool
owner wants to know that his electricity and pool filtering and water supply
aren't tied to factors he can't control, and he wants to know that he can
support 30 swimmers whether the club across the street is open or not.

However as I have said before I don't think strict allocation of available
resources make sense either, because SL isn't an apartment building or a
swimming pool. In that very post you replied to I talked about overselling
and managing the hosts regions run on to keep regions happy. This I think
is a reasonable compromise that allows for a simple to understand system
that is easy to work with and plan with but doesn't overly sacrifice
available resources.

- Kelly

On Fri, Dec 18, 2009 at 3:55 PM, Carlo Wood <carlo-A8X2UORpUyHQT0dZR+***@public.gmane.org> wrote:

> On Fri, Dec 18, 2009 at 10:13:36AM -0800, Kelly Linden wrote:
> > I place a high value on simplicity. I want to trivially understand where
> I am,
> > how much headroom I have, how close I am to what limits there are. I
> don't
>
> The swimming pool
> -----------------
>
> Once upon a time there was a swimming pool that costed $100 per day
> to run. Every day 100 people came to swim. Of course, they didn't
> come all at the same time, thank God no! Imagine that... you'd only
> have 1/100th of the water to swim in! No, sometimes there were
> a little more and sometimes there were a little less people.
> Not everyone stayed 24 hours per day, after all.
>
> One day, one of the customers complained to the management of
> the swimming pool, saying "Last Wednesday I could swim in my
> own lane, but today it's way too crowded to swim! I wish I could
> see how many people are inside before I pay the entrance fee!"
> and he looked really mad.
>
> Now the manager, Mr.Kelly, was a smart man and he found quickly
> a solution that everyone would understand, and after which everyone
> would have precisely the same area to swim in no matter when they
> would come! He said: Although there come 100 people every day,
> I think that at the most busy moments of the say I've ever
> only seen 30 at the same time. That number might be changed a bit,
> but lets say that's the maximum. Then we can garantee that you
> have the same area to swim in at every moment by giving you
> 1/30 of the swimming pool. From now on, even if the pool is
> EMPTY... or when there are only 3 people like on Sunday mornings,
> you are not allowed to use more than 1/30 of the swimming pool
> area. This way we have solved the problem of those griefer
> school kids too that come here with 100 kids at once, just to
> obstruct and annoy the other swimmers: as soon as there are
> really 30 people inside, we close the doors :).
>
> And so, everyone was happy-- because now they knew that whenever
> they came, they would have precisely 1/30 of the swimming pool...
> Well, except for about 90% of the customers, who were used to
> having MUCH more space normally, but they were quickly convinced
> that they only PAID for 1/30 (after all the math was such that
> nobody could argue here). And yeah, the entrence price remained
> the same too. One year later the swimming pool was broke.
>
> The End
>
> --
> Carlo Wood <carlo-A8X2UORpUyHQT0dZR+***@public.gmane.org>
>

[Tigro Spottystripes]

Can't the sim code be made multithreaded and have scripts that are using
more memory than is avaiable be moved to a sepárated thread that runs on
virtual ram only, so people can have fast memory hogs if there is enough
memory left, but if other scripts need it, the memory hogs get
downgraded to slower mode and don't use the physical ram, nor get in the
way of other things in the sim. ?
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posting

[Dzonatas Sol]

Maybe some way to flag a script as "phantom" like how objects are
phantom where they become independent of the phsyics engine and as such
the scripts become independent of the the usual simulator loop/affinity.

Phantom scripts would not have to be copied from sim to sim. The could
exist entirely a server just for phantom scripts.

Tigro Spottystripes wrote:
> Can't the sim code be made multithreaded and have scripts that are using
> more memory than is avaiable be moved to a sepárated thread that runs on
> virtual ram only, so people can have fast memory hogs if there is enough
> memory left, but if other scripts need it, the memory hogs get
> downgraded to slower mode and don't use the physical ram, nor get in the
> way of other things in the sim. ?
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting privileges

_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated p

[Imaze Rhiano]

This is basically what is happening currently when scripts in SIM are
using more memory than SIM have available - it starts swapping memory to
file. And because this is slow - it will lead to ebil lag monsters.

Problem with "moving scripts that are using more memory available" is
problematic - like how you decide what script is using too much memory?
And if you can detect - how you decide what scripts from those "bad
scripts" are moved to slower "lag" thread?

Tigro Spottystripes kirjoitti:
> Can't the sim code be made multithreaded and have scripts that are using
> more memory than is avaiable be moved to a sepárated thread that runs on
> virtual ram only, so people can have fast memory hogs if there is enough
> memory left, but if other scripts need it, the memory hogs get
> downgraded to slower mode and don't use the physical ram, nor get in the
> way of other things in the sim. ?
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting privileges

_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posti

[Carlo Wood]

On Sat, Dec 19, 2009 at 02:56:27PM +0200, Imaze Rhiano wrote:
> This is basically what is happening currently when scripts in SIM are
> using more memory than SIM have available - it starts swapping memory to
> file. And because this is slow - it will lead to ebil lag monsters.

Huh? Why do you say that it is the same? Seems totally different to me.

> Problem with "moving scripts that are using more memory available" is
> problematic - like how you decide what script is using too much memory?
> And if you can detect - how you decide what scripts from those "bad
> scripts" are moved to slower "lag" thread?
>
> Tigro Spottystripes kirjoitti:
> > Can't the sim code be made multithreaded and have scripts that are using
> > more memory than is avaiable be moved to a sepárated thread that runs on
> > virtual ram only, so people can have fast memory hogs if there is enough
> > memory left, but if other scripts need it, the memory hogs get
> > downgraded to slower mode and don't use the physical ram, nor get in the
> > way of other things in the sim. ?
> > _______________________________________________
> > Policies and (un)subscribe information available here:
> > http://wiki.secondlife.com/wiki/SLDev
> > Please read the policies before posting to keep unmoderated posting privileges
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting privileges

--
Carlo Wood <carlo-A8X2UORpUyHQT0dZR+***@public.gmane.org>

[Tigro Spottystripes]

Scripts that individually are using more memory than the maximum
guaranteed, and scripts that have been added after enough scripts with
the minimum guaranteed have already been added tot he parcel go to the
separated slow mode. Scripts in the slow mode that are using the least
memory bellow the maximum guranteed have priority for being upgraded
back to fast mode when enough memory for it has been released in the parcel.


Imaze Rhiano escreveu:
> This is basically what is happening currently when scripts in SIM are
> using more memory than SIM have available - it starts swapping memory
> to file. And because this is slow - it will lead to ebil lag monsters.
>
> Problem with "moving scripts that are using more memory available" is
> problematic - like how you decide what script is using too much
> memory? And if you can detect - how you decide what scripts from those
> "bad scripts" are moved to slower "lag" thread?
>
> Tigro Spottystripes kirjoitti:
>> Can't the sim code be made multithreaded and have scripts that are using
>> more memory than is avaiable be moved to a sepárated thread that runs on
>> virtual ram only, so people can have fast memory hogs if there is enough
>> memory left, but if other scripts need it, the memory hogs get
>> downgraded to slower mode and don't use the physical ram, nor get in the
>> way of other things in the sim. ?
>> _______________________________________________
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/SLDev
>> Please read the policies before posting to keep unmoderated posting
>> privileges
>
>

_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated posting pri

[Tigro Spottystripes]

This would be a mostly ideal solution since no script would stop
working, and scripts that currently lag everything (either due to the
scripter coding it to use lots of memory, or due to people placing more
scripts in the parcel than the RAM quota of the parcel) would only lag
each other, and when memory is freed scripts would once again be
promoted back to fast mode.

Ideally scripts by parcel owner would have priority over scripts from
visitors in regards to RAM usage.

If the parcels in the rest of the sim aren't needing the memory, more
RAM is avaiable to the parcel at the moment, and more scripts in that
parcel can be using RAM, same thing with avatars.

If scripts on an avatar are using more memory than is avaiable on the
sim, beyond the maximum guaranteed per avatar, some of the scripts will
be downgraded to slowmode, like with parcel scripts, the scripts that
use more memory and the scripts that came in last after the maximum
guaranteed has been used up get downgraded first. If someone wants to
have all the scripts on their avatar never be downgraded, they should
make sure they never get past the maximum guaranteed RAM quota per
avatar. But there won't be need to worry about scripts crashing or
objects de-rezzing due to lack of memory.


Both scripts and users hsould be capable of checking how much memory is
avvaiable int he sim, int he parcel,a nd for their own avatar, and the
maximum guaranteed for parcels and sims would just be dependent on some
simple value, like maximum allowed primcount, a value that would usually
be static inmost places, but not fixed since in some places people can
use more prims than in other places (opem space sims, parcels with prim
bonus etc), the maximum per avatar would depend on sim type and the
maximum number of avs in the sim. Ideally all the info woud be easy for
both scritps and users to find, though even though it is less ideal, it
would still be reasonably acceptable if the general guidelines to
calculating the value were made avaiable instead of the actual values in
each situation.



Lear Cale escreveu:
> While it's a good idea in theory, I doubt that's practical to
> implement at this time.
>
> Also, it has the problem of hysteresis: you get different results
> depending on the order in which things happen. That usually leads to
> unpredicted issues.
>
> On Sat, Dec 19, 2009 at 12:46 PM, Tigro Spottystripes
> <tigrospottystripes-***@public.gmane.org <mailto:tigrospottystripes-***@public.gmane.org>>
> wrote:
>
> Scripts that individually are using more memory than the maximum
> guaranteed, and scripts that have been added after enough scripts with
> the minimum guaranteed have already been added tot he parcel go to the
> separated slow mode. Scripts in the slow mode that are using the least
> memory bellow the maximum guranteed have priority for being upgraded
> back to fast mode when enough memory for it has been released in
> the parcel.
>

[Ann Otoole]

We could fast forward to the future reality...

Now that more people that need to be aware of the issue at hand are aware of this project then over the next year a lot of problematic scripts will be reworked (especially where the new functions are relevant). So by the time script limits are implemented they will no longer be so direly needed. However they are still needed for the edge case and intentional resource abusers. But overall the vast majority will most likely never be affected at all and many new residents acquiring the better scripts may never even know the limits exist.

The double plus is that with the limits the system capacity can be better planned and scaled.

That reminds me that I need to go delete that box of n number of free scripts that mostly includes junk that won't even run anymore. Elimination of bad examples to go by/learn from would go miles for improving things overall.

[Imaze Rhiano]

I fully agree with Kelly here.

People are buying their parcel to get certain guaranteed amount of
primitives and space from virtual world for their use. Same way people
want to get certain guaranteed amount of memory for their scripts for
their use. They don't want their landlord comes to say that they can use
that swimming pool for their activity - but they need to share it with
sexists neighbors. No - they want their own private swimming pool.

Other fact is that people are stupid. Fixed memory limits would be most
easily understood by average Joe and Jane. They really don't want to use
their head to calculate how many scripts they can deploy to their parcel
before hitting to boundaries. Keep it simple and stupid.

However - same time - they should be some configuration available.
Landlords should be either able to decide memory limits for each parcel
- or - use similar system that allows current double primitive parcels.
If this kind configuration is not available- then we will quickly see
how landlord convert their current double primitive estates to normal
primitive estates and remove all streets and other "community" parcels
from their estates.

... and I agree with bloooo kitty that fixed memory limits are not
scalable solution - however - Scripted Life (tm) architecture is not
scalable anyway - so who cares? :P

Kelly Linden kirjoitti:
> Ooooh! I love the completely ridiculous analogy game! Can I play?
>
> Carlo manages an apartment complex. After renting apartments for
> years out to just single families he realizes that significant
> portions of his building are empty and not being used for significant
> periods of the day. He can make more money by renting to more people
> if he can fill up that space. Given holidays, work, school, errands,
> entertainment etc each family is probably only in their space for 50%
> of the time. Heck if you consider it on a per room basis and take
> into account sleeping time, there is even more unused space! So he
> rents each apartment out to 3 families, which should totally be fine
> and he continues to charge and allocate the space as if each family
> had their own apartment. After all there are enough rooms for
> everyone, for the portion of the time they are probably home.
>
> Of *course* this is ridiculous, and of *course* the swimming pool
> example is ridiculous and of *course* the SL resource problem doesn't
> directly map to either. Though I think it may be closer to the
> apartment case than the swimming pool example. When you rent or lease
> land you aren't buying entrance to a theme park or movie or swimming
> pool. You are buying space to live or work or whatever. You want to
> know that your TV will work whenever you want to use it and that your
> bed will be available to you. The pool owner wants to know that his
> electricity and pool filtering and water supply aren't tied to factors
> he can't control, and he wants to know that he can support 30 swimmers
> whether the club across the street is open or not.
>
> However as I have said before I don't think strict allocation of
> available resources make sense either, because SL isn't an apartment
> building or a swimming pool. In that very post you replied to I
> talked about overselling and managing the hosts regions run on to keep
> regions happy. This I think is a reasonable compromise that allows
> for a simple to understand system that is easy to work with and plan
> with but doesn't overly sacrifice available resources.
>
> - Kelly
>
> On Fri, Dec 18, 2009 at 3:55 PM, Carlo Wood <carlo-A8X2UORpUyHQT0dZR+***@public.gmane.org
> <mailto:carlo-A8X2UORpUyHQT0dZR+***@public.gmane.org>> wrote:
>
> On Fri, Dec 18, 2009 at 10:13:36AM -0800, Kelly Linden wrote:
> > I place a high value on simplicity. I want to trivially
> understand where I am,
> > how much headroom I have, how close I am to what limits there
> are. I don't
>
> The swimming pool
> -----------------
>
> Once upon a time there was a swimming pool that costed $100 per day
> to run. Every day 100 people came to swim. Of course, they didn't
> come all at the same time, thank God no! Imagine that... you'd only
> have 1/100th of the water to swim in! No, sometimes there were
> a little more and sometimes there were a little less people.
> Not everyone stayed 24 hours per day, after all.
>
> One day, one of the customers complained to the management of
> the swimming pool, saying "Last Wednesday I could swim in my
> own lane, but today it's way too crowded to swim! I wish I could
> see how many people are inside before I pay the entrance fee!"
> and he looked really mad.
>
> Now the manager, Mr.Kelly, was a smart man and he found quickly
> a solution that everyone would understand, and after which everyone
> would have precisely the same area to swim in no matter when they
> would come! He said: Although there come 100 people every day,
> I think that at the most busy moments of the say I've ever
> only seen 30 at the same time. That number might be changed a bit,
> but lets say that's the maximum. Then we can garantee that you
> have the same area to swim in at every moment by giving you
> 1/30 of the swimming pool. From now on, even if the pool is
> EMPTY... or when there are only 3 people like on Sunday mornings,
> you are not allowed to use more than 1/30 of the swimming pool
> area. This way we have solved the problem of those griefer
> school kids too that come here with 100 kids at once, just to
> obstruct and annoy the other swimmers: as soon as there are
> really 30 people inside, we close the doors :).
>
> And so, everyone was happy-- because now they knew that whenever
> they came, they would have precisely 1/30 of the swimming pool...
> Well, except for about 90% of the customers, who were used to
> having MUCH more space normally, but they were quickly convinced
> that they only PAID for 1/30 (after all the math was such that
> nobody could argue here). And yeah, the entrence price remained
> the same too. One year later the swimming pool was broke.
>
> The End
>
> --
> Carlo Wood <carlo-A8X2UORpUyHQT0dZR+***@public.gmane.org <mailto:carlo-A8X2UORpUyHQT0dZR+***@public.gmane.org>>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting privileges

[Carlo Wood]

On Sat, Dec 19, 2009 at 03:24:19PM +0200, Imaze Rhiano wrote:
> I fully agree with Kelly here.

That's sad, cause what you're saying is that you agree
to pay the same for 1/10 of what you could use before
in practise. Sorry, I don't see the logic in that.

Considering that the price of a sim will remain the same,
this whole thing would only be fair if the amount of memory
in every server is increased with a few Gigabytes (without
increasing the price thus).

> People are buying their parcel to get certain guaranteed amount of
> primitives and space from virtual world for their use.

Huh?? Why on earth do you think that?
I did *NOT* rent my sim to get a "garanteed amount of memory"
that is 1/10th of what I can use NOW on average. I did rent the
sim for the money it costs BECAUSE it's a fact that normally
the other residents are not there; I rented it BECAUSE residents
are only 1 to 2 hours per day on the sim and THUS that for that
money I get a FULL sim for myself (if I'm alone).

I calculated that in. If anyone did not calculate that in and
assumed they'd only be getting 1/10th of the server capacity
AND only use it 1/10 of the day, then why the hell do they
agree to pay a sum that equals renting a real, complete, rack server?

No sorry, but LL is just trying to rip us off: let everyone
pay for the full rack server, and once this all rolls start
to over-sell it by a factor of five (ie, by running all servers
virtually on 1/5th of the hardware; that is actually going
to work with these new rules). And don't you think that the prices
will go down. Imho, this one just another sign that LL understands
it's dieing and is just trying to increase it's profits as
much as possible before that actually happens.

> Same way people
> want to get certain guaranteed amount of memory for their scripts for
> their use. They don't want their landlord comes to say that they can use
> that swimming pool for their activity - but they need to share it with
> sexists neighbors. No - they want their own private swimming pool.
>
> Other fact is that people are stupid. Fixed memory limits would be most
> easily understood by average Joe and Jane. They really don't want to use
> their head to calculate how many scripts they can deploy to their parcel
> before hitting to boundaries. Keep it simple and stupid.

Why not apply that reasoning to the physics engine and get rid of it?
Nobody understands how you can write realistic vehicles for a reason:
it's way to hard (and not really possible to begin with with all the
usual lag). That physics engine is only using cpu time, that we have
pay for, but it's useless the way it is: Joe and Jane will NEVER be
able to write a script that uses it; I certainly have never seen
any satisfactory working physical objects beyond a soccer ball.

> However - same time - they should be some configuration available.
> Landlords should be either able to decide memory limits for each parcel
> - or - use similar system that allows current double primitive parcels.
> If this kind configuration is not available- then we will quickly see
> how landlord convert their current double primitive estates to normal
> primitive estates and remove all streets and other "community" parcels
> from their estates.
>
> ... and I agree with bloooo kitty that fixed memory limits are not
> scalable solution - however - Scripted Life (tm) architecture is not
> scalable anyway - so who cares? :P
>
> Kelly Linden kirjoitti:
> > Ooooh! I love the completely ridiculous analogy game! Can I play?
> >
> > Carlo manages an apartment complex. After renting apartments for
> > years out to just single families he realizes that significant
> > portions of his building are empty and not being used for significant
> > periods of the day. He can make more money by renting to more people
> > if he can fill up that space. Given holidays, work, school, errands,
> > entertainment etc each family is probably only in their space for 50%
> > of the time. Heck if you consider it on a per room basis and take
> > into account sleeping time, there is even more unused space! So he
> > rents each apartment out to 3 families, which should totally be fine
> > and he continues to charge and allocate the space as if each family
> > had their own apartment. After all there are enough rooms for
> > everyone, for the portion of the time they are probably home.
> >
> > Of *course* this is ridiculous, and of *course* the swimming pool
> > example is ridiculous and of *course* the SL resource problem doesn't
> > directly map to either. Though I think it may be closer to the
> > apartment case than the swimming pool example. When you rent or lease
> > land you aren't buying entrance to a theme park or movie or swimming
> > pool. You are buying space to live or work or whatever. You want to
> > know that your TV will work whenever you want to use it and that your
> > bed will be available to you. The pool owner wants to know that his
> > electricity and pool filtering and water supply aren't tied to factors
> > he can't control, and he wants to know that he can support 30 swimmers
> > whether the club across the street is open or not.
> >
> > However as I have said before I don't think strict allocation of
> > available resources make sense either, because SL isn't an apartment
> > building or a swimming pool. In that very post you replied to I
> > talked about overselling and managing the hosts regions run on to keep
> > regions happy. This I think is a reasonable compromise that allows
> > for a simple to understand system that is easy to work with and plan
> > with but doesn't overly sacrifice available resources.
> >
> > - Kelly
> >
> > On Fri, Dec 18, 2009 at 3:55 PM, Carlo Wood <carlo-A8X2UORpUyHQT0dZR+***@public.gmane.org
> > <mailto:carlo-A8X2UORpUyHQT0dZR+***@public.gmane.org>> wrote:
> >
> > On Fri, Dec 18, 2009 at 10:13:36AM -0800, Kelly Linden wrote:
> > > I place a high value on simplicity. I want to trivially
> > understand where I am,
> > > how much headroom I have, how close I am to what limits there
> > are. I don't
> >
> > The swimming pool
> > -----------------
> >
> > Once upon a time there was a swimming pool that costed $100 per day
> > to run. Every day 100 people came to swim. Of course, they didn't
> > come all at the same time, thank God no! Imagine that... you'd only
> > have 1/100th of the water to swim in! No, sometimes there were
> > a little more and sometimes there were a little less people.
> > Not everyone stayed 24 hours per day, after all.
> >
> > One day, one of the customers complained to the management of
> > the swimming pool, saying "Last Wednesday I could swim in my
> > own lane, but today it's way too crowded to swim! I wish I could
> > see how many people are inside before I pay the entrance fee!"
> > and he looked really mad.
> >
> > Now the manager, Mr.Kelly, was a smart man and he found quickly
> > a solution that everyone would understand, and after which everyone
> > would have precisely the same area to swim in no matter when they
> > would come! He said: Although there come 100 people every day,
> > I think that at the most busy moments of the say I've ever
> > only seen 30 at the same time. That number might be changed a bit,
> > but lets say that's the maximum. Then we can garantee that you
> > have the same area to swim in at every moment by giving you
> > 1/30 of the swimming pool. From now on, even if the pool is
> > EMPTY... or when there are only 3 people like on Sunday mornings,
> > you are not allowed to use more than 1/30 of the swimming pool
> > area. This way we have solved the problem of those griefer
> > school kids too that come here with 100 kids at once, just to
> > obstruct and annoy the other swimmers: as soon as there are
> > really 30 people inside, we close the doors :).
> >
> > And so, everyone was happy-- because now they knew that whenever
> > they came, they would have precisely 1/30 of the swimming pool...
> > Well, except for about 90% of the customers, who were used to
> > having MUCH more space normally, but they were quickly convinced
> > that they only PAID for 1/30 (after all the math was such that
> > nobody could argue here). And yeah, the entrence price remained
> > the same too. One year later the swimming pool was broke.
> >
> > The End
> >
> > --
> > Carlo Wood <carlo-A8X2UORpUyHQT0dZR+***@public.gmane.org <mailto:carlo-A8X2UORpUyHQT0dZR+***@public.gmane.org>>
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Policies and (un)subscribe information available here:
> > http://wiki.secondlife.com/wiki/SLDev
> > Please read the policies before posting to keep unmoderated posting privileges
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting privileges

--
Carlo Wood <carlo-A8X2UORpUyHQT0dZR+***@public.gmane.org>

[Lear Cale]

>
> I fully agree with Kelly here.
>
I agree also, if I understand correctly.

Today, there's a rather high limit that, if exceeded, causes severe
thrashing. Most servers are below that limit, and not thrashing. If the
new limits cut in well before that thrashing limit, but also well above
typical usage levels, things should be good.

The problem is the swimming pool analogy, which is germane, if limited by
showing only one side of the issue. However, if the limits are high enough,
the hardest-hit residents will be those with the smallest parcels who are
relying on very low script usage of their neighbors. Yeah, that'll be a
bummer, but as I see it, any solution to this raises more problems than it
solves.

Another problem is that, given a fixed budget, people will tend to use up
that budget. To address this, I suggest we have two levels; when going over
the recommended level the parcel tools signal "yellow" but no limiting is in
force. The higher limit is enforced. Sure, many will simply ignore the
yellow, but many won't, and it'll be a clear signal about what is considered
safe and healthy. Those with smaller parcels will be less likely to heed
the color; those with larger ones are far more likely to since their impact
on the whole is greater -- they're more likely to shoot themselves in the
foot, so they'll be more likely to use a trigger guard. It would send a
useful message.

Argent argues for a bonus for smaller parcels. We should seriously consider
allocating the difference between reasonable levels and critical levels to
smaller parcels. This bonus could be calculated assuming all 512 parcels --
dividing the total difference by 65536/512 to calculate a per-parcel bonus,
applied regardless of parcel size. It would be insignificant for
full-region parcels, but substantial for 512's. The bonus might need to be
reduced proportionately for parcels smaller than 512, to avoid catastrophic
overcommitment in regions with lots of tiny parcels.

[Carlo Wood]

On Sat, Dec 19, 2009 at 12:27:27PM -0500, Lear Cale wrote:
> Argent argues for a bonus for smaller parcels. We should seriously consider
> allocating the difference between reasonable levels and critical levels to
> smaller parcels. This bonus could be calculated assuming all 512 parcels --
> dividing the total difference by 65536/512 to calculate a per-parcel bonus,
> applied regardless of parcel size. It would be insignificant for full-region
> parcels, but substantial for 512's. The bonus might need to be reduced
> proportionately for parcels smaller than 512, to avoid catastrophic
> overcommitment in regions with lots of tiny parcels.

That kind of reasoning might be relevant for mainland, but I'd
have nothing of it for private sims. It should be the region owner
who decides how to devide the resources.

I guess that the limits will be activated at least a year before
necessary tools for sim owners though...

I hope that there will be some way to turn as much of the effect of
limits off, by the Estate Managers, if they want to do so. Even with
"tricks" (but I guess even with that LL won't be willing to help).

It seems that there will be some kind of bonus system, so hopefully
I can use that to give every parcel the right to use all available
memory... then we'll only loose the memory of the 20 avatars with
maximum attachment scripts that are never ever ever ever ever there.

--
Carlo Wood <carlo-A8X2UORpUyHQT0dZR+***@public.gmane.org>

[Tigro Spottystripes]

a perparcel bonus could be abused by spliting your parcel into a bunch
of small ones....


Carlo Wood escreveu:
> On Sat, Dec 19, 2009 at 12:27:27PM -0500, Lear Cale wrote:
>
>> Argent argues for a bonus for smaller parcels. We should seriously consider
>> allocating the difference between reasonable levels and critical levels to
>> smaller parcels. This bonus could be calculated assuming all 512 parcels --
>> dividing the total difference by 65536/512 to calculate a per-parcel bonus,
>> applied regardless of parcel size. It would be insignificant for full-region
>> parcels, but substantial for 512's. The bonus might need to be reduced
>> proportionately for parcels smaller than 512, to avoid catastrophic
>> overcommitment in regions with lots of tiny parcels.
>>
>
> That kind of reasoning might be relevant for mainland, but I'd
> have nothing of it for private sims. It should be the region owner
> who decides how to devide the resources.
>
> I guess that the limits will be activated at least a year before
> necessary tools for sim owners though...
>
> I hope that there will be some way to turn as much of the effect of
> limits off, by the Estate Managers, if they want to do so. Even with
> "tricks" (but I guess even with that LL won't be willing to help).
>
> It seems that there will be some kind of bonus system, so hopefully
> I can use that to give every parcel the right to use all available
> memory... then we'll only loose the memory of the 20 avatars with
> maximum attachment scripts that are never ever ever ever ever there.
>
>

[Lear Cale]

Keep in mind that script memory is per server, not per region, so it's not
up to a region owner to decide what the safe limit is for the region: they
shouldn't be able to overallocate and hose the regions that share the
server. However, if LL wants to give Region owners the ability to adjust
the policy without going over the region's allotment, fine.

On Sat, Dec 19, 2009 at 1:40 PM, Carlo Wood <carlo-A8X2UORpUyHQT0dZR+***@public.gmane.org> wrote:

> On Sat, Dec 19, 2009 at 12:27:27PM -0500, Lear Cale wrote:
> > Argent argues for a bonus for smaller parcels. We should seriously
> consider
> > allocating the difference between reasonable levels and critical levels
> to
> > smaller parcels. This bonus could be calculated assuming all 512 parcels
> --
> > dividing the total difference by 65536/512 to calculate a per-parcel
> bonus,
> > applied regardless of parcel size. It would be insignificant for
> full-region
> > parcels, but substantial for 512's. The bonus might need to be reduced
> > proportionately for parcels smaller than 512, to avoid catastrophic
> > overcommitment in regions with lots of tiny parcels.
>
> That kind of reasoning might be relevant for mainland, but I'd
> have nothing of it for private sims. It should be the region owner
> who decides how to devide the resources.
>
> I guess that the limits will be activated at least a year before
> necessary tools for sim owners though...
>
> I hope that there will be some way to turn as much of the effect of
> limits off, by the Estate Managers, if they want to do so. Even with
> "tricks" (but I guess even with that LL won't be willing to help).
>
> It seems that there will be some kind of bonus system, so hopefully
> I can use that to give every parcel the right to use all available
> memory... then we'll only loose the memory of the 20 avatars with
> maximum attachment scripts that are never ever ever ever ever there.
>
> --
> Carlo Wood <carlo-A8X2UORpUyHQT0dZR+***@public.gmane.org>
>

[Michael Schlenker]

Simplicity has its value, but as Einstein said: As simple as possible, but not simpler.

Setting a fixed limit per avatar/parcel makes things easily analyzable and safe, but obviously wastes a huge amount of resources on reserves. It is the perfect solution if you need 100% reliability and can afford the reserve memory to back it up for 'normal' use.

It would be really good if LL could provide some insight about the memory use of the servers in general, how much memory is used by scripts, how much is needed for physics, for avatar state, for textures, inventory etc. Script memory might be an easy target, because its very easy to implement a trivial control on VM memory limits, but is it the right target?

Probably LL does not yet know what kind of limits would be sane, because they simply do not have any good profiling data about it yet. Takes some time to track and collect the right data.

So, in fact there are a few issues here:
- LL wants to cut cost and increase utilization of its hardware
- Residents want to keep at least the same experience they have now, probably a better one
- Scripters want a reliable and working base upon which they can build

So, can we eat three cakes and keep all of them?

I think LL does a good thing with providing some tools to profile script costs. Not sure if those tools will be worth using, would be nice if some Linden could provide a short description of what kind of metrics we can expect (e.g. useless aggregated data with no timeline as we see it now in the debug panel for estate owners or fine grained profiling info down to individual functions of our scripts. Or maybe a special 'trace' mode for developers which want to analyze there scripts?). If your system does a good job like e.g. DTrace on Solaris or OS X, very good, if it does less, lets see how much less...

The second step, to provide more efficient script functions to do common tasks is also a great thing. Long overdue. Lets hope you kill some more warts of the language in the process. (how about some functions to override the built in animations with our own, so we do not need to have silly AOs lag the world while trying to win the race condition against your built in anims? Or how about a real timer queue instead of the simple timer event, where you simply register callback functions to be called at some time in the future (e.g. like Tcl's after command, including something like after idle to run code when the simulator isn't really too busy doing other stuff). Some persistent storage would also be quite nice, as i guess a lot of scripts that need much memory just use it to store data, lik
e logs, messages, but do not really need to have all of it in RAM (or swapped in).

But the third step, memory limits and enforcement are the part where you need to be really careful to not create just chaos.

Fixed limits are good, in general. They make things really reliable and ease planning, so thats good for both scripters and LL. But the drop in available capacity in the average case for residents makes it a really ugly solution. Works, but will either annoy a lot of residents or LLs cash balance (if they invested for the needed reserves to handle peak utilization gracefully).

Is there a reason why we only discuss script memory limits? How about textures, those must eat a lot of memory too? And how about memory sharing techniques? If you bitch about resizer scripts in every prim of a 100 prim hair, why not optimize memory sharing for those? If any of those would need more than about 512 Bytes real modifiable memory it would be just a case for bitching about the bad choice for the mono runtime. Maybe provide a 'const' keyword or some other way to allow more aggressive sharing of script resources and the whole case of 'excessive' amounts of identical scripts would nearly vanish with NO impact for residents or scripters. Might be a bit more complex for the people writing the server code, but well, its easier to higher some qualified people to fix the server code th
an it is to educated a few thousand scripters and a few million users.

Michael


Am 18.12.2009 um 19:13 schrieb Kelly Linden:

> I'll be honest. I just really don't like the dynamic resource limits idea. It is very neat and interesting in theory, and fun to design and discuss. However I see a lot of value in knowing all my content will continue to work and knowing what content I can use - In knowing that when I buy/rent/lease land as part of that I am buying/renting/leasing a specific amount of resources. I hate the idea of *any* of my content only sometimes working.
>
> I place a high value on simplicity. I want to trivially understand where I am, how much headroom I have, how close I am to what limits there are. I don't want to code complex solutions with multiple behaviors based on the state of the region. And yes, I know people already do this by monitoring sim stats but it would be awesome if they didn't need to. "normal" residents also need to understand these limits and be able to see where they are. These limits will effect *everyone*, even if all you do is rent a house and buy content to furnish it. You will need to know what will and won't work and buying something that will sometimes work no matter what the reasons is just going to be a nightmare. If I buy a fish tank it needs to always work and always have fish and not have fish that s
leep or disappear when my neighbors decide it is chicken shooting time.
>
> That said, I also understand the usage issues here, which mirror closely the more generic web hosting problems. Resource usage patterns aren't equal or consistent over time or space, this is obvious and known and is NOT something we are ignoring. The general solution for web hosting is to over-sell, rely on some rules of averages and be able to move things around to accommodate users. Doing something similar is certainly a possibility, and one I have pushed for. It isn't as trivial as just setting higher numbers - we need to adjust and fix our infrastructure to more optimally assign regions to hosts - but it is certainly not impossible, and indeed such infrastructure changes would benefit everyone regardless.
>
> Dynamic resource limits are just complicated by nature. They are fluid in some respect, and they change based on time and usage - that is just what it means. Unfortunately it is that nature that makes it hard to plan around and hard to build content for and hard to understand. The system we use needs to be as easy as prim limits are now, where you can see the cost of an object and you can see how much you can support.
>
> - Kelly

[Charlie Pegwell]

Hi Everyone, first post for me, although been reading this list for some
time :) I now post as I'm obviously missing something in the plans for
script limits!

Firstly, the plan seems logical to me.....

1. Each parcel has a set limit, we can all see how close to limit we are
- Sounds very much like prim limit to me :P
2. Each Avatar has a set limit - Hurrah, no more AV enters sim... sim
lags out for some minutes until they go....

So, I fail to see the problem with this.... at least until we really can
see the actual usage with the tools.... and then maybe we can argue with
added knowledge....

As for dynamic allocations....... If we did that, then why not do same
with prim limits ? Heh, this was probably argued before my time....
but clearly we manage ok within the prim limits set, so we can probably
cope with script limits per parcel too......

I do have one question, which I may have missed answers to before.....
How will a resident who has 23k left in their parcel know which of the 5
different security devices will run without issue on their parcel ?
Will we be able to see the memory usage somehow before purchase ? Or
will we/they have to rely on an honest vendor who is clearly stating
memory use on their packaging ?

Thanks for reading, and please don't shoot me down in flames unless you
provide a fluffy pillow to land on :)

Charlie.

[Imaze Rhiano]

Charlie Pegwell kirjoitti:
> So, I fail to see the problem with this.... at least until we really can
> see the actual usage with the tools.... and then maybe we can argue with
> added knowledge....
>
> As for dynamic allocations....... If we did that, then why not do same
> with prim limits ? Heh, this was probably argued before my time....
> but clearly we manage ok within the prim limits set, so we can probably
> cope with script limits per parcel too......
>
Ya! That is interesting question. I guess people have used to fixed
primitive limits - but not yet used to thinking about fixed memory.
> I do have one question, which I may have missed answers to before.....
> How will a resident who has 23k left in their parcel know which of the 5
> different security devices will run without issue on their parcel ?
> Will we be able to see the memory usage somehow before purchase ? Or
> will we/they have to rely on an honest vendor who is clearly stating
> memory use on their packaging ?
>
>
And that is REALLY good question! Currently how primitive counts
checking is done is that honest vendors allow us to count primitives by
previewing their goods. For example in good furniture shop, furnitures
are available for viewing and testing - and counting primitives is easy
then. However, in proposed system it is not possible to see how many
bytes of memory furniture is using in shop (or any object owned by
another resident).

Either we need new permission for objects "allow anyone to see memory
usage" or some kind parcel setting that allows anyone to see objects
memory usage. Also xstreet and other out-of-world marketplaces need to
update their systems so that vendors can list their products memory usage.

> Thanks for reading, and please don't shoot me down in flames unless you
> provide a fluffy pillow to land on :)
>
>
Flames? EEEK! I was prepared to poison/chemical/biological attack. I
don't think that wearing latex catsuit and gasmask is good idea then...

[Tigro Spottystripes]

I don't see any reason memory usage would need to be private, prim count
isn't.

Not all vendor and webmalls list things like prim count in an specific
field, do they? Sellers that want to brag about their products' memory
usage (or just be honest) can simply write it in the product description
in cases where there isn't an specific field for it.

Though inworld venders that rez the product for browsing might not have
the rezzed product fully working, specially in cases where it's just for
display and not trying it out (some stores might be trying to save sim
resources to all the vendors they have in place and have the products
deactivated ont he vendors that do display the product live)

Imaze Rhiano escreveu:
> Charlie Pegwell kirjoitti:
>
>> So, I fail to see the problem with this.... at least until we really can
>> see the actual usage with the tools.... and then maybe we can argue with
>> added knowledge....
>>
>> As for dynamic allocations....... If we did that, then why not do same
>> with prim limits ? Heh, this was probably argued before my time....
>> but clearly we manage ok within the prim limits set, so we can probably
>> cope with script limits per parcel too......
>>
>>
> Ya! That is interesting question. I guess people have used to fixed
> primitive limits - but not yet used to thinking about fixed memory.
>
>> I do have one question, which I may have missed answers to before.....
>> How will a resident who has 23k left in their parcel know which of the 5
>> different security devices will run without issue on their parcel ?
>> Will we be able to see the memory usage somehow before purchase ? Or
>> will we/they have to rely on an honest vendor who is clearly stating
>> memory use on their packaging ?
>>
>>
>>
> And that is REALLY good question! Currently how primitive counts
> checking is done is that honest vendors allow us to count primitives by
> previewing their goods. For example in good furniture shop, furnitures
> are available for viewing and testing - and counting primitives is easy
> then. However, in proposed system it is not possible to see how many
> bytes of memory furniture is using in shop (or any object owned by
> another resident).
>
> Either we need new permission for objects "allow anyone to see memory
> usage" or some kind parcel setting that allows anyone to see objects
> memory usage. Also xstreet and other out-of-world marketplaces need to
> update their systems so that vendors can list their products memory usage.
>
>
>> Thanks for reading, and please don't shoot me down in flames unless you
>> provide a fluffy pillow to land on :)
>>
>>
>>
> Flames? EEEK! I was prepared to poison/chemical/biological attack. I
> don't think that wearing latex catsuit and gasmask is good idea then...
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting privileges
>
>

[Darrius Gothly]

Umm .. is the memory usage a "Secret Number" that you should keep hidden? I
would think (hope) not.

----- Original Message -----
From: "Imaze Rhiano" <imaze.rhiano-***@public.gmane.org>

> And that is REALLY good question! Currently how primitive counts
> checking is done is that honest vendors allow us to count primitives by
> previewing their goods. For example in good furniture shop, furnitures
> are available for viewing and testing - and counting primitives is easy
> then. However, in proposed system it is not possible to see how many
> bytes of memory furniture is using in shop (or any object owned by
> another resident).

[Argent Stonecutter]

On 2009-12-18, at 12:13, Kelly Linden wrote:
> I'll be honest. I just really don't like the dynamic resource
> limits idea. It is very neat and interesting in theory, and fun to
> design and discuss. However I see a lot of value in knowing all my
> content will continue to work and knowing what content I can use -
> In knowing that when I buy/rent/lease land as part of that I am
> buying/renting/leasing a specific amount of resources. I hate the
> idea of *any* of my content only sometimes working.

I understand that, but on the other hand most parcels on most sims
have negligible numbers of scripts in them. If the hard and soft
limits are well defined and it's easy to see if you're over the
committed limit, it shouldn't be a problem. This gives you the
advantages of overselling, with a fallback if you your sim really is
pushing the limits.

[Argent Stonecutter]

On 2009-12-18, at 06:10, Aleric Inglewood wrote:
> Under the new system, only 10 chickens could be rezzed at any
> time, because it keeps a reserve reserved for each and every
> resident, just in case they might suddenly want to play this
> game all at the same time in their own parcel (nonsense thus,
> which is why this proposed system is so bad).
> Your solution doesn't work either however: In your case I would
> start rezzing chickens, and when I rez chicken 76, suddenly
> the limits would kick in full force and 66 chickens would die,
> only leaving 10 to run free. At that moment we'd be under the
> 75% again though, so my chicken rez object would start creating
> new chickens again, until it again rezzes the 76th chicken...

And your customers would complain, so you'd add code to check how
close the sim was to triggering the soft limit, and all would be good.

[Kelly Linden]

This is exactly the kind of tool that it makes sense to extend to script
limits, and I don't think anyone has suggested it wouldn't be available,
even if we haven't explicitly listed it as a feature yet.

On Wed, Dec 16, 2009 at 11:54 PM, Peter Leonard/Dante <danteferret-***@public.gmane.org
> wrote:

> Just look at region Object Bonus. This is an example where a dynamic system
> is already in use and works.
>
> Object bonus allows EMs and the EO to allocate empty buffer parcels in
> order to give other parcels more prims.
>
> With object bonus on there is the posibility to rez more prims then the sim
> allows and have the sim return random objects, yet it works, and LL chose to
> give the estate staff the choice. Why can we not do this with script limits
> as well?
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting
> privileges
>

[Aleric Inglewood]

On Wed, Dec 16, 2009 at 2:03 AM, Stickman <stickman-***@public.gmane.org> wrote:
> The comfort or early warning I expect is that we're going to get
> better tools to see behind the scenes on scripts before the limits
> actually show up. My fear is that it's going to be right when midterms
> crop up and have a two week window to rewrite every script I've ever
> written.
>
> Can any Lindens on this project provide any information, or point us
> to a magical page on the wiki that explains this? Or, at the very
> least, give us a rough timetable so we know about what time is
> appropriate to begin our panicked search for information?

To save him from typing this again, here is some info about this
topic from IRC. I editted it (removed other conversation):

[23:53] <tehKellz> Aleric: in general script run time isn't an issue.
Scripts do run fast, and we dedicate a fairly fixed amount of time
each simulator frame to running scripts.

[23:54] <Aleric> tehKellz: If you are going to set limits on scripts,
you should not do so in any way that normal scripters are affected
imho. Only those that really try to abuse it. You cannot set limits
per-script in order to control the server load; the only way to do
that is using load balancing (NO limits for a script if there is
enough resources)
[23:55] <tehKellz> Sure, I can cover some points here:

[23:55] <tehKellz> *) Correct. When we start enforcing limits most
won't notice, only those extreme cases.

[23:56] <tehKellz> (everyone just always assumes they will be effected)
[23:56] <tehKellz> *) We won't be limiting CPU (for now at least) just memory

[23:56] <tehKellz> *) The limits aren't "per script" but "per region"
and "per avatar". A region will get probably ~300MB for scripts.
give or take.

[23:57] <tehKellz> *) The problem being solved isn't performance
because of script run time. It is because when memory bloats too much
it pushes sims into swap which kills the performance not only of that
region but every other region on the host.
[...]
[00:00] <tehKellz> In all cases, even if the memory limits we set are
1gig of mem for scripts per region, the truth is that we *do* have a
tragedy of the commons problem and we need the limits.

[Imaze Rhiano]

Stickman kirjoitti:
> I don't know what the official name is, but it's either Parcel
> Limits, Script Limits, or Memory Limits.
>
> It's been a while since I've heard any official word about it. Last I
> did hear, LL was gathering statistics and didn't know exactly how
> they were going to implement it, let alone what the limits would be.
>
> Has LL made any decisions, and would they be willing to share them?
> More minds on the issue can spot any holes or problems that could
> arise, and there's still some rumbling panic among the masses that
> can't be confirmed or quelled since we don't know how it'll work.
>
> Many thanks,
>
> Stickman _______________________________________________ Policies and
> (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev Please read the policies before
> posting to keep unmoderated posting privileges
>

Babbie's office hours and logs are best source of REAL information
currently. I am just writing good fictional
story here for you.

http://wiki.secondlife.com/wiki/User:Babbage_Linden
Tonight's office hour is last for this year - Babbie is going to have
holiday :(

Current status:
- Functionality that allows monitor memory usage is ready in server.
- Currently what is missing is UI for client side.Should be done early
2010 - thought most skeptics in audience
agrees that this is really going to happen 2011 - just before world
ends in year 2012.
- Parcel and avatar memory are going to be completely separated. If your
avatar don't have enough memory
for attachment that you are trying to rezz, then you will get error
message and rezzing will fail - even if parcel
have zillion bytes memory available. There is an exception here - in
sandbox sims you can still rezz any object. (OH
audience suggested that sandboxes would be renamed to "crashboxes" -
Babbie didn't make any promises)
- You can show your OWN attachment memory usage, how much different
attachments are using memory and
probably other statistics. This means that you can't look your
girlfriend attachments and see is she really using
that XCite thingie that you bought for her - or is she cheating you
and actually using that other manufacturer's thingie
what was bought by her secret lover that you are not supposed to know.
- You can show your OWN PARCEL memory usage, how much different objects
are using memory, other statistics
and there is also going to be tools that help you to locate those
scripts. You can't show avatar attachments memory
usage in your parcel.
- You can show your OWN REGION - even if you don't own parcel in there
(estate managers), memory usage,
how much different objects are using memory, other statistics and
there is also going to be tools that help you to locate
those scripts. You can't show avatar attachments memory usage in your
region.
- Parcel memory limitations are calculated from parcel's area. Initially
things like double primitives doesn't effect to memory
limitations. Babbie was hoping that someday region owners could
effect to this - like create heavily scripted regions and
lightly scripted regions.
- There is going to be at least half year warning period where residents
can see their memory usages, but limits are not
yet enforced.
- It is not technically feasible to do system that would separated "old"
content from "new" content created after memory
limit introduction - and would allow "old" content stil run without
limits.
- Mono scripts are going to use memory that they are using - might be
much less than 16Kb - LSL classics scripts are
always using 16Kb.

According Babbie, there is at least one avatar that have 7612 scripts
(using about 96Mb memory). And average user have
100 scripts. Highest script count what I have seen what was about 800
scripts - and it is pretty normal that non-techie
person have 200-400 scripts. This kind awful statistics has been
constant motivation about secondary discussion:
"Why people need so many scripts and what we can do for it so that there
is no need for so many scripts?". This discussion
has lead several improvements that ARE COMING to scripts early 2010 -
... err... someday...

PROBLEM: "There is too many scripts, I have GREAT IDEA! Let's limit
script size to 16/64Kb! That would limit script usage,
RIGHT?!"
- or -
"Marketing person: WE NEED TO RELEASE SL NOW! Skip idea about that
dynamic script memory thingie
whatever, we can't market such things anyway! Instead each script should
have fixed amount of memory - DO IT NOW!"
RESULT: Scripters will split scripts to multiple scripts so that they
can script larger scripts.
CAUSES: Multiple scripts will cause overhead because of communication
mechanism and other thingies to get them work. Multiple
scripts are actually using much more memory than single script would use.
HOW-TO-FIX: Mono scripts are going to get function that allows them to
allocate more memory for them self.

PROBLEM: "Whining customer: OMG COPYBOT! You can't allow scripts to get
primitives parameters that would make copying
them too easy! LL: Don't worry, we allow scripts only get parameters
same primitives where they reside. Bear hug?"
RESULT: Scripters will copy their scripts to every primitive in object
(for example hair resizers).
CAUSES: Have you ever heard 255 primitive hair with 255 script resizer?
I have .. I have several of those.
HOW-TO-FIX: llGetLinkedPrimitiveParams

PROBLEM: "Our servers can't handle load made by these functions if they
are called repeately in loop and they also allow
griefers to grief hundreds person in second. We need to add artificial
delays to these functions."
RESULT: Scripters will split scripts to multiple scripts so they can
avoid delays and run scripts parallel.
CAUSES: Multiple scripts....Like hair resizers.
HOW-TO-FIX: llSetLinkedPrimitiveParamsNoDelay, maybe also other
xxxNoDelay functions and different throttling method
for server that allows it to control load.

PROBLEM: "0MG! 1 can writ3 script! I am l33t n0w!"
RESULT: Badly scripted things like chickens. I hate chickens. Unless
they come with some good wine.
CAUSES: Lag
HOW-TO-FIX: C# and other languages are coming, LL have already working
prototype. Should be easier for creators identify
good from bad scripter.... Or maybe not...

PROBLEM: "OMG! I have great idea about HUD! We will built radar thingie
and then will add hug thingie to it! Great? GUYS?!"
RESULT: Hundreds scripts are running in server that could be running
client side only.
CAUSES: Lag
HOW-TO-FIX: Emerald viewer, client side radar, client side animations,
client side scripting... someday

Babbie would really want to hear more reasons why people are using
hundreds scripts. So if you have more reasons - please send them for
Babbie. So that his team can form strategy to overcome reasons behind it.

Anyway... you can stop whining now. Script limits are coming. There are
no other options. Maybe even before world ends. You should start
thinking about those limits NOW! At least what you can do is to make
your hairs and other objects copyable and allow customers to remove
scripts from them when they don't scripts anymore. You don't need to
make your object modifiable - you just need to add option to your
scripts that removes scripts from primitives by calling
"llRemoveInventory(llGetScriptName());". Some resizers have already this
option.
Just don't be moron and disable this option because you think that your
customers are too stupid.

... everything around this really leads to one real question: "If a
tree falls in the forest and no one is around to hear it does it make a
sound?"
Or why there is script running when no one is around to see results? But
that is architectural question that mortals can't comprehend.

[Tigro Spottystripes]

Hm, nice reading, most of it was indeed comforting to some extent, thanx
for bringing this to my inbox :)

Btw, is there some sort of communication medium for a group of people
that doesn't require people to communicate in real time nor actively
check to see if anyone has said anything new, nor require any sort of
client program that requires relatively expensive hardware to run? I
mean, could Linden office hours work (except for things that need live
demonstrations in-world) as separated mailing lists that run all week
long perhaps?


Imaze Rhiano escreveu:
> Stickman kirjoitti:
>
>> I don't know what the official name is, but it's either Parcel
>> Limits, Script Limits, or Memory Limits.
>>
>> It's been a while since I've heard any official word about it. Last I
>> did hear, LL was gathering statistics and didn't know exactly how
>> they were going to implement it, let alone what the limits would be.
>>
>> Has LL made any decisions, and would they be willing to share them?
>> More minds on the issue can spot any holes or problems that could
>> arise, and there's still some rumbling panic among the masses that
>> can't be confirmed or quelled since we don't know how it'll work.
>>
>> Many thanks,
>>
>> Stickman _______________________________________________ Policies and
>> (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/SLDev Please read the policies before
>> posting to keep unmoderated posting privileges
>>
>>
>
> Babbie's office hours and logs are best source of REAL information
> currently. I am just writing good fictional
> story here for you.
>
> http://wiki.secondlife.com/wiki/User:Babbage_Linden
> Tonight's office hour is last for this year - Babbie is going to have
> holiday :(
>
> Current status:
> - Functionality that allows monitor memory usage is ready in server.
> - Currently what is missing is UI for client side.Should be done early
> 2010 - thought most skeptics in audience
> agrees that this is really going to happen 2011 - just before world
> ends in year 2012.
> - Parcel and avatar memory are going to be completely separated. If your
> avatar don't have enough memory
> for attachment that you are trying to rezz, then you will get error
> message and rezzing will fail - even if parcel
> have zillion bytes memory available. There is an exception here - in
> sandbox sims you can still rezz any object. (OH
> audience suggested that sandboxes would be renamed to "crashboxes" -
> Babbie didn't make any promises)
> - You can show your OWN attachment memory usage, how much different
> attachments are using memory and
> probably other statistics. This means that you can't look your
> girlfriend attachments and see is she really using
> that XCite thingie that you bought for her - or is she cheating you
> and actually using that other manufacturer's thingie
> what was bought by her secret lover that you are not supposed to know.
> - You can show your OWN PARCEL memory usage, how much different objects
> are using memory, other statistics
> and there is also going to be tools that help you to locate those
> scripts. You can't show avatar attachments memory
> usage in your parcel.
> - You can show your OWN REGION - even if you don't own parcel in there
> (estate managers), memory usage,
> how much different objects are using memory, other statistics and
> there is also going to be tools that help you to locate
> those scripts. You can't show avatar attachments memory usage in your
> region.
> - Parcel memory limitations are calculated from parcel's area. Initially
> things like double primitives doesn't effect to memory
> limitations. Babbie was hoping that someday region owners could
> effect to this - like create heavily scripted regions and
> lightly scripted regions.
> - There is going to be at least half year warning period where residents
> can see their memory usages, but limits are not
> yet enforced.
> - It is not technically feasible to do system that would separated "old"
> content from "new" content created after memory
> limit introduction - and would allow "old" content stil run without
> limits.
> - Mono scripts are going to use memory that they are using - might be
> much less than 16Kb - LSL classics scripts are
> always using 16Kb.
>
> According Babbie, there is at least one avatar that have 7612 scripts
> (using about 96Mb memory). And average user have
> 100 scripts. Highest script count what I have seen what was about 800
> scripts - and it is pretty normal that non-techie
> person have 200-400 scripts. This kind awful statistics has been
> constant motivation about secondary discussion:
> "Why people need so many scripts and what we can do for it so that there
> is no need for so many scripts?". This discussion
> has lead several improvements that ARE COMING to scripts early 2010 -
> ... err... someday...
>
> PROBLEM: "There is too many scripts, I have GREAT IDEA! Let's limit
> script size to 16/64Kb! That would limit script usage,
> RIGHT?!"
> - or -
> "Marketing person: WE NEED TO RELEASE SL NOW! Skip idea about that
> dynamic script memory thingie
> whatever, we can't market such things anyway! Instead each script should
> have fixed amount of memory - DO IT NOW!"
> RESULT: Scripters will split scripts to multiple scripts so that they
> can script larger scripts.
> CAUSES: Multiple scripts will cause overhead because of communication
> mechanism and other thingies to get them work. Multiple
> scripts are actually using much more memory than single script would use.
> HOW-TO-FIX: Mono scripts are going to get function that allows them to
> allocate more memory for them self.
>
> PROBLEM: "Whining customer: OMG COPYBOT! You can't allow scripts to get
> primitives parameters that would make copying
> them too easy! LL: Don't worry, we allow scripts only get parameters
> same primitives where they reside. Bear hug?"
> RESULT: Scripters will copy their scripts to every primitive in object
> (for example hair resizers).
> CAUSES: Have you ever heard 255 primitive hair with 255 script resizer?
> I have .. I have several of those.
> HOW-TO-FIX: llGetLinkedPrimitiveParams
>
> PROBLEM: "Our servers can't handle load made by these functions if they
> are called repeately in loop and they also allow
> griefers to grief hundreds person in second. We need to add artificial
> delays to these functions."
> RESULT: Scripters will split scripts to multiple scripts so they can
> avoid delays and run scripts parallel.
> CAUSES: Multiple scripts....Like hair resizers.
> HOW-TO-FIX: llSetLinkedPrimitiveParamsNoDelay, maybe also other
> xxxNoDelay functions and different throttling method
> for server that allows it to control load.
>
> PROBLEM: "0MG! 1 can writ3 script! I am l33t n0w!"
> RESULT: Badly scripted things like chickens. I hate chickens. Unless
> they come with some good wine.
> CAUSES: Lag
> HOW-TO-FIX: C# and other languages are coming, LL have already working
> prototype. Should be easier for creators identify
> good from bad scripter.... Or maybe not...
>
> PROBLEM: "OMG! I have great idea about HUD! We will built radar thingie
> and then will add hug thingie to it! Great? GUYS?!"
> RESULT: Hundreds scripts are running in server that could be running
> client side only.
> CAUSES: Lag
> HOW-TO-FIX: Emerald viewer, client side radar, client side animations,
> client side scripting... someday
>
> Babbie would really want to hear more reasons why people are using
> hundreds scripts. So if you have more reasons - please send them for
> Babbie. So that his team can form strategy to overcome reasons behind it.
>
> Anyway... you can stop whining now. Script limits are coming. There are
> no other options. Maybe even before world ends. You should start
> thinking about those limits NOW! At least what you can do is to make
> your hairs and other objects copyable and allow customers to remove
> scripts from them when they don't scripts anymore. You don't need to
> make your object modifiable - you just need to add option to your
> scripts that removes scripts from primitives by calling
> "llRemoveInventory(llGetScriptName());". Some resizers have already this
> option.
> Just don't be moron and disable this option because you think that your
> customers are too stupid.
>
> ... everything around this really leads to one real question: "If a
> tree falls in the forest and no one is around to hear it does it make a
> sound?"
> Or why there is script running when no one is around to see results? But
> that is architectural question that mortals can't comprehend.
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting privileges
>
>

[Babbage Linden]

Very amusing and mostly correct summary of the situation (and about 6 months
of office hour logs), thanks Imaze.

2009/12/16 Imaze Rhiano <imaze.rhiano-***@public.gmane.org>

> ... everything around this really leads to one real question: "If a
> tree falls in the forest and no one is around to hear it does it make a
> sound?"
> Or why there is script running when no one is around to see results? But
> that is architectural question that mortals can't comprehend.
>

This is partially because Philip and Andrew's initial vision for SL was as
an autonomous world that people would occasionally visit.

Virtual creatures would run around eating and breeding and these ecosystems
should run whether or not people were there to watch.

Interestingly with over 1000 running scripts for every logged in avatar,
that is still largely the case: you can look at Second Life as a world of
scripts that humans occasionally visit.

Cheers,

Babbie

[Latif Khalifa]

On Wed, Dec 16, 2009 at 1:44 PM, Babbage Linden <babbage-1LqAnQyFbG9F6kxbq+***@public.gmane.org> wrote:
> Very amusing and mostly correct summary of the situation (and about 6 months
> of office hour logs), thanks Imaze.

One worrying thing about the office hour transcript is that the memory
limits are going to be enforced *before* you could set reserved
memory.

I'm just guessing here, but let say that you allow 300mb for script
memory per full sim, which would make a sim hit a limit at about 4000
mono scripts irrespective of how much memory they actually use. If
this is true, it's problematic on several levels. A lot of existing
sims are going to have their content broken, and it will give
incentive to people to recompile to LSO since that reserves 4 times
less memory than mono.

-- L

[Tigro Spottystripes]

If normal usage is not gonna be affected negatively, if most users
aren't gonna be affected negatively, then how can this problem be so big
to justify such measures at all?

[Tayra Dagostino]

On Wed, 16 Dec 2009 14:56:41 -0200
Tigro Spottystripes <tigrospottystripes-***@public.gmane.org> wrote:

> If normal usage is not gonna be affected negatively, if most users
> aren't gonna be affected negatively, then how can this problem be so
> big to justify such measures at all?

why, as you can read just above in this thread, a large number of
script waste simulator memory and is a source or wide lag. Take mind a
200prims jewell or a 150prims hair with resizer script or a 100prims
shoes all scripted with a resizer script each prim..... some good
scripter put a "delete" function to let customer to "clean" the object
after fitting the avatar (and some ppl don't know what happen if not
cleaned), but i prefer a safe way fool-proof like prioritization of
script (example: object rezzed inworld prio=1, hud prio=2, script of
attachment prio=3, where 1 is executed first and 3 in spare time) so
hud, and at least attachment, in this way the billion script attachment
will be reduced in spare time of simulator, without involve scripted
object or hud (maybe a limit per agent of hud script time may be a
transitional way to educated middle-low skilled scripters and
scripted items users).

This appear as a killing solution, but is the safier for an overall
lifeability of the grid

[Gigs]

Tigro Spottystripes wrote:
> If normal usage is not gonna be affected negatively, if most users
> aren't gonna be affected negatively, then how can this problem be so big
> to justify such measures at all?
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting privileges
>

Because, just like with any service that is not metered in a proper
manner, 1% ruin it for the other 99%.

-Jason

[Twisted Laws]

Add an optional command for scripts of llLoadWhenAvatarIsWithin(meters) and a lot of us would use that to control waterfalls, fountains, pets and other things :) Of course, you

need an CHANGED_ACTIVED and CHANGED_DEACTIVATED events to go with it.



Twisted


From: babbage-1LqAnQyFbG9F6kxbq+***@public.gmane.org
.....


Interestingly with over 1000 running scripts for every logged in avatar, that is still largely the case: you can look at Second Life as a world of scripts that humans occasionally visit.
...
Babbie

_________________________________________________________________
Hotmail: Trusted email with Microsoft’s powerful SPAM protection.
http://clk.atdmt.com/GBL/go/177141664/direct/01/

[Dahlia Trimble]

I'm curious why people deem it necessary to distribute resizing systems with
a slave script in each prim. Most of the resizing scripts I've seen only
allow you to adjust the size and position of prims, this is at most 6
floating point numbers per prim (x, y, z offsets, x, y, z scale). These
values are only needed as they are relative to the size and position of the
prim in the original design. Thus, a resizing system could be designed which
has a master script with memory storage for these values for each child
prim, and self-deleting child prim scripts which send the original values to
the master script one time (*before* leaving the designer's workshop) and
then delete themselves. The deletion function could also be enforced by
having the child prim scripts send their data and self delete when a
CHANGED_OWNER event occurs. The master script can then modify these values
and modify the child prims using the existing llSetLinkPrimitiveParams()
function.

If such a resizing script were commonly used, I suspect it may significantly
reduce sim memory usage. Unfortunately, the designers of the resizing
scripts in use today chose not to use such a method.


On Wed, Dec 16, 2009 at 6:38 PM, Twisted Laws <twisted_laws-***@public.gmane.org>wrote:

> Add an optional command for scripts of llLoadWhenAvatarIsWithin(meters)
> and a lot of us would use that to control waterfalls, fountains, pets and
> other things :) Of course, you
> need an CHANGED_ACTIVED and CHANGED_DEACTIVATED events to go with it.
>
> Twisted
>
> From: babbage-1LqAnQyFbG9F6kxbq+***@public.gmane.org
> .....
> Interestingly with over 1000 running scripts for every logged in avatar,
> that is still largely the case: you can look at Second Life as a world of
> scripts that humans occasionally visit.
> ...
> Babbie
>
> ------------------------------
> Hotmail: Trusted email with Microsoft’s powerful SPAM protection. Sign up
> now. <http://clk.atdmt.com/GBL/go/177141664/direct/01/>
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting
> privileges
>

[Kelly Linden]

On Wed, Dec 16, 2009 at 7:31 PM, Dahlia Trimble <dahliatrimble-***@public.gmane.org>wrote:

> The master script can then modify these values and modify the child prims
> using the existing llSetLinkPrimitiveParams() function.
>

At 0.2 seconds of script sleep per call you are currently at 1 second for
every 5 prims. 100 prims is 20 seconds and 200 is 40 seconds of pure sleep,
outside any time the script actually uses. While this isn't actually very
horrible for something that you would in theory only do rarely why push this
on your customers when it is simple to have a script in each prim and get
near-instant change?

By adding a version of llSetLinkPrimitiveParams that does not have a delay
you will be able to get the same 'near instant' change with a single script,
and that is our goal.

Additionally, llGetLinkPrimitiveParams doesn't yet exist and will remove the
need for even the initial round of self-deleting scripts in each prim.

- Kelly

[Ziggy Puff]

I wrote some scripts for a friend which let her sell a single object
with multiple color options on subsets of prims, instead of creating a
different object for each color permutation. I set it up with a pool of
slave scripts in the root prim, and she tested it on a few customer with
different numbers of slave scripts. Every single customer with a small
slave pool complained when it took more than a few seconds to switch the
textures.

She was happy when I told her that pretty soon all of that can be
reduced to one script.

Kelly Linden wrote:
>
>
> On Wed, Dec 16, 2009 at 7:31 PM, Dahlia Trimble
> <dahliatrimble-***@public.gmane.org <mailto:dahliatrimble-***@public.gmane.org>> wrote:
>
> The master script can then modify these values and modify the
> child prims using the existing llSetLinkPrimitiveParams() function.
>
>
> At 0.2 seconds of script sleep per call you are currently at 1 second
> for every 5 prims. 100 prims is 20 seconds and 200 is 40 seconds of
> pure sleep, outside any time the script actually uses. While this
> isn't actually very horrible for something that you would in theory
> only do rarely why push this on your customers when it is simple to
> have a script in each prim and get near-instant change?
>
> By adding a version of llSetLinkPrimitiveParams that does not have a
> delay you will be able to get the same 'near instant' change with a
> single script, and that is our goal.
>
> Additionally, llGetLinkPrimitiveParams doesn't yet exist and will
> remove the need for even the initial round of self-deleting scripts in
> each prim.
>
> - Kelly
> ------------------------------------------------------------------------
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting privileges

[Dahlia Trimble]

Sure the delay is a factor, however there are also rather large delays when
sending link messages through large link sets. I don't know how successful
you would be at removing the delay, prim animation aficionados such as
myself would quickly discover it and make nifty animated thingies which
would radically increase network traffic with object update packets when all
our friends gathered around the new animated thingie to watch. Perhaps an
alternate rule may work instead: apply the 0.2 second rule to each item in
the linkset that the script could address rather than the entire script? (or
something to that effect).

Of course prim animators use many scripts to get around the 0.2 second delay
now, so yeah, maybe just getting rid of it is a good idea :)

On Wed, Dec 16, 2009 at 7:45 PM, Kelly Linden <kelly-1LqAnQyFbG9F6kxbq+***@public.gmane.org> wrote:

>
>
> On Wed, Dec 16, 2009 at 7:31 PM, Dahlia Trimble <dahliatrimble-***@public.gmane.org>wrote:
>
>> The master script can then modify these values and modify the child prims
>> using the existing llSetLinkPrimitiveParams() function.
>>
>
> At 0.2 seconds of script sleep per call you are currently at 1 second for
> every 5 prims. 100 prims is 20 seconds and 200 is 40 seconds of pure sleep,
> outside any time the script actually uses. While this isn't actually very
> horrible for something that you would in theory only do rarely why push this
> on your customers when it is simple to have a script in each prim and get
> near-instant change?
>
> By adding a version of llSetLinkPrimitiveParams that does not have a delay
> you will be able to get the same 'near instant' change with a single script,
> and that is our goal.
>
> Additionally, llGetLinkPrimitiveParams doesn't yet exist and will remove
> the need for even the initial round of self-deleting scripts in each prim.
>
> - Kelly
>

[Carlo Wood]

On Wed, Dec 16, 2009 at 08:18:18PM -0800, Dahlia Trimble wrote:
> Of course prim animators use many scripts to get around the 0.2 second delay
> now, so yeah, maybe just getting rid of it is a good idea :)

Sorry, but the whole "sleep" punishment is a typical Linden
way to "solve" things that just never will work. Whatever you
try to solve that way (ie have people pay L$ 10 for freebies
to 'encourage' them to not list them; or use a punisher multiplier
on LSL scripts to 'encourage' people not to use them etc etc,
STOP. That is NOT the way. You don't even have to think about
it, it just is NOT the correct way to solve whatever problem
you have.

So, yes, adding any "sleep" to any of the functions should
never have happened in the first place. Look again at what
the problem REALLY is, and then solve the problem at the core
instead of making the life of people miserable with artifacts
hoping that they'll be forced (out of misery) into doing things
in a different way:

First:

method A sucks 10.
method B sucks 20.

people use method A.

Linden Lab wants people to use method B.

The correct solution would be to make method B suck only 5.
The solution that Linden Lab chooses is to make method A
artificially suck 40... The end result is that SL will suck,
and people will leave.

--
Carlo Wood <carlo-A8X2UORpUyHQT0dZR+***@public.gmane.org>

[Qie Niangao]

I sense an opportunity for some non-trivial mathematics to be applied
to optimally setting these limits.

The obviously, horribly wrong approach would be to set a ceiling for
all script memory use in a region and apportion that to parcel and
avatar allotments such that no over-allocation could ever occur. This
would create much lower limits than required for sub-ceiling
operations almost all the time.

Rather, the total amount of script memory that the limits permit may
be two or five or ten times that ceiling and still only encounter the
ceiling once every millenium or century or decade--all depending on
the distribution of transient demand for the capacity being limited.
So a Poisson or Erlang or some such distribution is relevant here.

What's interesting is that there are (at least) two identifiable
distributions: scripts in avatar attachments, and in parcel-resident
objects. The former is much, much more transient, of course. It all
feels a bit like engineering fibre capacity to optimally handle
predicted demand for different telecom applications.

Ignoring that new scripting functions may systematically change these
demand distributions, this seems an interesting problem for somebody
with the right background (not me!).

Even if solving the optimization problem is judged overkill, I wanted
to at least prevent that "obviously, horribly wrong approach."

[Tateru Nino]

Not that I think this mailing list is the best place to go over all
this, but I'll make one observation:

The more dynamic it is, and the less trivial the math involved, the
harder it is going to be for Joan User to figure out if her scripted
stuff is going to work properly or not, or determine the circumstances
under which it will or won't. I'd trade some versatility for a system
that is deterministic and easy to understand and predict.

On 17/12/2009 11:17 PM, Qie Niangao wrote:
> I sense an opportunity for some non-trivial mathematics to be applied
> to optimally setting these limits.
>
> The obviously, horribly wrong approach would be to set a ceiling for
> all script memory use in a region and apportion that to parcel and
> avatar allotments such that no over-allocation could ever occur. This
> would create much lower limits than required for sub-ceiling
> operations almost all the time.
>
> Rather, the total amount of script memory that the limits permit may
> be two or five or ten times that ceiling and still only encounter the
> ceiling once every millenium or century or decade--all depending on
> the distribution of transient demand for the capacity being limited.
> So a Poisson or Erlang or some such distribution is relevant here.
>
> What's interesting is that there are (at least) two identifiable
> distributions: scripts in avatar attachments, and in parcel-resident
> objects. The former is much, much more transient, of course. It all
> feels a bit like engineering fibre capacity to optimally handle
> predicted demand for different telecom applications.
>
> Ignoring that new scripting functions may systematically change these
> demand distributions, this seems an interesting problem for somebody
> with the right background (not me!).
>
> Even if solving the optimization problem is judged overkill, I wanted
> to at least prevent that "obviously, horribly wrong approach."
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting privileges
>
>

--
Tateru Nino
http://dwellonit.taterunino.net/

[Tillie Ariantho]

On 17.12.2009 15:37, Tateru Nino wrote:

> The more dynamic it is, and the less trivial the math involved, the
> harder it is going to be for Joan User to figure out if her scripted
> stuff is going to work properly or not, or determine the circumstances
> under which it will or won't. I'd trade some versatility for a system
> that is deterministic and easy to understand and predict.

Yah, and whatever you do, don't make it the way that all my customers shout at me "my HUD doesnt work anymore". I'll send them all to you, LL.

Tillie

[Kelly Linden]

On Thu, Dec 17, 2009 at 6:37 AM, Tateru Nino <tateru.nino-***@public.gmane.org> wrote:

> Not that I think this mailing list is the best place to go over all
> this, but I'll make one observation:
>
> The more dynamic it is, and the less trivial the math involved, the
> harder it is going to be for Joan User to figure out if her scripted
> stuff is going to work properly or not, or determine the circumstances
> under which it will or won't. I'd trade some versatility for a system
> that is deterministic and easy to understand and predict.
>
>
This is definitely one of our top goals.

[Kitty]

Each time I bring this up it seems quite a few people are unaware and are
trying to play memory tricks to save a few bytes here and there when Mono
tends to "waste" whole Kb's at a time per script without a way to really
tell or optimize for it because there isn't a way to look at the bytecode to
see how big each function ends up being.

As far as I can tell:
- data segments are multiples of 512 bytes (ie a script using 1 global
integer variable and one using 50 both use 512 bytes of memory to store them
in)
- each function (or event handler) is placed on a 512-byte boundary (ie a
function with nothing more than llSay(0, "Hello World!"); takes up 512
bytes)

It would be helpful to get some kind of (semi-)official confirmation of the
above and just how Mono is compiled and how things are laid out in memory
and if there are any plans to address it (some padding is always needed but
why so much per function?).

The data segment alignment isn't that big of a deal but the total amount of
memory "wasted" by padding each function to be a multiple of 512 bytes can
add up to quite a bit per script.

Kitty

[Sheet Spotter]

I have two questions that relate to the efficient use of the limited
physical memory within the simulator.

Firstly, does the server have any existing mechanisms to identify and
"unload" scripts that will never execute another line of code?

Everyone has likely bought objects that include a floating text script. Many
content creators are unaware that it's unnecessary to leave these scripts in
the object.

Some texture animation scripts and particle scripts are other examples of
scripts that only set a prim attribute and then never execute another line
of code.

Scripts that only have logic in the on_rez or state_entry events will never
execute another line of code after returning from these events.

Secondly, is the statistics gathering phase of this project able to identify
the percentage of scripts or memory that is currently allocated to scripts
that will never execute another line of code?

Identifying and removing these scripts from the simulator's runtime memory
improves on the efficient use of that limited resource. It does not
eliminate the need for script/memory limits.


Sheet Spotter

[Carlo Wood]

On Thu, Dec 17, 2009 at 07:17:03AM -0500, Qie Niangao wrote:
> I sense an opportunity for some non-trivial mathematics to be applied
> to optimally setting these limits.
>
> The obviously, horribly wrong approach would be to set a ceiling for
> all script memory use in a region and apportion that to parcel and
> avatar allotments such that no over-allocation could ever occur. This
> would create much lower limits than required for sub-ceiling
> operations almost all the time.

THANK YOU!!!
Finally someone else that understands this :)

I hope that you, and everyone else that understands this, will go
the Babbage office hours to bring this under her attention again
and again; until he understands that the easy road is not the right
one, and some more difficult approach HAS to be taken.

> Rather, the total amount of script memory that the limits permit may
> be two or five or ten times that ceiling and still only encounter the
> ceiling once every millenium or century or decade--all depending on
> the distribution of transient demand for the capacity being limited.
> So a Poisson or Erlang or some such distribution is relevant here.

Exactly. The servers will simply only use a FRACTION of their
resources on average. A huge waste of resources that we, the residents,
will have to pay for, literally.

> What's interesting is that there are (at least) two identifiable
> distributions: scripts in avatar attachments, and in parcel-resident
> objects. The former is much, much more transient, of course. It all
> feels a bit like engineering fibre capacity to optimally handle
> predicted demand for different telecom applications.
>
> Ignoring that new scripting functions may systematically change these
> demand distributions, this seems an interesting problem for somebody
> with the right background (not me!).
>
> Even if solving the optimization problem is judged overkill, I wanted
> to at least prevent that "obviously, horribly wrong approach."

The problem however is not technical (point out the flaw and people
start working on it), it is political. Before Babbage is going to
listen to this you'll need a LOT of lobbying-- no matter how utterly
true it is.

--
Carlo Wood <carlo-A8X2UORpUyHQT0dZR+***@public.gmane.org>

[Marine Kelley]

Although all neat and certainly very clever, would this kind of
solution still satisfy my primary need as a scripter ?I.e. being
CERTAIN that my scripts will NEVER crash because of memory shortage
due to reasons that are out of my control ? I could write the best
script in the world that takes a constant amount of memory, it would
still crash eventually if this amount suddenly became higher than the
limit, if this limit moves down when the sim becomes busier.

The script could freeze, slow down, we could have functions and events
to stay aware of how many bytes we have left, but to me the core issue
is that scripts which run out of memory simply endure an unrecoverable
crash. This basic behavior is very wrong in the first place and must
be revised.

Yes I do know this is asking a lot. I do not even expect this to
change any time soon, but in the meantime PLEASE don't add one more
level of uncertainty when it comes to scripting. I want to know how
many bytes I have left, and I want total control over what consumes
them.

Leave the limits fixed !

Marine


On 18 déc. 2009, at 13:32, Carlo Wood <***@alinoe.com> wrote:

> On Thu, Dec 17, 2009 at 07:17:03AM -0500, Qie Niangao wrote:
>> I sense an opportunity for some non-trivial mathematics to be applied
>> to optimally setting these limits.
>>
>> The obviously, horribly wrong approach would be to set a ceiling for
>> all script memory use in a region and apportion that to parcel and
>> avatar allotments such that no over-allocation could ever occur.
>> This
>> would create much lower limits than required for sub-ceiling
>> operations almost all the time.
>
> THANK YOU!!!
> Finally someone else that understands this :)
>
> I hope that you, and everyone else that understands this, will go
> the Babbage office hours to bring this under her attention again
> and again; until he understands that the easy road is not the right
> one, and some more difficult approach HAS to be taken.
>
>> Rather, the total amount of script memory that the limits permit may
>> be two or five or ten times that ceiling and still only encounter the
>> ceiling once every millenium or century or decade--all depending on
>> the distribution of transient demand for the capacity being limited.
>> So a Poisson or Erlang or some such distribution is relevant here.
>
> Exactly. The servers will simply only use a FRACTION of their
> resources on average. A huge waste of resources that we, the
> residents,
> will have to pay for, literally.
>
>> What's interesting is that there are (at least) two identifiable
>> distributions: scripts in avatar attachments, and in parcel-resident
>> objects. The former is much, much more transient, of course. It all
>> feels a bit like engineering fibre capacity to optimally handle
>> predicted demand for different telecom applications.
>>
>> Ignoring that new scripting functions may systematically change these
>> demand distributions, this seems an interesting problem for somebody
>> with the right background (not me!).
>>
>> Even if solving the optimization problem is judged overkill, I wanted
>> to at least prevent that "obviously, horribly wrong approach."
>
> The problem however is not technical (point out the flaw and people
> start working on it), it is political. Before Babbage is going to
> listen to this you'll need a LOT of lobbying-- no matter how utterly
> true it is.
>
> --
> Carlo Wood <***@alinoe.com>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting
> privileges
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posting

[Carlo Wood]

On Fri, Dec 18, 2009 at 04:34:41PM +0100, Marine Kelley wrote:
> The script could freeze, slow down, we could have functions and
> events to stay aware of how many bytes we have left, but to me the
> core issue is that scripts which run out of memory simply endure an
> unrecoverable crash. This basic behavior is very wrong in the first
> place and must be revised.

Imho, the best solution would be to, after selecting
the right scripts according to some algorithm [(only from
those users that use more than their share, then from
those who use the most, then first those scripts that
haven't really done anything in a long time and first
those that are flagged as volatile (not so important),
etc etc etc], and then just stop them (give them
no more cpu time) and swap them out to disk. This won't
delay the sim since they don't run anymore for a while.
It also won't crash any scripts, because they don't
get less memory, they are just temporarily stopped.

If some attempts to start a NEW script, then you
should not start it at all of course, otherwise
a griefer could attempt to 'attack' the harddisk
space ;).

Once the server is less loaded again, using the
same algorithm you can reverse the swapping and
start scripts again.

But well... let me not waste my time any longer.
We all know that LL isn't going to change their
plans anyway. They never do.

--
Carlo Wood <carlo-A8X2UORpUyHQT0dZR+***@public.gmane.org>

[Dzonatas Sol]

The way I understand it isn't the way it is and maybe not the way its
going to be, yet my vision is simple:

Let each avatar 'buy' server memory usage (kind like how they buy land
usage now). Guarantee each avatar can have the max memory usage in any
sim no matter what condition.

If that means the top 50 avatars with the most memory allocation meet up
in a single sim, then it should handle it.

The way the sims are designed now, it won't handle it with or without
those limits as Babbage expressed and how this thread evolves.

The only way it could handle it if is simulator become disassociated
with CPU affinity such that a single simulator may actually execute
across several CPUs/machine/networks all at the same time. Obviously the
main limitation here that keeps simulators tied to CPU affinity is
physics -- not memory usage.

Carlo Wood wrote:
> On Thu, Dec 17, 2009 at 07:17:03AM -0500, Qie Niangao wrote:
>
>> I sense an opportunity for some non-trivial mathematics to be applied
>> to optimally setting these limits.
>>
>> The obviously, horribly wrong approach would be to set a ceiling for
>> all script memory use in a region and apportion that to parcel and
>> avatar allotments such that no over-allocation could ever occur. This
>> would create much lower limits than required for sub-ceiling
>> operations almost all the time.
>>
>
> THANK YOU!!!
> Finally someone else that understands this :)
>