[sldev] Bidding System Algorithm for Allocation Script Memory

Carlo Wood carlo at alinoe.com
Sun Dec 20 04:09:00 PST 2009


On Sat, Dec 19, 2009 at 10:43:47PM -0200, Tigro Spottystripes wrote:
> Would it be too hard to instead of true stasis the scripts were just
> transfered into a separated thread that has less priority, runs only
> when the is some idle time on the processor or somthing (including using
> cheaper hardware and nto getting in the way of other stuff),  so scripts
> can continue to work? (either way the event that gets triggered when a
> script is about to get downgraded would still be great to have)

Well, we're assuming that the server is out of memory, so the memory
those scripts use are swapped to disk.

Assume a disk speed of 50 MB/s. Assume one script takes 64 kB.
Assume a needed run time of at least 100 ms to make sense to swap
a script out and in again. That means you can load say 5 MB every
100 ms, which are 80 scripts (at the cost of an additional 5 MB
of RAM).

The maximum number of swapped out scripts would be equal to
the maximum number of scripts that can run on a sim (for the
worst case of 1 person loading the sim fully, but only owning
a fraction of the land, and then being pushed out completely
by everyone else joining and running all the scripts they
have a right to).  So, according to LL that would 150 MB
(300 MB minus the avatar pool). Hence, those swapped out
scripts could run 100 ms every 150/5 * 100ms = 3 seconds.

Although slow, they indeed still run then,.. so I'd definitely
include a sending them a signal (maybe change their state to
'statis'? If that state doesn't exist then the default should
be to do nothing; a script could take action (ie, go to sleep)
and stay in statis, in which case it would not be swapped
out again at all, or it could change it's state back to another
state, in which case it would continue to run at the slow
speed).

-- 
Carlo Wood <carlo at alinoe.com>


More information about the SLDev mailing list