To save money and resources: Opensim could sleep when no-one is watching
If a tree falls in a forest and nobody can see it, does it still fire a collision event?
In Second Life(R) it does, and this is one of the reasons that the platform is so expensive – maintaining 20,000 regions requires 20,000 processor cores. Consider the WWW by contrast – a single server can power thousands of websites; because the cost of hosting is virtually free until someone accesses the site. Cost does not equate simulation space – it’s based on simultaneous concurrent accesses and the complexity of processing the requests.
OpenSim falls into the same trap in many ways – while the cost of hosting an empty region is nearly nil; there are two key aspects where processing will always continue even if there is no need or desire to do so. These areas are physics and scripting – arguably two of the larger expenses on the processor bill.
Physics can be limited somewhat – switching away from a persistent simulator (ODE) to something that computes physics ‘on demand’ (POS, BasicPhysics) will remove the expense of physics while no-one is in the region, but you lose the ability to have objects move independently. For those hosting geographical areas this may be perfect – if you don’t have any scripts in the region and compute physics purely on demand, you are looking at a raw cost in just memory – about 20mb per region, and even that can be paged to disk safely.
However, hosting conventional regions is a more tricky prospect – users have an expectation of certain features working, people use scripting and want to physically interact with objects. One of the options worth considering may be simply dialling the simFPS according to the number of viewers in the region. Drop down to 1Hz when there is no users, but dial back up to 45Hz when users appear – all easy enough to do within the codebase, however doesn’t reduce the processor cost to zero while inactive.
If we consider the ultimate goal being to reduce Virtual World running expenses to similar to that of a web-host: costs being per-access, measured in processor time, bandwidth, etc. then we need to go a few steps further. One of the bigger steps is reducing expectations – right now you can safely assume LSL will always be running, so therefor you can write things like “servers” in LSL. Servers are a good example of the problem – they are something that interacts with the world, but aren’t supposed to be part of it; yet they consume the expenses of being in the world all the same.
Servers could be much better replaced by simple web scripts or server daemons on a normal server – which have a decent API that can connect to the world and make their interactions without needing to be part of it. By doing so, you not only make the servers more efficient (Apache+PHP is faster and more powerful than LSL), but you reduce the persistent load on the world itself.
The work I am doing on MRM is addressing part of this problem – redefining the API to reduce the number of scripts you need in the world, but a total solution here includes some kind of “remoting-style” API that lets you send messages and interact with the world, from a completely independent outside authority. The other side of the same coin is reducing ‘background noise’ processing – timers, sensorrepeats and other recurring tasks all place a small but visible background load on the server, all of these events will keep the server processing even if there is nothing to do.
Some things may require this – but encouraging people to think about when they need these events is better. Limitations on the LSL API really prevent this in SL, but in OpenSim would you be willing to use a “TimerIfAvatarInRegion” instead of a plain Timer? If you could – then it would allow the back-end server to attach conditions to your scheduler which provide optimisations when no-one is there. Allowing these kinds of optimizations is going to be key in the long term – because a cost of one processor core per four concurrent users is just simply insane and will never be adopted in the wider marketplace VW operators hope to gain. If webservers could only handle four simultaneous users – Google would require millions of servers to operate instead of just thousands.
The conception of sleeping sim is a very fresh, and nice idea. I think the same as you. The SL architecture is not really optimal, and not enough flexible to be a platform of the future virtual reality. I really believe in MXP and the sleeping sim philosophy, what you introduced in this article. I think the MXP can help to create a web like global virtual reality architecture.
You have spoken about 2 problems of the sleeping grids: the phisics, and the scripts which have to be run in also in non obeserved state. I have no idea about phisics, but I have a possible solution to solve the problem of scripting. I think the core of the problem that LSL uses simple event handling for the “inner events” (events which comes from inside the SIM, like timer ticks). If you change these events by others which fire only when the object is observed, you can solve the problem in many cases. For example, if you want to rotate a simple cube in LSL, you do something like this:
on_timer() {
counter ++;
rotate(counter % 360);
}
It can be changed a different timer event, which fires only when the object is obesrved, and calculates the state of the object in the time of observation:
on_timer_observed(rez_time, now) {
counter = now – rez_time;
rotate(counter % 360);
}
In this second script we get the time when the script started, and the actual time, and calculates the counter, and the state of the object. The difference that in the first (standard) case, we calculates every phase of the rotation, but in the second case we put it the state which should be in, on the observetion time. The second script is equivalent like the first, but it has the advantage that it can be sleep when the object is not observed.
The more generic way to solve problems like this is creation of an “observation” event. It could be fire only when the object is observed. In this event you could set the state of the object (as I’ve shown), do a sensor scan, etc. I think it is a more cleaner solution like create many new events like “TimerIfAvatarInRegion”, “SensorIfAvatarInRegion”, etc.
It can help to make “sleepable” scripts in many cases, but not all of them. When the object interacts others when it is changing with time, the observation event is not enough. Imagine a moveing cube, which is collide another cube. If you dont observe them when they collide, they wont collide. So, the observation event is not a universal solution, but it could help to solve the “sleepable script” in many cases.