[sldev] Bandwidth requirements

[David Baker]

Hi Pheonix,

Thanks for that info - there goes my easy data use reduction.

In relation to the second part of my original post, you mention that texture 
downloading is 80%+ of the bandwidth usage for the client.  Can you comment 
on what proportion of server load it contributes?  In other words, is there 
scope for a significant reduction in lagginess / ability to support 
additional avatars in a simulator through peer to peer exchange of textures? 
Not much point looking at that as a concept if it won't make much 
difference.  Also, the obvious architecture for such a system would rely on 
the uniqueness of texture UUIDs and that the texture with a given UUID 
cannot change.  Are these safe presumptions?

Cheers,

David


----- Original Message ----- 
From: "Phoenix" <phoenix at secondlife.com>
To: "Tim Shephard" <tshephard at gmail.com>
Cc: "David Baker" <david_baker at iinet.net.au>; <sldev at lists.secondlife.com>
Sent: Wednesday, January 24, 2007 4:54 AM
Subject: Re: [sldev] Bandwidth requirements

There are a lot of issues at work here so I will try to fill in some
holes.

During development years ago, we discovered that opening files on
win2k was so abysmally slow that we needed a specialized file cache
to reduce client stalls. This is implemented in the LLVFS class which
uses (in their various forms) the index.db2 and data.db2 files. Our
vfs implementation is usable, pretty fast, but not usable past a gig
or so of cache data.

As noted elsewhere, the 'first look' viewer is not using the vfs for
texture cache -- easily 90% of total bandwidth usage. Since the
viewer is only opening and decoding a small set of textures over a
few seconds, the file open overhead is no longer significant for
textures.

During startup, the viewer is still engaging in a lot of
initialization logic, and will let you in world before it is done. As
such, it has not even necessarily loaded (it uses asynchronous file
reads for textures) or decoded any textures even if they are cached.
It is always possible that there are cases where the cache is just
broken and it has to re-download the texture, but the new cache
scheme for the upcoming viewer will make this easier to detect.

*snip*