[sldev] A thought on how to lower resources used by sensors

[Carlo Wood]

On Mon, May 18, 2009 at 01:03:35PM -0700, Kelly wrote:
> difficulties that are less insurmountable but still trouble.  By their nature
> they are at least a little more load intensive than just accessing data the
> region already has in memory would be.

The problem of 'sensors' is that they do too many call backs to
(cpu intensive) LSL scripts. Namely, whenever the distance to
the sensor changes.

The core of the problem here is that scripts are SLOW and
for some reason use too much cpu (imho, I could write a server
that can host the same at 1/10 of the cpu (and price)).

For example, if sensor data wasn't needed for scripts but
it would be sufficient to just have that data on the viewer,
it wouldn't be a problem at all to include the coordinates
of all avatars in a sim in a single packet and send that
once a second to all viewers. Personally, I'd do this by
default and provide the means to run HUD object scripts
entirely client side (so that people can implement radars
client side). [PS client side scripts should be open source,
full permission]

Unfortunately, as soon as you include any kind of
limitation that can be overcome by using more than one
sensor object, then that is what will be done. Therefore
two things will be needed: 1) making things more efficient
on the server, 2) limit resources per avatar/owner,
and not per object. The latter will cause some people to
start using secondary connections, but at least for
a while that should be limited to only a hand full of
hackers.

PS. One way to limit sensors in a way that it can NOT
    be over come by using more than one sensor is
    by means of time and/or space quantisation that
    is the same for every object.
    For example you could only report coordinates
    (x,y) if z < 96 (and not at all if the sensor
    z > 50) modulo 4 meters. No matter how many
    sensors, one would never get more information
    than with one sensor. Unfortunately... that
    means that even for short distances the quantisation
    has to be same as for large distances and thus
    that llSensor() would have to be removed
    (because it would be a means to get MORE data
    by using it, still, in multiple objects).
    Hence that space quantisation can never be an
    option.
    Time quantisation could be in practise, but
    I'd really not like it when the normal llSensor
    suddenly starts to report changes only every
    4 seconds. Now, if one would count the number
    of sensors in a region per owner and increase
    the time quantisation for all sensors per ratio
    than that would really be point 2 above.
    For example, at most four sensor() events
    per second per owner, at most one per
    second per script, and all calls quantisized
    at integer number of seconds UTC.

    The implementation of this would be easy
    (on the server) and require no viewer or
    protocol changes.

    The server would handle sensors once per
    second, keep a list of all sensors by
    owner in a priority queue where the
    priority depends on distance and time
    since last event, and only trigger the
    sensor() event for the first four.

-- 
Carlo Wood <carlo at alinoe.com>