Cache management: smaller = better?

I am wondering if it may improve my performance to make my cache extremely small. I clear my 500MB cache fairly often, because I get into a state where textures refuse to fully download (very fuzzy textures that never fully rez). It is particularly noticable in stores.

The problem seemed to get worse when I upped the cache size (to 800MB). I suspect that what is happening is that my CPU cannot finish updating the cache when a lot of textures change at once. So, (watching the texture console) downloading textures appears to stall. Actually, if I stand in one place long enough, I can watch textures go from clear to fuzzy ... I think they may age out of the cache, and then never fully reload. For me, bandwidth is less of a constraint than local CPU cycles (SL always runs at 100% CPU utilization) ... bad graphics chips so CPU is taking up the slack. Also, it's a laptop ... disk speed prolly not terrific.

If anyone has insight on this, I'd sure appreciate it!

Usually a bigger cache is a good thing, providing you have enough clear defragmented HD space available. If you TP a lot, the system will delete the oldest items in the cache and download the new textures in their place. If you have setting too high (such as draw distance) this will download textures etc for far away objects that you probably won't even bother taking a closer look at.

If you are struggling to see textures popping in (rezzing) it maybe your connection, bandwidth, ping, latency etc.

Setting your prefferences for one situation, will not always be right for another.

Turn off BumpMapping and shiny, turn down particles to around 50-100, move the flexi sliders to the far left, use lower terrain setting, Sun and Moon only, turn off ripple water, you can also turn off the Avatar Vertex Buffering and VBO, bandwidth to 2/3rd's of your actual connection speed (not isp quoted), music media to 32kbps, reducing your inventory to a sensible 5k of items, take off scripted objects (HUD's etc), primed hair and accessories before you TP, will allow the system to focus on filling your cache with the 'world around you' before you then apply them one by one, allowing each to render and work before the next.

Oh, and keeping your HD defragmented on a regular basis will help. Don't run programmes in the background while using SL is always a good thing. If you run certain anti-virus checkers, set them so they ignore the SL cache will speed things up a bit. Cold reboot your external router/modem (assuming you have one) at least once or twice a week (unplug it from the mains for 10-20 seconds).

Having a 'bad GC' isnt a good thing with a OpenGL programme, the GC still has to deal with the dynamics of rendering every texture and prim used in the game, the CPU will do some work, but its already busy with the computations of the VR environment and physics etc.

Thats the tip of the iceberg explainned... but there is more

Thanks AWM. I do nearly all of this already (keeping inventory at 6.5K while still building is a challenge!) ... and still it looks like the cache is simply not being populated fully. I clear it (by deleting the caches, not clearing) and login directly into the place that refused to rez before, and all is good for a while. Puzzling.

I am curious as to why people recommend rebooting one's router. If the link performance is not degrading, what is the concern?

Its recommended by most ISP's, especially A/DSL systems as it refreshes the connection node...

Effective cache size seems to be a trial and error thing found by testing your system with various size caches. The whole flaming system is way too complex to simply say: "bigger is better."

I have found that the rendering of water ripples and the rendering of the ground textures seems to depend on cache size. At 300M cache size, I never have a problem with those two renderings, but at 500M I occasionally do, and at 1000M, I always do; at 1000M, I have to clear cache everytime to assure proper rendering of water rippling and the ground. It seems that there are three textures that are involved in the ripple effect and when it fails, only one or two of the textures has rendered. For the ground texture failure, no matter what sim I'm in, the texture that is set for a certain height will be a vast and irritating blur: usually the zero meter texture, but it has happened instead at the second or third texture above the zero meter level, making mountain tops a blur instead. Obviously, something is happening between cache and program in those initial seconds that is unique to those two texture renderings, no other texture of any type ever exhibits any problem.
[/INDENT]

That is always the underlying problem with the open architecture of the PC systems.. the prolifercation of variances in system specs. Most programmes have to rely on the OS to cope with most things since the demise of DOS. What works for some, needed mean it will work for all.
Add to the confusion, some manufacturers make tweaks to the GC etc and supply their own drivers etc.

[/INDENT]
Fascinating! I wish we knew what the cache design was, that would probably clear things up a bit. I have begun to experiment with different cache sizes, but as you know it is a slow process, particularly as the state of the grid varies so much between different login sessions.

The observation about the 'vast and irritating blur' is very illuminating. I have seen this, but never attributed it to my (obviously often) borked cache management. It's nice at least to have a theory about it.

Some people tend to think of routers as toasters that just sit there and route when they are actually microcomputers that can be just as buggy as any other software. The worst culprit is usually memory leaks which will degrade throughput over time; I've yet to see a consumer router which doesn't do this. So, if you are trying to optimize every link in the application, cold booting the router can help.

There are some who like to gloss over the overwhelming evidence that the SL cache is rather broken* and has been since about forever. Rebooting your router can't really fix this, but is decent voodoo since you can't fix the cache.

* /327/96/207066/1.html