[sldev] Script/Parcel/Memory Limits
Carlo Wood
carlo at alinoe.com
Fri Dec 18 04:32:52 PST 2009
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 at alinoe.com>
More information about the SLDev
mailing list