Better Cacheing System Idea

You might also find defragmenting your cache file on your HD will result in higher speeds. Not to mention keeping your systems VM on a different drive. Distributing the load across mutliple drives decreases seeking.

There is a command line utility you can use to defragment individual files.
Contig

I've again changed my cache size to 1000MB to see if I notice gains as you do. I hope so.

Frequently New ideas ( or old ) come to surface and becomes overly obvious and neccesary.
As I have noticed and I am sure others have also that with each upgrade we recieve from SL, new things have been added.. some are great and then some I find little use of.. but then I am sure others have different perspectives on that.
However these additions add to the server info and takes up more and more bandwidth.
And along with it more Lag.
At some point the Cache needs a drastic overhaul.

this Post is in attempt to bring this forum back to the top and give it life again.
lets talk about it more with inovated ideas from all.
Thanks everyone for their support.

Shjak Monde

<blink><glowing><weeping-blood>WHERE THE FLOCK DO I MAKE A FEATURE REQUEST FOR MICROSOFT TO FIX THE FLOCKING FILE SYSTEM FRAGMENTATION PROBLEM</weeping-blood></glowing></blink>.

There are NO modern operating systems but Windows where fragmentation is an issue on drives that are less than packed-to-capacity.

I'm not a programmer, but since other on line 3d worlds make use of a cache on my own hard drive, it seems to work there. And you can set however much of your drive you want to use, also, giving the user a way to fine tune the cache.

Huge edit: teleport tracking for burst caching!

LL is probably just concerned about losing their assets over this issue.


I see a number of ways to optimize cache accesses, and it all comes down to looking at how objects are loaded as you explore the world, trying to organize the cached data for rapid reads.

We are creatures of habit. With the vastness of SL, it is common for people to establish areas of interest that they visit far more often than anywhere else, and these areas are usually likely to be traversed in a certain linear manner or along a certain common path.

And so, for every cached object, maintain the following statistics:
- how often has the player seen this object?
- when did the player last teleport somewhere?
- in what chronological order was it seen since teleporting?

This sort of cache optimization defines a linear path through the dynamic 3D world of SL. Monitoring when cached objects are seen relative to other cache objects allows the cache to track objects along a linear path of travel through the world, even though the space could be tranversed any number of ways.

Tracking teleports allows the cached objects to be broken into separate caching and pathing categories. Each time a player teleports somewhere, it is as if they are entering the SL world again for the first time, and the cache must be hit hard in a linear fashion, loading up all the objects that make up the new teleport zone.

Objects which are loaded the soonest after a teleport are the most significant since they are the part of the world the player sees right away after arriving and expects to load up the quickest. When teleporting somewher you just expect everything to just be there, instantly loaded and ready.

The point in time where objects are no longer being burst-cached may only be 5-10 minutes after teleporting somewhere, because by then you are settled in and the need for instant loading is all done.



Let's assume that you have a house, and your Home is set to a room inside this house. You always enter SL through this house.

Highest seen many times priority goes to:
- the textures in the room where you arrive
- the textures in the hallway outside the room
- the rooms on the lower floor of the house
- the surrounding outdoor textures seen as you walk out of the house

These objects are seen repeatedly, and so are given much higher burst-cache retention priority, over areas you have visited perhaps only once or twice.

Sorting by when seen puts:
- the textures of the bedroom all next to each other
- the textures of the hallway outside the room all next to each other
- the textures of the rooms on the lower floor all next to each other
- the outdoor textures outside the house all next to each other

By doing this statistical analysis and reordering, and enabling read-ahead of cache data, the textures can load up in a flash because the data is organized in a manner that most closely suits you and your interests. Every cache read can then also read the next few items you are most likely to want to see anyway.

Less-frequently explored areas around your home that you rarely visit will have much slower loading speeds because they aren't among the most commonly seen, and aren't usually seen in any particular order.

If there's a certain club you like to visit weekly, there's a linear path you will likely travel every time you teleport to the area and then enter the club. Sorting the textures by when you you saw them as you walked/flew through would also speed up viewing of this less-often seen area.

-Scalar

In addition to the teleport/burst-cache mentioned in my previous post, I see room for several separate overlapping caches, each emphasizing a certain type of speed of data-loading.

Another type of much-needed sorted-by-time cache is the Race/Game cache. This cache emphasizes loading speed of objects when doing something that has certain predefined and set limits.

When you want to play a racing game against someone in cars across many sims, the path you travel for each race will be along a certain predefined path, which is seen repeatedly each time you race.

This cache could be helped along by LL if there were an actual explicit "start of game" and "end of game" command added to LSL, along with a key-generation system so that all games of a certain location all have the same key.

Every time you start playing the game, that game's key is flagged and the objects seen while playing are cached and tracked by when-seen. Cache monitoring stops when the game stops.

The next time you play the racing game, the cache is ready for you. As you race in your vehicles along various roads, the cache is prefetching objects along the path you travel in the game, so that movement is smooth and there are no loading delays.

You can move as fast as you want, and the cache can stay ahead of you since it already "knows" the path you will most likely be taking.



This sort of cache could be taken a step further by using in-world phantom pathing objects, that are used much like the breadcrumbs in games like Unreal Tournament, to help the prefetching engine know where you are most likely to be going.

Multiple paths of travel can be supported such as along a twisting maze of many streets, with the view up/down each street being maintained in a separate stream of cached objects. As you reach an intersection, the cache is handed off to one cache stream or the other, depending on which of the phantom breadcrumbs you are nearest. It can also distinguish reverse-pathing, doing read-behinds rather than read-aheads if you are traveling the other direction along a path.


An important part of this sort of cache is permitting the duplication of cached data. This allows objects seen from several different paths to be sorted into the fastest read-ahead location for each of those paths.

It would not suprise me if such path caching spanned gigabytes of storage, but I really do not care. My only concern is that the environment load up quickly when I need it most.

-Scalar

And I for one would allow such a chache to take up several GB of space. I would love to see TPs last seconds instead of minutes and be fully loaded when I land.

I'm going to bump this thread up because I completely agree with this cache thing. If not to increase the size, then to put stuff in different folders. I heard somewhere to make SL run better I should clear my cach... BAD idea! Every thexture in the librady had to be reloaded one at a time and the program ran slow for quite a while to get all the more used textures back . I was at a racing sim where I hat to do a lap to load all the ground prims. I went to the middle to chat, came back and had to reload the prims all over again!
If the whole idea is a bit more complicated than people think, at least raise the limit from 1G to 100G and let them see that idea for themselves.
...Unless that somehow requires alot of code...?

- Jolan

About 4863 lines. As soon as we change a UI option, we crash the renderer and can't communicate with the network. ;P

This sounds like a good idea to me...all ten of my votes went to proposal 989!

The cache definitely could use some improvement. Even if images were better cached, it would help.

I'm tired of logging in and seeing gray boxes at my home. I'd think that the area I visit the most would still be in my cache... and certainly, geometry I looked at less than 10 seconds ago should still be in the cache... but I can very easily run out of geometry by simply flying back and forth with my power of flight script.

Bump

I think we should have a option of using draw distance or to load the entire Sim entirely. I don't mean to bash on the people with the smaller draw distances but If I wanted to have a distance of 512M Its almost fruitless because when I move it countinues to load what I can't see. If I could load the entire Sim or quarters of it I can walk around and not load again like levels or stages of other games. And it being a option means people who need it at 64M can still draw.

With a Static cache system, you could walk around the sim once and load everything and retain it as long as you like on your own computer never having to download it again and only download things that have changed since your last vist.

Bump

With SL changing nature, the cache is probably one of the most important parts of the system.

I think that instead of a static cache you need to do a cache per sim where the sim has a command where it gives you a list of guids and “last changed date/time”.

This would be used to quickly determine what items should be deleted from the directory and which ones need to be retrieved.

The disadvantage of this type of approach is that common images have to be downloaded multiple times. The “last changed date/time” would have to be updated every time an object changes anything. (Change on object update)

Since worn objects aren’t handled by the sim, I would place them in an Avatar cache.

Edit:
With SL's pipeline design it might be better for the client to tell the sim what date/time it visted last and have the sim send all the changed items.

The “master list of objects” packet would then only need to contain the Guids of the objects that are in the sim at the moment. This of course is important since without it, the client does not know what objects have been removed.

@Grumble
I was asking about this actually, apparently simulators do cache information already to an extent, however the system uses "Squid" proxy server software so I'm not 100% sure of how well this works, though I assume it works between the simulator and asset server(s). ie Koss requests asset ID 1234, the proxy sees that 1234 was already requested, and retrieves the result from the cache accordingly.
Since UUIDs are static there is no issue of updates, as the UUID of an updated object is different from the object you started with. It will work well (in theory) for images, sounds etc. A main problem with this is the low RAM and shared hard-drive in the systems, which likely hurts the caching and requires fairly low limits on cache size (making it essentially worthless for a sim with any moderate amount of content).

However, while what I think you're getting at is partly the objects in the simulator itself, I'm not sure of the advantage of caching these. Sure, for visiting a few select sims frequently it may help, but the bulk of the information is textures and sounds, objects aren't really that complex of themselves, and are now compressed. I suppose every little help though.

Is there no way to manual rezise the cache (>1GB)?
What is with the VFSSalt value?

Woah, this thread came back from the dead!



This is possibly the easiest solution they could go for. Have a separate cache folder for each simulator, and cache file governing these folders. The caches themselves will behave exactly as the full cache does now, so each one can go up to 1gb, and they cull older items when they get full-up.
In addition, each simulator folder is tagged with a 'last visited' time, either as meta data on the folders themselves or in a file somewhere that can be looked at when needed. This then would allow you to have a total cache size (if it's filling up then throw away the oldest sim folders before throwing away files from the current sim) or a time-based culling (ie any simulator that hasn't been visited in a week is culled).

This would be a MUCH better system without really having to change the current caching code except to point it to a different folder for each simulator, and add a file to handle the folders. Sure it still wouldn't cache objects very well, but it would keep textures, sounds etc around a lot longer for the places you frequent, thus leaving bandwidth unclogged for downloading objects.

I would happily devote 10 to 100gb of space if it made SL run better, which it would if done right. If LL still don't have a team devoted to making a better caching system then they're being stupid, though that said if they DO have a team for it then I'm curious as why it's taking so damn long for such a comparitively simple feature that would greatly improve speed and reduce bandwidth demands.

I have come to realize that the essential problem with developing this concept, is that a cache can be easily data-mined by a "copybot" type program, but with no inworld detection being possible because it can be done totally offline.

Data storage in a cache would have to include the object keys used in-world for a cache to be useful at all, and presumably that cached data could contain all other prim data such as link lists, child prim keys, texturing data, owner/creator keys, pricing data, permissions, and so forth.

This could be surfed at-will by some nefarious object copyer program, all while completely offline and not requiring any "secondary/paid" account to extract the data. Such a tool could do things like:
- list/extract all prims and textures in the cache created by someone
- list/extract all prims and textures in the cache owned by someone
- list/extract all prims and textures in the cache owned by a group
- list/extract all prims and textures in the cache with a selling price over L$nnnn
- list/extract all prims and textures in the cache with no-modify permissions
- list/extract all prims and textures in the cache with no-copy permisions


This appears to be the reason that LL has been avoiding making a truly robust, quick loading cache, since it would be a gold-mine to any potential content thieves. But like it or not, a really good caching system will eventually be inevitable once people are free to develop their own open-source clients with their own internal caching schemes.

And so this copybot uproar is just the beginning. A huge, efficient, local, 50-gig world cache will be a double-edged sword. You'll get great speed and efficiency when exploring the world, and great speed and efficiency if you want to rip off other people's content offline that's stored in the cache.

I find it extremely unlikely. Having an ineffective cache hasn't prevented people from developing this kind of tool.

I wrote an offline cache ripper a good while ago. I used it to reverse-engineer the LSL bytecode (and I found a couple bugs in the LSL compiler as a result); these days I use it to extend clothing i purchased to fit my avatar (this falls under fair use).

Also wrote a tool based on that for extracted scripts (it does not give access to scripts that you didn't have access to; it cannot be used in any way to break permissions on scripts; it could not be modified even if decompiled to break permissions). This is the only cache related tool i have released to the public.

Agreed, CopyBot can just as easily mine the raw data as it's sent to the client, before it enters the cache. Leaving us with a crippled caching system only hurts the majority of users and SL as a whole (think how much data is being shunted about that doesn't need to be!)

A local cache must not be unsafe. But i thing, SL has a bigger problem with the developer.

The problem of lag get worst and the developer has other priority's. The change is a day of work. Nothing more.

To make the cache and SL save there are simple ways. You sign each object that you create with your private key. Nobody can copy it. Its used in industry for years. Private public key sign is standard. But not in this "program".

The problem are the developer. Not the maths or technical. This suggestion is 1 year old and the only thing that changed is the lag.
Sometimes, you cant see the obvious thing and need a view from outside.