The Costs of Free Resources

We all like it: When we get something for free!

But the non existence of costs has also disadvantages: We tend to ignore the resources that are associated with what we use. This is simply the case, because there are no costs for us, that otherwise would provide an incentive to make a more economical use of resources.

In OSGrid users like that it is possible to upload textures, animations and sound files for free. Additionally the users do not have to pay for activities like creating new groups. To make it clear: I fully back these policies, because they support the development of OSGrid.

And at this point we should all  thank the donators that cover the costs of the central infrastructure of OSGrid and that help keep it running so well every day. For sure you all know about the new “donate” button on the new Elgg based OSGrid web site.

But the missing incentives to save resources has negative effects, that over time increase the costs for central grid services unnecessarily, reduce the performance and lessen usability in certain areas.

In the following paragraphs I pick two examples to describe these issues and how these could be solved by implementing policies and tools. With this article I want to initiate a discussion about these issues, before we experience a future rapid grows of free Opensim grids.

A)  Asset Usage

People tend to upload textures, animations and sound files even if they exist within the world already. From the user point of view the costs – the time needed to check if for example a texture is available already – is higher than simply uploading it once more. Such duplicates inflate the space required for the asset database and asset caches. Additionally duplicates increase the data that needs to be transferred and thus reduces Opensim performance.

Additionally people tend to upload multiple versions of an asset to test it in world until they are happy with the result. At the end they just use the last version. Such unused assets, assets that are not referenced anymore, still consume space in the asset database that could be freed.

Possible Solution

One solution would be to introduce incentives for a more economical use of these resources. Second Life does this with their L$10 uploading fee.

But even better would be, if Opensim is able find duplicates and unused assets. Alternatively this can be done on the fly, by using some Opensim extension, or by using database scripts that are run regularly, as part of an asset database maintenance task. The goal is to remove all unreferenced assets and to replace duplicate assets with a single copy, which might include the replacement of the corresponding UUIDs.

To efficiently find duplicates, data block sizes and hash values can be used. For sure only assets that cannot be changed by individual users separately can be replaced by a single asset copy. This is especially true for uploaded textures, animations and sound files, that cannot be changed within the viewer. Notecards and scripts, that can be changed in world, and other changeable assets cannot be replaced by a single asset database copy.

In practice OSGrid uses Fragstore to do dupe compression based on 256 bit hash values for nearly 3 million assets, now. The compression achieved is about 25 percent. Currently no deletion of unused assets is done. The detection of unused assets seems to be impossible or at least very difficult with the current asset server architecture Opensim uses.

B) Creating New Groups

Groups have been introduced with Opensim revision 9215, but already today there exist nearly 600 groups in OSGrid. I have had a closer look at the existing groups and saw the following:

  • Most groups just have one member
  • There are even many groups with no members
  • Some groups have very similar names and it looks like that most of them have already been given up for newer groups with a slightly improved title

If the development continues like this, we soon will see many thousand groups, where it is difficult to identify which groups are trash and which are still used. For certain keywords group search already returns many groups with many similar names (search for “star” for example).

Possible Solution

To prevent an exaggerate use  of groups, that also reduces usability, policies and tools that support these policies should be used.

In Second Life people have to pay a fee to create a new group. Additionally the group owner has to recruit more group members within 3 days, otherwise the group gets deleted. And a group must maintain a membership of at least two members all the time in order to remain active.

In OSGrid I think we do not need a fee, but a policy for active groups similar like in Second Life. This means that empty groups and groups with less than 2 members would get deleted at latest 3 days after creation. This is the case for most groups that currently exist in OSGrid.

Additionally it might be useful to check when all group members have logged in the last time. If no group member has logged in during the last 90 days, it can be assumed, that all group members are not active OSGrid residents anymore.

A database script could check all existing groups regularly and delete groups that do not fulfill the previously mentioned conditions. For sure Opensim needs to behaves properly, if a group is encountered that was deleted and if such a group is used by land or objects shared by or deeded to that group.

In the case of shared objects and land, the group defined should simply be removed, making it unshared objects or land again. Deeded objects and land is more tricky, because in that case the group also needs to be deleted and the owner has to be reset to the previous owner before the object or land was deeded. All this should just happen if that group really was deleted. A disabled group module (maybe by accident) should not reset all group memberships.

Well, the last part was a bit technical, but it shows that implementing such a policy is something that needs to be well thought through.

Finally a little history story: As we all know, teleporting between regions also uses resources, especially processing power and bandwidth to transfer data. That is why during Second Life “stone age” they tried to introduce a fee for teleporting between regions. But understandably it did not take long, until users were demanding to abolish this teleporting fee.

I am sure that we will find a solution to prevent an exaggerate use ressources with policies and tools, without having to use money as incentive.


3 Responses to “The Costs of Free Resources”

  1. 1 BlueWall June 12, 2009 at 5:18 pm

    Nice thoughts!

    I suppose a lot of things need to be moderated with some programming, and others just need for those using the infrastructure to pitch in ( with whatever they can to promote the effort.

    Also, several business models are springing up around OSGrid. This is great for the entrepreneurs because of the ready-made infrastructure. Every one should work to be good neighbors and contribute back to the community in the proportions of the resorces being used.

    It is a fun thing to see unfold and develop!


  2. 2 coyled June 12, 2009 at 5:50 pm

    Some good thoughts here.

    I still think there’s a place for single-member groups. For example, I have a group which is simply a collection of role-titles-as-presence-indicators, so if I’m with a group of people but frequently switching to other work I can simply wear my “[ frequently AFK ]” group title while keeping my viewer up in the background. Enforcing a two member minimum would simply mean I’d create an alt to join the group, which would actually take up *more* resources. I can, though, see benefit in pruning abandoned groups.

  3. 3 rknop June 19, 2012 at 7:58 pm

    Garbage collection on grids like this is a hard probelm. I wasn’t involved with it back when I worked at Linden Lab, but there was somebody in the ops team who spent a decent amount of time making it work, and dealing with it. (As you can imagine, the problem of the sweling asset server is a huge issue for Second Life *despite* the $L10 upload fee, because there are so many users there.) The hard trick is making sure that it’s *really* not a referenced asset. They can be referenced in so many places; peolple’s inventory, in the contents of objects inside people’s inventory, on the contents of objects that are in the contenst of other objects…. Also, in regions, and in the contents of objects in regions. That gets even harder on OSGrid, where a region might be down for a few days but come back and expect its assets to still be there.

    Worth thinking about, because unused assets are cruft that build up using space and doing nobody any good, but it’s a hard problem.

    I can also think of various complications with duplicate assets. The simplest way to deal with it would be some offline process that goes through the asset server at whatever speed is necessary and figures out when two assets are identical. What to do next– best would be to implement some sort of symbolic linkage in your asset server implementation. Trying to rewrite asset IDs everywhere (inventory, regions, object contents) is probably prohibitive again because of the problem of offline regions. There are also going to be hardcoded asset UUIDs in scripts — I know I’ve done that.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Blog Stats

  • 22,398 hits


June 2009
« May   Sep »

%d bloggers like this: