Better Cacheing System Idea
|
Shjak Monde
Registered User
Join date: 10 Feb 2004
Posts: 111
|
02-02-2006 02:09
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: From: someone Hi Shjak! My own personal experience has been that I've left cache size to 500MB because I haven't noticed any substantial gains setting it to 1000MB. Some may have noticed benefits, but in all my travels, it hasn't made a practical impact to load things quicker. 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: From: someone One of the reasons is because SL is such a dynamic world--even in frequently-visited areas, there's a lot that changes. So it's not directly analogous to a typical HTML webpage, which may be static, or requires less data than a typical SL "scene" takes to load (keeping changes in mind like avatars moving in and out, new objects being rezzed with different textures, etc.). 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: From: someone Now, like yourself, I feel there's certainly some frequently-visted places that I would think could be stored better--i.e. I visit the Welcome Area a lot so I wish I could persistently cache the main builds there and efficiencize things after a long night of journeying--as well as improvements that our engineers are working on. 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
|
Felix Uritsky
Prime Minister of Lupinia
Join date: 15 Dec 2004
Posts: 267
|
02-02-2006 14:52
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.
|
Strife Onizuka
Moonchild
Join date: 3 Mar 2004
Posts: 5,887
|
02-02-2006 16:51
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.
_____________________
Truth is a river that is always splitting up into arms that reunite. Islanded between the arms, the inhabitants argue for a lifetime as to which is the main river. - Cyril Connolly
Without the political will to find common ground, the continual friction of tactic and counter tactic, only creates suspicion and hatred and vengeance, and perpetuates the cycle of violence. - James Nachtwey
|
Shjak Monde
Registered User
Join date: 10 Feb 2004
Posts: 111
|
02-02-2006 18:50
Felix Uritsky Wrote: From: someone 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. 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
|
Travis Bjornson
Registered User
Join date: 25 Sep 2005
Posts: 188
|
02-02-2006 19:22
Shjak, I think you're right-on here. From: someone there's probably a point where it becomes faster to query the server than parse the local data. 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. From: someone SL is such a dynamic world--even in frequently-visited areas, there's a lot that changes 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.
|
Strife Onizuka
Moonchild
Join date: 3 Mar 2004
Posts: 5,887
|
02-02-2006 19:48
From: Shjak Monde With the Havock 2 coming soon, I would love to see improvements on the cacheing system acompany it.
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.
_____________________
Truth is a river that is always splitting up into arms that reunite. Islanded between the arms, the inhabitants argue for a lifetime as to which is the main river. - Cyril Connolly
Without the political will to find common ground, the continual friction of tactic and counter tactic, only creates suspicion and hatred and vengeance, and perpetuates the cycle of violence. - James Nachtwey
|
Travis Bjornson
Registered User
Join date: 25 Sep 2005
Posts: 188
|
02-02-2006 21:17
From: someone 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.
|
Shjak Monde
Registered User
Join date: 10 Feb 2004
Posts: 111
|
02-04-2006 08:38
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
|
Crash Prefect
Darklife Art Director
Join date: 4 Dec 2004
Posts: 55
|
reducing lag
02-04-2006 09:27
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.
|
Shjak Monde
Registered User
Join date: 10 Feb 2004
Posts: 111
|
02-04-2006 10:22
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
|
Herzog Svarog
The Wise(ass)
Join date: 9 Nov 2004
Posts: 74
|
02-22-2006 09:15
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.
|
Introvert Petunia
over 2 billion posts
Join date: 11 Sep 2004
Posts: 2,065
|
02-22-2006 09:29
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.
|
Argent Stonecutter
Emergency Mustelid
Join date: 20 Sep 2005
Posts: 20,263
|
02-22-2006 17:43
From: Felix Uritsky 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. 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.
|
Strife Onizuka
Moonchild
Join date: 3 Mar 2004
Posts: 5,887
|
02-22-2006 18:08
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.
_____________________
Truth is a river that is always splitting up into arms that reunite. Islanded between the arms, the inhabitants argue for a lifetime as to which is the main river. - Cyril Connolly
Without the political will to find common ground, the continual friction of tactic and counter tactic, only creates suspicion and hatred and vengeance, and perpetuates the cycle of violence. - James Nachtwey
|
Khamon Fate
fategardens.net
Join date: 21 Nov 2003
Posts: 4,177
|
to add, well, there's nothing to add
02-22-2006 19:32
From: Introvert Petunia 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. 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. From: Strife I sorta promised LL i wouldn't spill the beans on how the cache works. 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
_____________________
Visit the Fate Gardens Website @ fategardens.net
|
Iron Perth
Registered User
Join date: 9 Mar 2005
Posts: 802
|
02-22-2006 19:35
From: Strife Onizuka LL doesn't sort thier key cache table. As you can guess, this results in slow lookups. 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
|
Iron Perth
Registered User
Join date: 9 Mar 2005
Posts: 802
|
02-22-2006 19:43
From: Strife Onizuka LL doesn't sort thier key cache table. As you can guess, this results in slow lookups. 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
|
SuezanneC Baskerville
Forums Rock!
Join date: 22 Dec 2003
Posts: 14,229
|
02-22-2006 20:43
From: Herzog Svarog YBut I'd gladly contribute 100gig I see your hundred gigs and raise you a hundred and fifty gigs. Or more if the cache could be split over two drives. 
_____________________
-
So long to these forums, the vBulletin forums that used to be at forums.secondlife.com. I will miss them.
I can be found on the web by searching for "SuezanneC Baskerville", or go to
http://www.google.com/profiles/suezanne
-
http://lindenlab.tribe.net/ created on 11/19/03.
Members: Ben, Catherine, Colin, Cory, Dan, Doug, Jim, Philip, Phoenix, Richard, Robin, and Ryan
-
|
Jesrad Seraph
Nonsense
Join date: 11 Dec 2004
Posts: 1,463
|
02-23-2006 03:15
From: Strife Onizuka 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. Hashing table ? Nah, it would make too much sense 
_____________________
Either Man can enjoy universal freedom, or Man cannot. If it is possible then everyone can act freely if they don't stop anyone else from doing same. If it is not possible, then conflict will arise anyway so punch those that try to stop you. In conclusion the only strategy that wins in all cases is that of doing what you want against all adversity, as long as you respect that right in others.
|
Introvert Petunia
over 2 billion posts
Join date: 11 Sep 2004
Posts: 2,065
|
02-23-2006 03:25
So is there anything, that we, as customers, can do about it aside from mockery? I fear not. 
|
Khamon Fate
fategardens.net
Join date: 21 Nov 2003
Posts: 4,177
|
02-23-2006 06:56
Fifty-thousand quatloos on the mockery
_____________________
Visit the Fate Gardens Website @ fategardens.net
|
Eata Kitty
Registered User
Join date: 21 Jan 2005
Posts: 387
|
02-23-2006 07:01
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.
|
Jon Marlin
Builder, Coder, RL & SL
Join date: 10 Mar 2005
Posts: 297
|
02-23-2006 09:56
From: Jesrad Seraph Hashing table ? Nah, it would make too much sense  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
_____________________
Come visit Marlin Engineering at Horseshoe (222, 26) to see my line of flying vehicles.
|
FlipperPA Peregrine
Magically Delicious!
Join date: 14 Nov 2003
Posts: 3,703
|
02-23-2006 11:03
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
_____________________
Peregrine Salon: www.PeregrineSalon.com - my consulting company Second Blogger: www.SecondBlogger.com - free, fully integrated Second Life blogging for all avatars!
|
Polka Pinkdot
Potential Slacker
Join date: 4 Jan 2006
Posts: 144
|
02-23-2006 11:08
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).
|