[sldev] Bandwidth requirements

[Phoenix]

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.


On 2007 Jan 22, at 17:24, Tim Shephard wrote:
> I agree David, with terrabyte hard drives coming out, it would be nice
> to hear some background to the decision to cap out caches to 1GB (at
> least according to the user interface).
>
> I'd like to say it's a very large gaping hole in the architecture, but
> I think there must be some reasoning since it's been this way for so
> long and theoretically would be very easy to fix.
>
> Can a linden comment on this?
>
> Regards,
>
> Tim.
>
> On 1/22/07, David Baker <david_baker at iinet.net.au> wrote:
>>
>>
>> Hi all,
>>
>> I have been looking at the open source codebase with an eye to  
>> seeing what
>> can be done to reduce the bandwidth requirements of the client -  
>> both from
>> the client's perspective and from LL's perspective.  My general  
>> thoughts on
>> this have been that the client would benefit from:
>> 1) a caching system that actually works - if SL can take 1GB of my  
>> hard
>> drive to cache things it downloads, how come when I log out of SL and
>> immediately log back in in the same place everything has gone grey?
>> 2) the ability to share assets on a peer-to-peer basis - which should
>> hopefully reduce loads on LL servers (possibly allowing them to  
>> support mroe
>> avatars per simulator), improve load times for those of us in far- 
>> flung
>> places and potentially permit the favoring of data from other  
>> users sharing
>> an ISP.
>>
>> My motivation in this is that, as an Australian, I am on a capped  
>> data
>> Internet plan and when you only have 20GB/month available to you  
>> the fact
>> that SL likes to use 200-250MB/hour gets quite limiting.  Anything  
>> that can
>> be done to reduce this would definitely improve take-up in  
>> Australia (and
>> remove my temptation to upgrade to a $130/month plan).
>>
>> Has anyone else been looking at this?  Care to compare notes?
>>
>> Regards,
>>
>> David
>> _______________________________________________
>> Click here to unsubscribe or manage your list subscription:
>> /index.html
>>
>>
>>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070123/4693872c/PGP-0001.pgp