[sldev] Reformatting Textures for the cache

Laurent Laborde kerdezixe at gmail.com
Fri Mar 23 01:04:23 PDT 2007

On 3/23/07, Tim Shephard <tshephard at gmail.com> wrote:
> We'll see.  In the current implementation, as Tofu Linden says, we are
> CPU bound so there is little chance of straining the file system.   As
> far as I can tell, the file system cache is meaningless in the current
> implementation .. all it does is save on bandwidth.

In an ideal world, we shouldn't have to spend so much time in cache
We could just store a few big texture and get everything else by network.
Even if i can't believe that loading a texture from a remote cache
(memory and hdd of the netowrked server) is faster than loading it
from the local cache.

Anyway, we're not in an ideal world :
- We have packet loss
- We have high ping (i have a 250/300ms ping to SL server, just that
is enough to grab a local texture even from a poorly designed cache)
- We have some high image time on the remote server. (it's A LOT
better since a few days)

The problem is _partially_ cpu bound. My 2nd core is sleeping a lot.
Spending more time requesting a texture UUID than decoding it (if i
understand the texture console correctly).

i'm running a lot of test, one of the problem that slow down my
computer is : i think, the client request FAR TOO MUCH texture at once
from the disk. look like my disk try to read something like hundreds
of file at once. (ok, maybe not hundreds, but a lot).

It also probably kill all kind of Filesystem optimisation like :
- predict and put the next hdd cluster to be requested on the hdd
cache internal cache
- the hdd head is moving all over the disk trying to read all thoses
opened file at once
- the disk cache (in system memory) is probably missing everytime.
- defragmenting the disk don't help a lot if you request many, many
file at once.

Ok, maybe i'm wrong and maybe the client don't try to read tons of
file at once, but it seriously look like it.

kerunix Flan

More information about the SLDev mailing list