Efficient world caching: Pay people to link objects and not move them

If Second Life is to have a fast efficient caching system, one way to do that is to use a robust local cache that use object links and timestamps to quickly refresh the cache each time you start up the client.


Timestamping to quicky update the cache

The basic way this works is that every object in the world has a timestamp that is updated every time anything about the object changes, such as being moved, resize, recolored, rezzed, etc.

When the client loads the world it stores the object in your local cache and records the timestamp in a fast-searchable list.

Then when you exit the client and reopen it later, the client first checks the timestamp on the object. If the timestamp hasn't changed since last time, the object in the cache is up to date and there's no need to download it again. Just rez it up from the cache and don't bother the asset server any further.


Linked objects are faster than individual timestamps

The key concept here is that linked objects should also get a timestamp, which changes anytime anything in the link is linked/unlinked or moved/resized. And this link timestamp gets priority over the individual object timestamp.

So let's say you're opening the client and it is checking its internal cache. If you have a linked cached object, your client only checks the timestamp of the link with the asset server. If that timestamp is current, then all the objects in the link are up to date and don't need to be checked.

This means that links of objects can massively cut down on asset server queries, since one link-object timestamp check can take the place of up to 255 individual object timestamps.


Link your objects to make the world better

Under this system, it is to the advantage of both the end user and LL for as many objects in the world to be linked together as is feasibly possible.

A single huge link of static objects means that:
- that link and all objects and textures that comprise it can be loaded up immediately from the local cache
- that link requires only a single operation of the asset server to verify all other objects in that link are current


Paying landowners to do The Right Thing

To help this along, a small stipend should be offered to builders so that they will construct the world in such a way that it can be loaded up from the local client cache in the fastest and most efficient way possible.

For every five objects in a link that are on your land and are linked together, you will be paid L$1 per week. There is an second bonus of L$1 every 25 objects in a single link, and a third bonus of L$1 for every week it sits untouched on your land.


Payout for the small landowner

So lets say you have a 203-prim linked object sitting on your land for one week. There are 40 sets of five in this linked object, plus 8 sets of 25 objects in the link, giving a total bonus of L$48 per week this single 203-prim link is on your land.

Now let's say you leave the object in place and don't touch it for a year on your property. That's 52 weeks times L$48, plus L$52 for letting it sit there untouched for 52 weeks, totalling L$2548 or about US$8.49 per year.


Payout for the sim owner

If you have a whole island, and link 12,000 objects into 47 links of 255 objects, each link yields (255 / 5) + ( 255 / 25) = L$61 per week, times 47 links = L$2867 per week.

If you let your whole island sit there static for the year, that is a yearly linked-object bonus of L$2867 * 52 + 47 * L$52 = L$151,528 or US$505 per year.


What is the return to LL for paying people to do this?

- Refreshing an entire sim with as few as only 47 timestamp checks vs 12,000 individual object timestamp checks means the core asset server does not have to be so incredibly huge and expensive.

- Paying a sim owner US$505 per year to make their sim cache-efficient is cheap compared to what would have to be spent on backend asset server and networking infrastructure for that sim, if everything must be constantly redownloaded live.

- LL can do far more with much less back-end asset server equipment, and the full-sim object download is usually only a one-time event that does not have to occur over and over each time a person enters SL.


What is the benefit to users of SL?

- Just 47 cached-object timestamp checks means the entire sim can rez up from locally cached objects, with almost no bandwidth usage.

- With a sufficiently large local cache it might be possible to initially load up your world cache on a broadband connection, and then be able to use it again later over dialup, since the whole sim can rez up with as few as 47 timestamp checks.


.

It's called "linking" not "grouping." Group objects are those that are owned by a group.

Fixed.

Nice idea, though I doubt paying people for it will fly with LL.

However, I'd happily link more objects etc if it meant less lag for the area I'm in. Thing you have to watch though is that there are trade-offs between linking objects and leaving separate. Linked objects get handled slightly differently by the physics engine, so linking say a cuboid building made with hollowed cube corners and flattened cube floors, has a hit on the physics engine. Where as linking the floor/ceiling and leaving the walls of the cube individual is supposed to have less of an impact.
Admittedly I haven't put it through a great deal of testing, but if you look at any physical linked object, the engine treats it as a single object (as it should) but then has to somehow work out collision for all it's individual parts, I believe this is what it is done with non-physical linked sets as well. One of the Lindens gave a big description on it a while ago.

But yeah, I think that the reduced lag and improved user experience alone is worth the work linking objects together logically, as for businesses it can equate into more revenue as users come to enjoy your low-lag club or whatever.

Particle system changed?
How about a prim bonus for linked objects instead? So after an object has been left linked for a week, 10% of the prims in it (rounded down, so the object has to be at least 10 prims) get counted against sim overhead, not parcel limits.