SL Viewer Caches...Again : )

[Wallace Wirefly]

I have read some trying to understand "The Cache" used in SL viewers. From what I gather it is something that was put in place long ago to be used as a "temporary" cache stored on ones HD to help speed up retrieval of textures,sounds and such. Also I have read about the randomness with which these items are stored all over one's HD. If you were to look at your HD you will see that "cache" is put wherever there is a place to put it. No sequential order. Now long ago I could see this has helping to "speed up" ones expierence in sl since supposedly you did not need to retrieve this data from the server therefore freeing up time since the idea is it is faster to retrieve from HD than from server. But now in todays world of SL ,considering the randomness of "The Cache" and the huge increase in textures and land  I am wondering if this whole concept should not be addressed. One idea that I was thinking of is: Could Linden offer players a "Bundled" Cache to SL viewers? Most "Video Games" load the complete "World" onto ones computer in a nice neat package why can't Linden offer something like this? I would think that there are many "Items" common to the SL World that everyone could use and if these were given as a "Permanent cahce" I would think it would remove load from Server side and speed up ones expierence Inworld. So was wondering.. is this possible? If not why not? One could still have a "temporary" cache but one that would be much like ones used by Windows OS. Thanks

[Qie Niangao]

Scale.  There are probably terabytes of new assets uploaded every day.  It would demand prohibitive bandwidth to keep distributing all that content to keep a cache warm, and 99.999% of it would never be accessed.  So the cache is necessarily temporary because content is so dynamic.

Personally, I set the SL cache very small and keep it in memory, on a ramdisk (/dev/shm on Ubuntu).  There are a lot of misses, of course, but there always are, and at least hits are blindingly fast to retrieve.  When I reboot my machine, my cache is fully cleared; that's more a virtue than a drawback, IMHO.

[Peggy Paperdoll]

How would the viewer and server software know what is common to all users in order to download the "perminant cache"?.  What if that a texture (or many textures) changed because another user redecorated their home or business, or a shop owner updated the items for sale?  You or another user decided it's time to change clothes or avatars?  The content in SL is not finite...........the changes constantly.  That constant change makes storing the content on an individual's machine impossible.  It has to be stored on a central data base (servers) and delivered to each individual machine on a as needed basis  When the texture is needed by the viewer it is also copied to a cache so that, until that content changes, any future loading of the content will be delivered via the cache instead of the servers.........which does speed up the loading as long as the content remains the same for what the viewer is requesting.  I can see no possibility of perminantly downloading every content item to one's computer.  The storage requirement for any machine would be impossibly huge (100's of terrabytes).  The time to download all that content, even at the fastest Internet connection speeds, would be days or weeks...........then when something changes the viewer has to somehow know that and download it, store it and then figure out what to do with the older content (archive it or delete it?).  I don't see a home computer capable of handling such a task as what would be required.

That tossing data all over the hard drive is the nature of how computers store data..........not just caches, but every thing that is stored on the hard drive.  Programs and information that computers store are not in neat, tidy little bundles that are tightly grouped together so that they can be put all in one neat place on the drive.  Data gets updated or changed all the time and there's no way for any program to predict how large or small a file will be to allocate the neat spot all grouped together.......not to mention the huge amount of wasted space on your hard drive that would occur (a allocation of 20 MB to cover additional future requirements for a 10 KB file?).  Think of the SL viewer(s) as your web browser (that is actually exactly what the viewer is.........a specialized browser)..........the Internet is constantly changing and there is no way to predict what the content will be at any given instant and, therefore, impossible to download and store the data ahead of time.  You can put your cache at different locations on your computer that will confine it to a relatively small space.  Partition your drive (or use a second drive or flash drive) sufficiently sized (not too large and not too small) to confine the cache.  That prevents the caches from fragmenting your drive and makes searching the cache faster.

Caches are here to stay.  Defragmenting your hard drive often helps speed things up too.  Deleting or clearing your cache occassionally also helps speed things up (though the initial reloading of the cache will slow things doen until your surroundings are loaded again.........but in the long run it can speed things up for you).

[Jennifer Boyle]

If fragmentation of the cache is an issue, it's easy to avoid by creating a small partition and putting only the cache in it.

[Jenni Darkwatch]

Fragmentation will be a non-issue once SSDs become more affordable. It's already reasonably feasible to buy a small SSD and stuff the cache on it.

The larger problem with SL's cache mechanism is that it's an extremely poor cache implementation, too often getting corrupted because of faulty "clean/dirty" markers, not shareable between computers on the same network etc.pp.

HTTP Texture fetching should have enabled the use of large distributed well-functioning proxy caches - but of course LL in their infinitesimal wisdom made sure that this simple approach doesn't work right without some hacks.

Clearing the cache on every SL start is pretty counterproductive btw, though admittedly with the crap cache implementation it's a too-common practice.

[Peggy Paperdoll]

"HTTP Texture fetching should have enabled the use of large distributed well-functioning proxy caches - but of course LL in their infinitesimal wisdom made sure that this simple approach doesn't work right without some hacks."

-----------------------------------------------------------

Every time I see statements like this I wonder "if the person making the statement was so wise and knowledgable and it really is that simple, why would any company not perform that simple easy task?  I mean, it's so much less of a pain in the butt to do the easy fix than to deal with the consequences for not doing the easy, simple task."

My conclusion is that it's not so simple and definately not simple.  In other words the person making the statement does not know nearly as much as that person wants me to believe.  Caches get corrupted over time (any cache, not just the SL texture/object cache) due to errors in overwriting of existing data.  With the enormous amount of texture downloads, which then are cached, the probability of errors is much greater than most other caches.  You could surf the Internet for days at a time without downloading nearly as much data as you could download in an hour or two in SL.  Simple is only a figment of your imagination.

[Jenni Darkwatch]

The problem is that they added a session-specific UUID into the middle of the URL. As a result the caching doesn't work right. Here's a (dirty and somewhat buggy since it's ooold and uses some funky way to intercept the calls) snippet of code that _can_ and does cache textures properly. It presumes full-resolution texture fetching. I've since moved to a custom-written proxy that does fix the issues this script has and works perfectly well with multi-user setups, sharing the cache properly. I've not had a single cache corruption since.

If I can do that, so should LL.

 

<?// Texture caching intercept
// 2011-03-13: Initial experimental script to see if it can be done
// 2011-05-26: Rewritten from scratch, ditched functions, went for flat spaghetti code instead// The viewer requests data in this manner:// GET /cap/<TMP_UUID>/?texture_id=<TEXTURE_UUID> HTTP/1.1// Host: simXXXX.agni.lindenlab.com:12046// Connection: keep-alive// Keep-alive: 300// Accept: image/x-j2c// Range: bytes=0-599// Server returns something like this (usually):// HTTP/1.1 206 PARTIAL CONTENT// Date: Thu, 26 May 2011 18:34:17 GMT// Server: Apache/2.2.9 (Unix) mod_ssl/2.2.9 OpenSSL/0.9.8c DAV/2 mod_wsgi/2.3 Python/2.4.4// Content-Type: text/html; charset=utf-8// Connection: close// Transfer-Encoding: chunked// ============================================================================// GLOBAL SETTINGS$sqluser="myusername";$sqlpass="mypassword";$sqldb="slcache";
$logfile="slcache.log";

// ============================================================================// INIT: Open DB, files, etc.pp.// Connect to MySQL DB, though file based buffer should probably work just as well$sqllink=@mysql_connect("localhost:3306",$sqluser,$sqlpass) or die("Database error: ".mysql_error());mysql_select_db($sqldb) or die("Could not access database. Error: ".mysql_error());// Open log file for debug purposes$hLog=fopen($logfile,"a");// ============================================================================// ANALYZE QUERY AND FETCH INFO$sim=$_SERVER["SERVER_NAME"];$uri=$_SERVER["REQUEST_URI"];$uuid=substr($uri,strpos($uri,"=")+1);if(isset($_SERVER["HTTP_RANGE"])) {  // Client requested partial data. Regex was slower, hence the mess  $range=explode("-",substr($_SERVER['HTTP_RANGE'],strpos($_SERVER['HTTP_RANGE'],"=")+1));} else {  $range[0]=0;  $range[1]=33554431; // That's the same "max" value the viewer uses}// Log what we gotfwrite($hLog,date("Y-m-d H:i:s")." >> ".$sim." - \"".$uuid."\" - \"".$uri."\" - ".$range[0]."-".$range[1]."\n");// ============================================================================// CHECK LOCAL CACHE FIRST$result=mysql_query("select texture from texture where uuid='".mysql_real_escape_string($uuid)."' limit 1");if(mysql_num_rows($result)==1) {  $tmp=mysql_fetch_row($result);  $texture=$tmp[0];} else {  // Texture isn't in our cache, fetch it  // Connect to LLs servers  $ch = curl_init("http://".$_SERVER["SERVER_NAME"].":12046".$_SERVER["REQUEST_URI"]);  // Set custom header options  curl_setopt($ch, CURLOPT_MUTE, TRUE); // Tell curl to STFU   curl_setopt($ch, CURLOPT_BINARYTRANSFER, TRUE); // We expect binary data  curl_setopt($ch, CURLOPT_FILETIME, TRUE); // We do want the modification date  curl_setopt($ch, CURLOPT_HEADER, FALSE); // Don't return headers  curl_setopt($ch, CURLOPT_RETURNTRANSFER, TRUE); // No output desired, I need the body  curl_setopt($ch, CURLOPT_PORT, 12046); // SL Texture assets on port 12046  curl_setopt($ch, CURLOPT_HTTPHEADER, array('Accept: image/x-j2c'));  // Fetch data  $texture=curl_exec($ch);  // Check result code  $info=curl_getinfo($ch);  // Close connection  curl_close($ch);    // If we were not successful, die here.  if(substr($info['http_code'],0,2)!="20") {    // Some error - just pass it on     header("HTTP/1.0 ".$info['http_code']." ERR");    fwrite($hLog,date("Y-m-d H:i:s")." EE ".$texture."\n");    die($texture);      }  // Log what we got  fwrite($hLog,date("Y-m-d H:i:s")." << ".               $info['http_code']." - ".               $info['total_time']." - ".               strlen($texture)." - ".               "\n");  // Store the texture in our local db  $result=mysql_query("insert into texture set uuid='".mysql_real_escape_string($uuid)."',".                                             " accessed='".date("Y-m-d H:i:s")."',".                                             " texture='".mysql_real_escape_string($texture)."'");  if($result===FALSE) fwrite($hLog,date("Y-m-d H:i:s")." EE MySQL Insert: \"".mysql_error()."\"\n");}// ============================================================================// RETURN RESULT TO VIEWER// Rewrite header to indicate result - it appears the client doesn't really give a damn about the codeheader("HTTP/1.0 200 OK");// Return texture in bodyecho substr($texture,$range[0],$range[1]-$range[0]);// Update access time in SQL DB$result=mysql_query("update texture set accessed='".date("Y-m-d H:i:s")."' where uuid='".mysql_real_escape_string($uuid)."'");// Clean up, technically not necessaryfclose($hLog);mysql_close();?>

 If you're curious, writing cache code isn't hard. Especially not in a case like SL where textures don't change. My main job isn't programming, though it's part of my job. LL has some fairly skilled programmers - why can't they fix what I can?

Btw, this kind of cache is not nearly as fast as a local cache, but the goal was to have a shared cache on LAN/WAN circumventing LLs bandwidth limits, thus this approach.

Warning: Do not use that script! It has multiple remote-exploitable security issues and a logic error and it's just not terribly efficient. Good enough for testing, nothing more.

[Peggy Paperdoll]

Let me see now.  I'm a political junkie and I watch and read a great deal on almost everything polical.......just something I really enjoy.  I've been watching and reading almost maniacally the US Republican debates and campaigning both against each other and against Presiden Obama.  One of the hot issues at the moment is the price of gasoline in the US (more about the extremely rapid rise in the price than the fact that gas is going up in price).  Newt Gingrich says he has the answer.  He says he can bring the price down to $2.50 per gallon.  He laid out a very logical plan that, according to him, will accomplish his goal.  Everything he said makes perfect sense.  He has a knack for being totally logical and backs everything up with historical facts........you would be hard pressed to mount a argument against his logic and his facts.  Now, here's my question:

Would it work?  Is what he says true?  Has he left out some inconvenient facts (not lying but just leaving out a few tidbits of information that just may alter his conclusions if those facts were also told.........would his logic and historical facts be interpeted a little differently?  I don't know.  His assertion is certainly worth concideration but without the ability to know what has been left out (if anything) I can not agree or disagree.  I'm in the dark.  What he is saying is very much like what you are saying.  It's simple. It's easy. And "anyone" can figure it out.........but the present administration chooses not to try it.  Could it be that it really isn't that simple or that easy and that President Obama is exactly right when he says it's "complicated"?

Disclaimer............I'm not an Obama fan.  I didn't vote for him last election and I won't vote for him this election.  I actually like Newt Gringrich and I would consider voting for him come June when my state holds it's primaries.  But I don't think I totally believe what he says about $2.50 a gallon gasoline.  I do know that if the price of gas was a simple fix it would have been fixed long ago............polititions are very good at doing simple stuff (it's the hard stuff they can't........actually don't do).

I still think "simple and easy" is a figment of your imagination.

[Jennifer Boyle]

It seems like we are getting way off topic, but I am going to respond.

The United States is consuming way too much imported petroleum and is producing way too much harmful emissions.  Lower prices for gasoline will increase consumption and harmful emissions; higher prices will decrease them.  We need higher prices.  I have seen many well-dressed, middle-aged people riding motorscooters, bicycles, and public transportation in Europe.   One of our big problems is that we have so many people who think that they have a God-given right to low-priced gasoline.  No one has any right to any price for anything other than the price that a free market offers.

[Qie Niangao]

Follow the votes.  

• What happens to oil prices when war with Iran appears likely?  
• Which party in the US presidential election benefits from higher short term oil prices?  
• Now, which party is promoting an Iran attack?

It's a neat trick if the electorate is stupid enough.

[PeterCanessa Oh]

---

Wallace Wirefly wrote:

...Most "Video Games" load the complete "World" onto ones computer in a nice neat package why can't Linden offer something like this?...

---

Well done - you have found the single biggest difference between SL and a "video game".  As Qie, et al, explained; SL just isn't like that so the same methods often aren't applicable.  When that really sinks in it explains an awful lot about SL and even LL.  Enjoy.

[Jenni Darkwatch]

---

Peggy Paperdoll wrote:

[...]

I still think "simple and easy" is a figment of your imagination.

---

Aside from pollutical references that mean nothing to me, just consider this: Caching is successfully implemented pervasively throughout anything that runs software. The most well-known cache mechanism is probably in web browsers. In complexity that one is roughly the same as SL caching. There are far more difficult caching strategies employed by computer hard drives and even by operating systems like Windows, Mac and Linux or even by CPUs.

To me it feels like you're trying to argue that LL is incapable of implementing a working cache where the rest of IT can get caching right. What makes LL so special that they cannot write a pretty stupidly simple cache?

[Peggy Paperdoll]

"To me it feels like you're trying to argue that LL is incapable of implementing a working cache where the rest of IT can get caching right. What makes LL so special that they cannot write a pretty stupidly simple cache?"

--------------------------------------------

Because you are saying that the caching for SL is identical to the caching of Internet Explorer, Safari, or Chrome.  I could go along with that is SL was not a unique program, very different than the Internet (about the only common link if that SL is delivered via the Internet).  A viewer is a specialized browser made to handle the unique Second Life program.  I'm pretty sure you don't know how SL is coded..........evidently neither does anyone else except the Open Sim project grids which reverse engineered the SL server code to come up something very similar.  Now, why is it that those grids have the indentical cache issues as SL?  If it's so simple why hasn't, at least one, of the Open Sim grids fixed it?  There's something that makes the cache issues that everyone experiences occassionally...........I don't know what it is and I don't think you do either.

It's easy to say the the LL coders are idiots for not fixing something you see that is easy to fix.  But, since no one else has fixed it yet it appears that you're making judgements based on incomplete facts.  That's all I'm saying.  Creating a cache is a known art for browsers but, obviously, it's little more difficult to create for something like SL.  Keeping your cache small, clearing it regularly, and even moving it to a second drive or partition "fixes" it for me.............I haven't had a cache issue in 3 or 4 years.

[Jenni Darkwatch]

Minor flaw: I have fixed the cache for me. Just not in a way that's useful to the majority of people in SL since it addresses specific needs of mine. It's currently 240GByte in size.

[Perrie Juran]

---

Jenni Darkwatch wrote:

Minor flaw: I

have

fixed the cache for me. Just not in a way that's useful to the majority of people in SL since it addresses specific needs of mine. It's currently 240GByte in size.

---

Two questions if I may.  I have no ball in this game but you have piqued my curiosity. And I will also acknowledge my ignorance of coding.

First, you said that the code you posted above has security issues.  Is this code different than the code you use and if so is the code you use free of security issues?

Secondly, if you have a 'superior' caching code that is free of security issues, why aren't you making it available?

[Peggy Paperdoll]

Oh  I have no doubt you fixed your cache.  The problem, as stated by you, it fits your speicific needs.  I would imagaine that if the fix for you won't work for most others it's not a good fix for LL to impliment.  I fixed mine too.  512 MB (the default) on a separate hard drive.........and I clear my cache for every log in.  It takes maybe 15 seconds longer for everything to load upon my initial log in and sometimes a few seconds longer when I go to my familar haunts.........after that, it's lightning quick.  And, as I mentioned before, I haven't had a cache problem for 3 or 4 years.  My fix would work for almost anyone........even if they don't have mulitply hard drives in their systems since you can create a partition quite easily these days (not like the old days when that was a scary process).

[Jenni Darkwatch]

---

Perrie Juran wrote:

First, you said that the code you posted above has security issues.  Is this code different than the code you use and if so is the code you use free of security issues?

Secondly, if you have a 'superior' caching code that is free of security issues, why aren't you making it available?

---

The code is lacking safety checks. It doesn't query whether or not the requested UUID is actually a valid UUID, nor does it do any safety checks on the destination. The code I use now is different, it's a flat multithreaded proxy specifically written for SL. As near as I can tell the new code is safe to use. I'd never claim the new code is entirely free of security issues, just that it is safe as far as I can tell.

In no way shape or form is the code superior, it's too specific to my needs which is why I never made it available. Because it's specific to my needs it also has some extremely specific network setup requirements. I debated whether or not to put it on the forums but decided against it considering it's extremely narrow use-case and requirements. Not to mention that the code isn't exactly high quality.

Specifically, the proxy cache was meant to allow sharing a cache between multiple simultaneous users across different PCs on a private WAN without requiring a patch of the original LL code. I've patched LLs code in v1 days to do that, and it's a pain in the ass. With the rapid release cycle of the current client it'd be a ridiculous effort to keep patching it into every new release. To write it into the LL code properly (i.e. multithreaded) would require significant time which I refuse to invest. Not technically difficult for a good programmer, though not something entirely easy for me.

The requirements are also very specific, though I haven't tried whether it's possible to simplify it:

- Requires a Linux as network gateway. That's the big requirement that I doubt all that many people have.

- Requires PHP+cURL+mySQL+xinetd+cron

- Requires iptables with some libraries (usually installed by default)

[Jenni Darkwatch]

---

Peggy Paperdoll wrote:

Oh  I have no doubt you fixed your cache.  The problem, as stated by you, it fits

your speicific needs

.  I would imagaine that if the fix for you won't work for most others it's not a good fix for LL to impliment.  I fixed mine too.  512 MB (the default) on a separate hard drive.........and I clear my cache for every log in.  It takes maybe 15 seconds longer for everything to load upon my initial log in and sometimes a few seconds longer when I go to my familar haunts.........after that, it's lightning quick.  And, as I mentioned before, I haven't had a cache problem for 3 or 4 years.  My fix would work for almost anyone........even if they don't have mulitply hard drives in their systems since you can create a partition quite easily these days (not like the old days when that was a scary process).

---

I'm sorry but clearing the cache on every start is ludicrous. You could then just as well forget about caching entirely.

[Peggy Paperdoll]

But, it fixes the caching problem, doesn't it?  I also clear my cache and history for my Internet browser.  And I seldom have problems with that either..........though, to be honest, I do occassionally have cache issues with my browser.  Should I hammer Microsoft about that? 

[Jenni Darkwatch]

Meh forget it. Do whatever you like. Again, you could just turn off caching (almost) everywhere. Sure that'd fix potential "issues", though I've never ever heard or encountered IE cache issues or any others outside of SL actually.

[Perrie Juran]

---

Jenni Darkwatch wrote:

---

Perrie Juran wrote:

First, you said that the code you posted above has security issues.  Is this code different than the code you use and if so is the code you use free of security issues?

Secondly, if you have a 'superior' caching code that is free of security issues, why aren't you making it available?

---

The code is lacking safety checks. It doesn't query whether or not the requested UUID is actually a valid UUID, nor does it do any safety checks on the destination. The code I use now is different, it's a flat multithreaded proxy specifically written for SL. As near as I can tell the new code is safe to use. I'd never claim the new code is entirely free of security issues, just that it is safe

as far as I can tell

.

In no way shape or form is the code superior, it's too specific to my needs which is why I never made it available. Because it's specific to my needs it also has some extremely specific network setup requirements. I debated whether or not to put it on the forums but decided against it considering it's extremely narrow use-case and requirements. Not to mention that the code isn't exactly high quality.

Specifically, the proxy cache was meant to allow sharing a cache between multiple simultaneous users across different PCs on a private WAN without requiring a patch of the original LL code. I've patched LLs code in v1 days to do that, and it's a pain in the ass. With the rapid release cycle of the current client it'd be a ridiculous effort to keep patching it into every new release. To write it into the LL code properly (i.e. multithreaded) would require significant time which I refuse to invest. Not technically difficult for a good programmer, though not something entirely easy for me.

The requirements are also very specific, though I haven't tried whether it's possible to simplify it:

- Requires a Linux as network gateway. That's the big requirement that I doubt all that many people have.

- Requires PHP+cURL+mySQL+xinetd+cron

- Requires iptables with some libraries (usually installed by default)

---

Thank you for responding.

[Wallace Wirefly]

Thanks for all the insight into this interesting but what seems to be for some a troubling issue. I do not confess to be a programmer nor fully understand differences in "code" and storage of such. From what I read here is that because SL is such a changing world every day that the idea of permanent cache is impossible? So I am to compare it to  "browsing" the internet type of thing compared to playing a static game like WOW or COD. And I should be thankful that LL stores all this data and provides us with constant updates through efficient updates of my cache to make sure I "see" the world correctly.

Still haven't figured out whether its better to clean daily (like brushing your teeth ) or to keep small cache and let "the code" take care of randomness of my cache. I guess this something like sim crossings and lag that will have to wait till technology and new know how comes up with a better idea than the one I was thinking. Thanks for all the insight....oh and please lets not bring politics into a technical discussion....this is wayy over any politicians head :matte-motes-big-grin:

[Jenni Darkwatch]

Your understanding of the cache mechanism is basically correct. The SL cache gets populated as you go, i.e. it won't get populated with data you haven't encountered yet.

As far as clearing cache: In theory, clearing any cache pretty much defeats the purpose of having a cache in the first place. If you clear cache, your SL client has to re-download everything from scratch.

On the other hand the SL cache code is buggy. It's been worse in the past, but it's still bad. If you encounter textures that just won't load (or sculpties, they're textures too) or problems with your inventory, you pretty much have no choice than to dump the entire cache.

The size of the cache affects how your SL experience will be, especially if you use higher draw distances. The smaller the cache, the sooner textures and various other items get tossed out of the cache, meaning your client re-downloads them from scratch the next time you encounter it. In theory a big cache would therefore be ideal. Except that the buggy cache code means that it's not necessarily likely that the current (approx.) 10GB limit ever gets reached.

[Madelaine McMasters]

---

Wallace Wirefly wrote:

Thanks for all the insight into this interesting but what seems to be for some a troubling issue. I do not confess to be a programmer nor fully understand differences in "code" and storage of such. From what I read here is that because SL is such a changing world every day that the idea of permanent cache is impossible? So I am to compare it to  "browsing" the internet type of thing compared to playing a static game like WOW or COD. And I should be thankful that LL stores all this data and provides us with constant updates through efficient updates of my cache to make sure I "see" the world correctly.

Still haven't figured out whether its better to clean daily (like brushing your teeth ) or to keep small cache and let "the code" take care of randomness of my cache. I guess this something like sim crossings and lag that will have to wait till technology and new know how comes up with a better idea than the one I was thinking. Thanks for all the insight....oh and please lets not bring politics into a technical discussion....this is wayy over any politicians head :matte-motes-big-grin:

---

Exploring SL is much like surfing the web. The contents of a sim (webpage) are dynamic. People alter their builds and scripted objects change their position and characteristics. There are more than 20,000 sims in SL, no two alike (except potentially the Linden Homes sims, which may share a lot of textures). Your hard drive would not be large enough to cache even a small portion of SL, even if SL were static.

As for fragmentation of the cache, if your hard drive is already fragmented, your OS will have no choice but to toss cache files whereever they will fit. No disk access will be as slow as pulling an asset from the SL servers, so caching should always improve performance.

I run my cache at maximum size and get better overall performance than when running it small. That's all the metric I need. I have noticed that while my MacBook Air (with SSD drive) has lower frame rates than my quad core iMac, scene rezzing after TP goes faster. I attribute this to vastly faster access to cache files on the SSD.

I only clear cache (as Jenni suggests) when I find a stubborn texture that refuses to load at full rez. That's the most common error I see, that the cache appears to think that one of the early steps in the progressive load of a texture is the final one. I suppose it's not commonly known that textures load progressively, with low resolution versions loading first, so you get some sense of what's in the scene as soon as possible. Texture resolution improves over time as more pixels arrive. I'm not sure if this is done by incrementally updating cached textures in place (most bandwidth efficient) or by replacing them entirely with higher resolution versions, but I do know from watching scenes rez that textures load in progressively higher resolution.

[PeterCanessa Oh]

---

Wallace Wirefly wrote:

...So I am to compare it to  "browsing" the internet type of thing compared to playing a static game like WOW or COD...

---

That's a pretty good way of putting it I think.  Also note that if you stay within the same few sims the cache will stabilise as there isn't much new for it to retrieve.  EVERYTHING gets much smoother then - higher fps, lower bandwidth, smoother movement, etc. etc,