OpenSimulator - User contributions [en]

Talk:Mono

2009-06-16T20:04:22Z

Morgaine:

* It sure is nice that Opensim is on Miguel's radar now. He might even see it as a nice heavy load test for Mono, which would be good for the Opensim community. [[User:Morgaine|Morgaine]] 23:18, 14 June 2009 (UTC)

* Miguel's preceding post in [http://pastebin.ca/1460278 pastebin] may be worth preserving as well, as it provides some insight into which memory size parameter is actually being measured and compared (namely RSS), and why:

I did some testing and downloaded opensim-0.6.4-release on both Windows and Linux.

I accessed a remote Windows system to do the build and run the simulator and I used my
local Linux machine with Hippo to test the memory usage. Sadly, Hippo kept crashing on me,
so I could not do a very extensive test.

A fresh virtual world with Mono/32-bit vs Vista/32 bit has Mono using 51 megs of RAM on
startup on Linux vs 55 megs of RAM on Vista (50 megs plus 5 megs of the OpenSim.vhost.exe)

If you run Mono/64 (which is what I initially did) the size of 64 bit pointeres has a strong
effect on Mono and increases the process size by 11 megs.

So at least starting up, Mono ends up with a 5 meg advantage. Perhaps the objects loaded
after that make a difference, but without the actual data that you used, it is hard to
find out exactly what it is.

I suspect though, that you might have compared the memory usage report from taskmanager on Windows
versus the VSIZE memory usage, this is a common mistake.

It is also worth pointing out that the VSIZE reported by ps aux is usually very large and is the
*wrong* metric to measure memory usage of OpenSim on Mono. The VSIZE reports the VM address space
used by Mono and it happens to include all sorts of things that are not actually using memory.

The RSS size is what you want to look at in both cases. There are a few hundred blogs that explain
why you should not use VSIZE when computing memory usage and why you should look at RSS, for instance:

http://virtualthreads.blogspot.com/2006/02/understanding-memory-usage-on-linux.html

[Miguel]
-----------
> First Post:
>
> Regarding the claims on Mono’s memory problems. I would like to know what exactly you claim
> that is larger in Mono than it is on .NET.
>
> I can understand a small percentage increase in memory consumption in Mono, but not a 3x or
> 4x increase in memory usage.
>
> Could you provide a sample “set” that I could use to test various versions of Mono across a
> number of operating systems and compare it to Windows?
> [Miguel de Icaza]

: Pastebin links reported to SL::AW Groupies by ssm2017 Binder, pasted here by [[User:Morgaine|Morgaine]] 16:11, 15 June 2009 (UTC).

Talk:Mono

2009-06-15T16:11:24Z

Morgaine:

* It sure is nice that Opensim is on Miguel's radar now. He might even see it as a nice heavy load test for Mono, which would be good for the Opensim community. [[User:Morgaine|Morgaine]] 23:18, 14 June 2009 (UTC)

* Miguel's preceding post in [http://pastebin.ca/1460278 pastebin] may be worth preserving as well, as it provides some insight into which memory size parameter is actually being measured and compared (namely RSS), and why:

I did some testing and downloaded opensim-0.6.4-release on both Windows and Linux.

I accessed a remote Windows system to do the build and run the simulator and I used my
local Linux machine with Hippo to test the memory usage. Sadly, Hippo kept crashing on me,
so I could not do a very extensive test.

A fresh virtual world with Mono/32-bit vs Vista/32 bit has Mono using 51 megs of RAM on
startup on Linux vs 55 megs of RAM on Vista (50 megs plus 5 megs of the OpenSim.vhost.exe)

If you run Mono/64 (which is what I initially did) the size of 64 bit pointeres has a strong
effect on Mono and increases the process size by 11 megs.

So at least starting up, Mono ends up with a 5 meg advantage. Perhaps the objects loaded
after that make a difference, but without the actual data that you used, it is hard to
find out exactly what it is.

I suspect though, that you might have compared the memory usage report from taskmanager on Windows
versus the VSIZE memory usage, this is a common mistake.

It is also worth pointing out that the VSIZE reported by ps aux is usually very large and is the
*wrong* metric to measure memory usage of OpenSim on Mono. The VSIZE reports the VM address space
used by Mono and it happens to include all sorts of things that are not actually using memory.

The RSS size is what you want to look at in both cases. There are a few hundred blogs that explain
why you should not use VSIZE when computing memory usage and why you should look at RSS, for instance:

http://virtualthreads.blogspot.com/2006/02/understanding-memory-usage-on-linux.html

[Miguel]
-----------
> First Post:
>
> Regarding the claims on Mono’s memory problems. I would like to know what exactly you claim
> that is larger in Mono than it is on .NET.
>
> I can understand a small percentage increase in memory consumption in Mono, but not a 3x or
> 4x increase in memory usage.
>
> Could you provide a sample “set” that I could use to test various versions of Mono across a
> number of operating systems and compare it to Windows?
> [Miguel de Icaza]

: Pastebin links reported to SL::AW Groupies by ssm2017 Binder. [[User:Morgaine|Morgaine]] 16:11, 15 June 2009 (UTC)

Talk:Mono

2009-06-14T23:18:09Z

Morgaine: New page: * It sure is nice that Opensim is on Miguel's radar now. He might even see it as a nice heavy load test for Mono, which would be good for the Opensim community. ~~~~

Talk:Virtual World Model

2009-06-10T12:40:11Z

Morgaine: /* The meaning of safety */

== Simulator Trust Domain definition==

It currently states: "One or more simulators that completely trust each other, operated by one single authority." Does it really need to be operated by a single authority? Could I not say I fully and completely trust sims operated by John Smith and/or he fully and completely trusts sims operated by me? --[[User:DaveCoyle|DaveCoyle]] 11:40, 20 April 2009 (UTC)

Yes, you are right. I changed the definition. Basically, I think what you're getting at is that each simulator, or each seed trust domain, can extend trust to other trust domains, and this is not transitive: you trust W, but you don't necessarily trust the sims that W trusts. Needs more thinking. --[[User:Diva|Diva]] 07:50, 20 April 2009 (PST)

== OSGrid and trust domains ==

There seems to be continued disagreement regarding OSGrid and trust domains, so let's discuss it here. Charles, you removed the sentence "For example, OSGrid has, by nature and intent, several hundred simulator trust domains." I disagree with its removal, and based on the -dev list thread everyone doesn't seem to be on the same page on this point. So let's talk it out.

I am a region operator on OSGrid. I fully trust sims operated by myself. I fully trust sims operated by a handful of others who I believe will not do anything nefarious to me, my communications, my inventory, etc. I neither trust nor don't trust sims operated by most others, as I neither know them nor have reason to believe they'll do bad things. I do not trust some regions (e.g. DNCH).

Sounds like multiple trust domains to me. --[[User:DaveCoyle|DaveCoyle]] 11:31, 20 April 2009 (UTC)

I would really like to hear more from the OSGrid community about wishes for the future, 1 year ahead. The only reason why I am making that subtle distinction between Grid and Trust Domain is OSGrid. I mention LL grid, but, really, I have no idea what their plans are, that's just speculation. OSGrid, however, exists. Unifying the concept of Grid with that of trust domain will make the model a whole lot simpler and easier to implement, so if that is what's on the map for OSGrid, it would be good to know. --[[User:Diva|Diva]] 09:45, 20 April 2009 (PST)

== The meaning of ''safety'' ==

There seems to be an important reference left undefined in this useful page. Various paragraphs refer to "safely exchange messages", "unsafe teleports", and "safe simulator connectivity", but nowhere is the meaning of "safety" explained or illustrated. I can imagine a variety of possible considerations that can give rise to a verdict of "safe" versus "unsafe", such as the desire to safeguard assets, or protect system integrity, or prevent abuse, or simply to disallow unauthorized access, but which of these were intended here? Perhaps all of them? Or does "safety" have a specific meaning in this context?

I think it's worth spending a little time defining what is meant here, because the foundational idea of "trust domain" is currently being described in terms of a fuzzy concept that obscures rather than explains. Yes, we all love the motherhood and apple pie implied by "safe", but what does it actually mean in this specific context, for the purposes of model definition? :-) [[User:Morgaine|Morgaine]] 12:37, 10 June 2009 (UTC)

Talk:Virtual World Model

2009-06-10T12:37:56Z

Morgaine: The term "safe" lacks definition

== Simulator Trust Domain definition==

It currently states: "One or more simulators that completely trust each other, operated by one single authority." Does it really need to be operated by a single authority? Could I not say I fully and completely trust sims operated by John Smith and/or he fully and completely trusts sims operated by me? --[[User:DaveCoyle|DaveCoyle]] 11:40, 20 April 2009 (UTC)

Yes, you are right. I changed the definition. Basically, I think what you're getting at is that each simulator, or each seed trust domain, can extend trust to other trust domains, and this is not transitive: you trust W, but you don't necessarily trust the sims that W trusts. Needs more thinking. --[[User:Diva|Diva]] 07:50, 20 April 2009 (PST)

== OSGrid and trust domains ==

There seems to be continued disagreement regarding OSGrid and trust domains, so let's discuss it here. Charles, you removed the sentence "For example, OSGrid has, by nature and intent, several hundred simulator trust domains." I disagree with its removal, and based on the -dev list thread everyone doesn't seem to be on the same page on this point. So let's talk it out.

I am a region operator on OSGrid. I fully trust sims operated by myself. I fully trust sims operated by a handful of others who I believe will not do anything nefarious to me, my communications, my inventory, etc. I neither trust nor don't trust sims operated by most others, as I neither know them nor have reason to believe they'll do bad things. I do not trust some regions (e.g. DNCH).

Sounds like multiple trust domains to me. --[[User:DaveCoyle|DaveCoyle]] 11:31, 20 April 2009 (UTC)

I would really like to hear more from the OSGrid community about wishes for the future, 1 year ahead. The only reason why I am making that subtle distinction between Grid and Trust Domain is OSGrid. I mention LL grid, but, really, I have no idea what their plans are, that's just speculation. OSGrid, however, exists. Unifying the concept of Grid with that of trust domain will make the model a whole lot simpler and easier to implement, so if that is what's on the map for OSGrid, it would be good to know. --[[User:Diva|Diva]] 09:45, 20 April 2009 (PST)

== The meaning of ''safety'' ==

There seems to be an important reference left undefined in this useful page. Various paragraphs refer to "safely exchange messages", "unsafe teleports", and "safe simulator connectivity", but nowhere is the meaning of "safety" explained or illustrated. I can imagine a variety of possible considerations that can give rise to a verdict of "safe" versus "unsafe", such as the desire to safeguard assets, or protect system integrity, or prevent abuse, or simply to disallow unauthorized access, but which of these were intended here? Perhaps all of them? Or does "safety" have a specific meaning in this context?

I think it's worth spending a little time defining what is meant here, because the foundational idea of "trust domain" is currently being described in terms of a fuzzy concept that obscures rather than explains. Yes, we all love the motherhood and apple pie implied by "safe", but what does it actually mean? :-) [[User:Morgaine|Morgaine]] 12:37, 10 June 2009 (UTC)

Virtual World Model

2009-06-09T21:56:59Z

Morgaine: Spelling corrections

__NOTOC__
{{Template:Quicklinks}}
<br />

What follows are working definitions for the model of virtual worlds supported by OpenSim. They are intended to clarify terminology, and to sharpen the requirements with respect to security of users' data and world assets. Please use the [[Talk:Virtual_World_Model|Discussion]] tab to comment on these definitions -- they are live and subject to improvements.

'''Simulator Trust Domain''': One or more simulators that completely trust each other, operated by one single
authority. Trust means that these simulators can safely exchange messages and share data with each other.
Specifically, trusting simulators can engage in exchanges that enable useful features, such as server-side
teleports, that are unsafe when done between non-trusting simulators. Trust domains can be extended to include
simulators in other trust domains, but in these extensions trust is neither commutative nor transitive.
[[Talk:Virtual_World_Model|discuss here]]

'''Resource Services''': A set of zero or more services serving resources for simulators. Resources include:
assets, user accounts, and assorted services like map, lookup, social networking, forums, etc.

'''Grid''': One or more simulators that share resources via resource services. At the very minimum, the
simulators in a grid share assets, but many more services are possible (see above). A Grid includes one or
more simulator trust domains. Normally one would expect one grid to be one single trust domain, but that
doesn't necessarily need to happen. Given that a Grid may include more than one simulator
trust domain, there can be untrusted connections within the same grid. In deploying security schemes, this
needs to be taken into account. (OSGrid and trust domains...[[Talk:Virtual_World_Model|discuss here]]).

'''Hypergrid''': The interconnection of grids. Hypergrid simulator connections are necessarily untrusted, so
security schemes need to take that into account. Besides safe simulator connectivity between grids, the
Hypergrid addresses the interoperability of resource services -- that is, the ability for: user accounts in
one user service being recognized in other grids; assets in one asset service being transferred to other
grids; social networking services being bridged, etc. The Hypergrid architecture enables, but does not impose,
the emergence of independent Hypergrid-wide resource services such as User Services, Asset Storage, Social
Networking, Search, etc. that serve several grids and are not coupled with any one grid in particular.

'''Walled-Garden Grid''': A grid that only handles resources directly managed by its own resource services. It
does not recognize or allow users and assets from other grids, and it does not allow the export of its own
users and assets. It may, however, import/export assets in bulk via backend storage systems (e.g. OARs).

Additional notes:

* Tentatively, I'm unifying the concept of Grid with the concept of Virtual World.

* A "Standalone", which should be read as "Standalone Grid" (term credit to Michael Cortez), is a grid-in-a-box. It's one process that single-handily performs simulation and resource management. Just like any other grid, a Standalone grid may be hypergrided or may operate as a walled garden.

* Simulator trust domains have ultimate freedom to implement any feature they want among themselves, including transferring user agents (user permitting), sharing private data, etc.

* Grids may exist without any services but asset services. [Note: could there be a grid without assets?!]

* Hypergrided Grids may treat all users equally or may treat their own users in special ways.

* Grids may provide visitors with additional resources that are only available while the users visit that grid, and become unavailable once the visitor goes elsewhere (aka grid-specific inventory).

More notes (Melanie's email, edited by Diva):

Users should be in control of their own inventory and its associated assets, independent of a single grid. This means:

* users can select where their data is stored. This may be an ISP, a web hoster, a grid or their own PC (bandwidth permitting). No simulator has authority over that storage.

* Regions hold COPIES of the assets needed to render whatever is currently in world. Normally, this will be "by value", e.g. the sim will have a full and valid copy of the data and be able to supply everything needed to render its content independent of any outside servers.

* Grids are one or more trust domains, they are groups of regions sharing asset and user services. They access the same servers for their data and anything within one region can be moved to any other region without the need to copy assets. Regions within a trust domain are able to destroy storage needed by other regions to render data, but cannot access user inventories unless authorized, and with very limited scope. Typically, but not mandatory, all sims in one gridwill be owned and operated by a single individual/organization.

* User services authenticate users for access to a trust domain. They may require username/password, X.509 certificates, oAuth, openID or any other form of authentication, or none. They may decree that, if you don't authenticate, your access may be limited to observation only, or in any other way they, as the trust domain controller, see fit.

* Sim asset services are the storage at the heart of a grid, sims in a grid share these asset services. That is distinct from user asset services, which are out of scope for regions.

* Optionally, user asset services may pass an object to a region "by reference". This assumes a basic level of trust with the region, which is advised to not keep a copy, but request the current data from the user asset service each time it is needed. This required continuous authorization for that item, which will be limited to specific sims, Therefore, such items can't leave the sim, they cannot be given or sold, but only be taken by the owner. This is useful for allowing the update of scripts in-place, e.g. for applications like sloodle, which may want to update all inworld terminals all at once. It it a marked departure from the Linden way of doing things.