A really fascinating paper (PDF) on Second Life provides a detailed technical and statistical assessment of the Grid and gets into specific recommendations for how to improve the platform. Written by Matteo Varvello et. al. (poor Al never gets enough credit) it concludes:
“Second Life (SL) has received a lot of press coverage and even some major companies and governments have set up a presence on it. The one figure that is usually cited as an indication of the raving success of SL is its more than 10 million registered avatars.
We have carried out a detailed evaluation of a large portion of SL, and made some interesting observations. Almost 30% of the Regions do not attract any visitors, and only few Regions are quite popular. So one is tempted to para-phrase the famous American comedian W. C. Fields saying “I went to Second Life and it was closed”. We also find that avatars exhibit a behavior that very much resembles that of humans: they get together in popular places, where they frequently meet their friends.
From a systems perspective, we observe that SL shows that there is a high chance that every time an avatar connects to SL it will interact with a set of avatars it has repeatedly encountered before. This suggests that the caching system mentioned in Section 6.1.2 can be enhanced by taking into account the presence of highly synchronized avatars.
The main idea is to build a distributed cache using the information provided by the social network, i.e., that some avatars meet frequently in the virtual world. Therefore, avatars could first attempt to download data from their friends using the P2P network, and only resort to contacting the server when no friends are available. Moreover, having each friend store a different piece of content would reduce the size of the client’s cache size.
We are currently working on the deployment of a SL client which implements a Delaunay Network [3] [9] among ava-tars located in the same Region. At the same time, we are evaluating the effectiveness of a distributed caching system based on information derived from the social network.”
There’s a lot of highly technical looking analysis. Gives me something to read over the holidays. And much of it seems to support known knowns with maybe a few unknown now knowns thrown in.
It also somewhat reminds me of a post I did ages ago titled “The Empty World.” Posts about lag I leave to Hamlet.
I think the idea is great to analyze and make suggestions.
Here are some from me:
* Pop-up notifier when an avatar puts on something that makes his ARC go into red.
* Enhanced texture library -> buy a few tons of textures, quality textures at least the quality of Halflife 2 or Far Cry or Doom 3. (Esp. the first two is everywhere in SL anyway.) Encourage people using this with features like… see below.
* Color-code sims on map based on the load it would put on your machine. Maybe people will forgot the stupid 1K textures.
* Background pre-loading for simulators -> Have another option of tp-ing. You could chat/etc. for 1 more minute before this ‘new tp’-option would grey out.
* An intermittent black box would be cool too even if I know it will never happen. (A box where you and everyone who is just in the progress of tp-ing appears as an untextured silhoutte.) OK, this is fantasy.
GTG now.
great idea. if the regionally close avatars could switch to other common interest variables anytime this would be more valuable. btw what caching solution second life is currently using?
Kevin:
For Second Life content itself, most of what’s downloaded is cached on the client host’s disk, and that’s not shared with anyone else at the moment.
Avatar baked textures (with all clothing and skin layers combined into a single texture per section of the mesh) are stored on the disk of the simulator host where they were baked, and when your viewer requests someone’s baked texture from the simulator you’re standing in, they’re fetched via HTTP.
Most content shipped around within our own network is shipped with HTTP, and almost all HTTP requests go via a local Squid cache on the host, so they’re cached in RAM and on disk by Squid.
A good deal of the slowness in showing content has to do with the fact that almost everything still goes via UDP. We already have support for sending textures to the viewer via HTTP built into Snowglobe, but right now it is only used for map tiles AFAIK. Once we’re using it for all textures, this should help a lot with the apparent speed of loading.