[sldev] Bandwidth requirements

[Strife Onizuka]

Texture lag (lag caused by serving textures) historically was a major
problem. Areas like the city sims west of Dore, plagued by texture lag.
Those sims are double prim, so the land is valuable but there are so many
textures in each sim they got very laggy (because the sim had to spend much
of it's time serving textures). Which is why there are only 4 city sims with
double prims on the mainland.

It has been a long time since they released the city sims.

Pheonix could you talk to us about briefly about how textures are served? I
know there have been a number of changes in the past years...

----

I accidentaly didn't reply to all last time so i'll repost...
this was in response to tim's post.

---

I'm not a linden but I'll answer your questions regardless.
The issues with the cache are these:
1) Size of assets
2) Number of assets

Assets range in size from a few hundred bytes (animations) to a few hundred
kilobytes (textures). For this reason they used a single file to house the
cache. Their adressing system uses 32 bit addresses which limits them to a
cache size of 4 GB.

The next issues is the number of assets. The average asset size is around 64
kilobytes. Which means a typical 1GB cache holds around 16 thousand assets.
Likewise there is a lookup table with keys and addresses. The reason the
cache is limited in size, has more to do with searching then anything else.
When you have a lookup table of 16000 items, it is very time consuming to
find anything in the table. Very few file systems can handle this quantity
of items gracefully.

It doesn't take a great leap of imagination to figure out how to optimize a
file system storage method.

----

On 1/23/07, David Baker <david_baker at iinet.net.au> wrote:
>
> 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*
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070123/f1e909a4/attachment.htm