How much cache would you set up if you could...

The current texture cache uses a complex virtual file system with only "overflow" showing up as separate files in the file system. If Linden Labs bypassed the VFS for large textures, and instead uses a Squid/Harvest style three level file system cache, they could efficiently cache a more or less unlimited number of textures on your local hard drive. If they did that, and you could set your texture cache to any size you want, how big would you make it? This is particularly relevant as "bandwidth" caps are becoming more common.

Your disguised feature suggestions don't fool me!

Start at 100GB and work up

Oh, I made the *feature suggestion* years ago, and opened a Jira on it last year. A recent post in the forums about bandwidth caps made me want to know how much benefit the feature really would provide.

I mean, hell, I didn't even include a link to http://jira.secondlife.com/browse/VWR-10224!

lol

I have 200GB free on my PC, which I could easily dedicate to caching SL textures since I have no other plans to use that free space.

I voted 300GB or more since it's kind of a "how long is a piece of string?" question. A sky's-the-limit capacity that would allow residents to cache however many files they wish seems appropriate.

I am certain that 1GB is completely unsatisfactory since the periodic necessity of clearing cache is plain tiresome. How many times do I need to stand still while the client downloads an animation my AO has played countless times before? Or wait for a favourite sim, including my home, to reload texture by texture?

As big as it wants as long as it makes it faster. If it could do >300GB efficiently, and improved performance, I'd be all over that.

Since sites routinely have hundreds of gigabytes of Harvest caches, I think it could do it efficiently.

http://www.youtube.com/watch?v=zjqZ0aIAgFM

The only song worthy of this posting.

I only have 25GB free on my laptop's 100GB drive, so I voted 10.

I'm interested to know how much we need for it to be worthwhile.

I fail to see the connection.

I don't know if this helps or not, but caching of textures, animations, etc, is one of the strategies employed by Blue Mars to minimise the amount of data to be streamed. Their SDK download is 1.4Gb, and 1 Gb of that is textures.

What is it? I can't access YouTube in my neck of the woods.

That's called "cache preloading" and isn't relevant to a virtual world with primarily user-created content. Second Life already caches textures, animations, etcetera... it just doesn't cache enough of them because of some poor implementation decisions made a long time ago in a galaxy far far away.

Looks like the spam song from Monty Python.

Edit: Nah, it's some spam parody of "Stand" by REM.

Ditto Lear's comment in that case. Explain yourself, Ms Ryan!

Would this fancy-pants cacheing system give advice? Maybe keep some history and try to tune itself, or advise the human user to change settings once in awhile?

In a situation where several/many people at one RL lcoation are in SL together (business/school/etc), could they share a cache? That seems to me to be a big win.

It's not a fancy-pants caching system, it's a simple one. A simple large cache will almost always beat out an over-complicated small one, many times over.
Not until they switch to TCP for textures, so you can use an external squid proxy.

/me has about 400GB free but votes for 3GB anyway.

What would be good would be if it allowed for different caches with different characteristics. Baked avatar textures are pretty short-lived while other textures never, EVER change. Inventory is fairly constant, probably tends to grow more than it shrinks for most people and, again probably for most people, is only really ever 20% in use. Is the interest list cached? If so, there's yet another set of stuff that could benefit from a tweaked setup.

With all this stuff just piled into one cache, even a squiddy cache, I think it'd be more annoying at cache-clear time to have a ton of disk dedicated to it. If it was a smarter setup and knew how to deal with the different use-cases, I'd probably vote for more. LL wouldn't do that, though - if anything, they're moving towards dumbing down the viewer.

/me has suggested this, though maybe not in jira, a bunch of times over the years. SL is so bandwidth-heavy that it would indeed be a big win if businesses could set up a local cache on their corporate LAN..

You wouldn't need to clear the cache with this scheme, because partially downloaded files in the cache would be ignored and deleted if they hadn't been downloaded by the current instance of the client. Simpler really is better.

/me paraphrases: no part of this will EVER break, get corrupted or be sent crap info from the LL servers - there's no need to have a recovery plan! Inconceivable!!

Er.. Sorry if I sound a little wary about this.

I don't mean there is no need for a recovery plan, I mean that this kind of cache does not have the complex on-disk data structures that make frequent cache cleaning necessary.

How often do you run checkdisk/fsck?

Maybe once a year unless I get crashy.