Better Cacheing System Idea

I was encouraged to bring this question to Feature Suggestions to talk to others and get feedback about this idea by Torley Linden.

This is the Link to the original post.
/invalid_link.html

Is there a way to create an Option, inwhich if we desired to, sacrifice as much of our personal Hard Drives on our Computers, for the use as a Chache for Second Life?
The Idea is that as we explore Second Life and once in the visiting area and download of the Area is complete, The information downloaded would remain on my Computer until
1: I delete that Cache... or
2: the next time I visit that area, changes have accured.
and then only those changes are corrected in the Cache.

For some perhaps (with small Hard Drives) May not wish to use up a Massive amount of their Computer resources, However I do believe there is a large Majority of us that would be more then happy to sacrifice as much as possible in hopes of reduceing the lag in SL.
Personaly I have 40 gigs I would sacrifice.

Another Idea is to have each server to create thier own cache, with the sims name on it.
that way if you did not wish to sacrifice so much of your hard drive then at least you could choose which sims you visit most often and only maintain those caches.

This is just an idea I would like to get feed back on...if its popular then I will add it to the ideas list and see if we can get some votes on it.


Torley Linden wrote:


Well I would expect very little change in speed would be noticed, being that the 500- 1000meg is discribing a Chache size only.
This means if you have your draw distance set to 64, your cache seldom needs to be more then 500 megs any ways... however if you are setting your draw distance above 128 you may want to have 1000megs of cache to store all the builds and objects for that distance.
Your connection to the internet will determine the speed inwhich you download everything.
And I am sure 1000megs will take twice as long to complete the download then setting it to 500megs.

The problem remains the same if the cache is dumped and a new download is started each time I change sims.
what I am speaking about is a system that will not dump the cache at all. It continues to grow with each sim you visit.
If you return to a sim inwhich you have already loaded into your cache then the server confirms the objects in your cache and only downloads any changes that have accured since your last visit.

Torley Linden wrote:


This is very True. SL is one of the Most Dynamic Games I have seen.
However many many things are pretty Satic in all the sims.. Mostly walls, floors, Major builds.. which realy add up to a huge percentage of the objects.
And you are right to think even those get changed often.
But if we can cut the load in half, that would nearly equate out to half the lag.

Torley Linden wrote:


I would like to hear everyones opinion. And if you think I am way out in left field, I guess I would need to hear that also.

Thanks
Shjak Monde

Well, I'm not sure about massively increasing the local cache size, since there's probably a point where it becomes faster to query the server than parse the local data. However, what I'd like to see is the ability to force the textures of your choice to stay resident in the local cache. The library textures ought to stay on the HD, as well as the default particle texture and all tree textures. Any texture that you've uploaded ought to stay resident as well, perhaps with a viewer to delete older versions of re-uploads.

The cache system could be better designed.
If assets were locationaly tagged then, then entire locations could be flushed at a time. Locations could be weighted, so that some would persist in the cache longer or shorter.
Av textures would be treated like locations.

IMHO weighting should be implemented and configurable by the user.
Last access time would effect the weight.

Currently only type and time effect the weight.

The current system has horrible problems managing images, really i don't need 2 week old map images. Old notecards or scripts from previous sessions? don't need 'em either.

Felix Uritsky Wrote:


I would have to agree with Felix here.
After awhile the size of a single massive cache would influience performance, However if each sims server created its own cache on your computer and named it after the name of that sim and maintained that cache within that 500-1000meg range, then this problem may be avoided.
Instead of one massive cache, you may build a local library of caches.


Again wonderful ideas Strife,
With the Havock 2 coming soon, I would love to see improvements on the cacheing system acompany it.
It would be a major leap for SL.

Thanks
Shjak Monde

Shjak, I think you're right-on here.


Actually, I think that querying the local cache for a specific item should always be fastest, as long as the local drive and CPU are fast enough, and the data is indexed properly.

Items should of course be identified in the cache by UUID, and the list of UUIDs that the cache has on file should be indexed efficiently. The index would be very small compared to the data, and that should make lookup extremely fast.


As far as I know, images and sounds never change. Rather, they might be replaced by different images or sounds. So when the client is told to display a texture, the only consideration should be whether or not it's in the cache, not whether or not it's changed.

Now, it's possible that with so many textures in use in-world, there's really just more data than the cache can hold. But I suspect that there's more network traffic happening than absolutely necessary.

HAHAHAHA
Havok 2 is the longest running joke in SL, it has been promised to use for... almost 3 years. They keep saying the next version, or the version after next. Normaly i'm positive and give LL the benifit of the doubt, but Havok 2 in SL is vaporware.

Chaching improvements wouldn't be too difficult to add to the client IMHO.

Actually yes, it should even be straightforward to pull out all of the client-side caching and replace it. If there are hooks in the server code, I imagine the hooks would be simple.

Thank you all for some very intuitive Posts.
I feel that in the overall, the sentement is a positive one to improve the cacheing System.
I have taken the idea to the next step and have made a proposal.


Prop: 989 - Takeing a Serious Bite out of Lag with a Local Static Cache Library
http://secondlife.com/vote/

Hopefuly we may generate the public interest and accumalate enough votes to get this initiated.
Again thank you very much.
Shjak Monde

Heya Shjak, thank you for pointing this thread out to me, as im not a programmer i dont understand alot of the numbers, but as an MMORPG developer studying in college to be so, I can see how the players of Mark Busch and My game Darklife would benefit from not having to load the darklife sim everyday, as alot of them seem to spend most of there secondlife slaying monsters on our sim.

Thank you Crash,
I do believe there will be an overall Improvement for everyone in SL and a Marked improvement in all of SL's Gameing Sims.
This will not be a complete cure (probably no such cure exsists), However every little bit helps.
Again thanks for the suport
Shjak Monde

You read my mind Shjak...I've been thinking for a long time how nice it would be to have the option of maintaining more data on my HD to make SL play more smoothly...if NOTHING else I'd love to see us be able to maintain a much larger texture cache (that does NOT delete the INSTANT you wander 30m away from something). But I'd gladly contribute 100gig of my hard drive if it would improve my SL experience! Dumped all my votes into Prop 989 and I'm hoping more people will see the potential benefit and get it up to 500 so that LL will take it into consideration.

The local cache is widely believed to be non-functional or badly broken. This is only bolstered by the somewhat recent addition of the "Clear Cache" button to Preferences->Network. Indeed, there are many reports that an empty cache (where requests have to be passed to the server) require less time to render than from a populated cache. This is kinda the opposite of how a cache is supposed to work.

Until such a time as LL deems the current cache worthy of fixing, I would hazard that suggestions for improvement are somewhat moot.

Why should the data in the cache be in a format that requires any more parsing than the compressed format received over the wire?

And since we know the sims use squid internally for caching data from the asset server, it should definitely be no slower to pull data out of a local cache structured like the squid cache, divided among files named by an efficient hash of the UUID. It would take up a lot more space on your local drive, but if it was 20 times as inefficient I'd still be able to hold four times as much data and it'd be accessed quicker.

I sorta promised LL i wouldn't spill the beans on how the cache works. I have a theory why it is slow when full and fast when empty. Searching. LL doesn't sort thier key cache table. As you can guess, this results in slow lookups. When the cache is empty, so is the key cache table. When it's full, it has to search though alot of keys that are not the correct key, many search algs, work best when their data is sorted. The trouble is, the cache contains when it's full, something like 26,000 assets. Most operating systems have a cow if you try to browse a folder with that many files in it. Some modern filesystems will start doing weird things when you get that high up. Thats about 40 kib per asset.

It's not the cache couldn't use the space, it's just that i couldn't find anything quickly.
If SL segmented it's key cache table, saying every key that starts 00 goes here... and every key that starts 01 goes here, they could drasticly reduce search times.

Long before the button was added, a patent answer from LL was to manually clear the cache, by deleting the files in the folder. This snakeoil was steadily touted as the solution to just about any problem.

Why the fuck not? If I sound pissy it's only because I am. The shit doesn't work worth a pile of mud. Why wouldn't they want everybody to know why, so that we can suggest some better strategies to them? Does somebody walk around the office all day long hitting these people in the head? They have a massively huge gigantic pool of talent at their fingertips. They tap it to build train stations and type notecards and orient new residents and advertise and organize conventions and the list goes on and on. But this omg the mind boggles I can't see help me the darkness is

I have heard this before.

Frightening if true, but the truth must be more subtle than that.

There are a lot of complex things in SL, far more complex than trivial logn key lookup algorithms we all learned in comp sci 101

I have heard this before.

Frightening if true, but the truth must be more subtle than that.

There are a lot of complex things in SL, far more complex than trivial logn key lookup algorithms we all learned in comp sci 101

I see your hundred gigs and raise you a hundred and fifty gigs. Or more if the cache could be split over two drives.

Hashing table ? Nah, it would make too much sense

So is there anything, that we, as customers, can do about it aside from mockery?

I fear not.

Fifty-thousand quatloos on the mockery

Despite what Torley said I found cache size did make a difference. Going from a 1000MB to 500MB cache I would get grey textures far more often, the 1000 cache could cope with you moving around quite a lot and not have to reload areas but the 500 dropped them quite quickly.

Exactly...

I've done hashed collections with over 400,000 objects, with really fast order(1) lookup on the elements using a simple string key.

There is no reason in the world why they couldn't do that, with only 26,000 entries in the list.

- Jon

I made some suggestions for improvement here, which would also allow for more user control, and a (sort of) backup system:

/108/12/81593/1.html

It seems to me that the asset tags are _already_ hashkeys. It should be trivial to look them up quickly.

Of course I'm also confused why there apparently needs to be one central asset server when it should be trivial to distribute the assets based on a hash (which we already have! All assets ending with an odd number on server 1, even on server 2).