Difference between revisions of "Talk:Project Motivation"

From Second Life Wiki
Jump to navigation Jump to search
 
(80 intermediate revisions by 7 users not shown)
Line 1: Line 1:
== Scaling for events ==
{{architecture_header}}


I would like to add '''more scary numbers''' to the main namespace here.
== Notice ==
This page has grown too large.  Please move the discussion of events and event sizes to a new set of pages. [[User:Zero Linden|Zero Linden]] 10:42, 16 October 2007 (PDT)


* If N people are interested in an event today, and the population grows tomorrow by a factor of M, then tomorrow N*M people will be interested in that event, assuming unchanging population demographics.
:* Done. All event scalability discussion now in [[Talk:Event_Scalability_VAG]]. --[[User:Morgaine Dinova|Morgaine Dinova]] 03:17, 19 October 2007 (PDT)
:* Scalability for events seemed to have vanished from the 4-point list of dimensions of scalability earlier.  I can't see any discussion here related to that, so I reinstated the two lost lines since the need to scale for events has already endured many weeks of scrutiny and agreement from numerous wiki participants. --[[User:Morgaine Dinova|Morgaine Dinova]] 13:11, 17 October 2007 (PDT)
:* The paragraph on discussion control has been moved to [[Talk:Event_Scalability_VAG#Discussion_control]]. --[[User:Morgaine Dinova|Morgaine Dinova]] 03:24, 19 October 2007 (PDT)


* Every live music event by the top few SL musicians maxes out their event sim:  let's assume that this means 100 people, although the demand is undoubtedly higher already but not satisfied.  SL currently has just under 10m registered residents.  If the scary number for total population size is 2 billion, then the scary number for event interest is 100*2000/10 = 20,000 to an event region, given unchanging demographics.


* Of course, worldwide we do not have an unchanging demographic, but no matter by how much you want to reduce this figure as a result of this, the answer is still collosal.  And bear in mind that there is much uniformity in eastern populations, just as there is in the west, so event interest within each cultural domain will be huge. And of course many events are cross-cultural.
== First paragraph ==
Shouldn't the first paragraph explain for which project this is the motivation off? Or there be some link back at the top, that says part off..


* Which brings me to the issue that nobody seems to want to tackle:  the new architecture needs scalability for events.
I just came to this page accidently, when searching for something else. I know what it is about, but for someone who doesn't, it isn't clear. Also the title makes you think this is a Project named Motivation and not the motivation for a project.
The same goes for other pages, like the use cases. [[User:Frans Charming|Frans Charming]] 05:23, 7 October 2007 (PDT)


* While I recognize fully that there are monumental hurdles in the way of achieving this, it is just an engineering problem with a number of known partial solutions and amenable to tradeoffs.  Worse, not addressing it will leave us exactly where we are today, with zero scalability for events.  And, very unhappily, SL will become the virtual world where almost everybody is barred from their favorite event.  19,900 people out of every 20,000 will have to stay at home.  That's not the future system we want to build, in my view.
:* There could be some confusion, yes.  I'm surprised that there isn't a link to the parent in the title of each of these main namespace pages that are children of [[Architecture_Working_Group]].  However, note that this is not possible in the wiki generally, since many pages can point to the same child as a top-level entry.  In this particular case it would probably work.  As for changing all the children's names to make the AWG: namespace explicit ... that would break an immense number of links! Unless there is a tool to automatically change all references suitably, it's best avoided.  And it wouldn't fix the offsite references and bookmarks that already exist anyway. :-) There are probably other solutions though. Anyone? --[[User:Morgaine Dinova|Morgaine Dinova]] 08:55, 8 October 2007 (PDT)




* Please add at least 10,000 per '''region''' to the scary numbers, to focus the mind. --[[User:Morgaine Dinova|Morgaine Dinova]] 21:07, 24 September 2007 (PDT)
== Wolves at the gates ==
* Excellent addition, Strife, and central to ''Project Motivation''!  I guess Sony HOME and Google MyWorld will be candidates for this section too. --[[User:Morgaine Dinova|Morgaine Dinova]] 03:59, 2 October 2007 (PDT)


* I mentioned this at Zero's Office Hours today, but no traffic yet, so added it myself. --[[User:Morgaine Dinova|Morgaine Dinova]] 17:42, 25 September 2007 (PDT)
* A shiver ran through me Strife, when I realized that you'd added the subtitle "'''Competitors'''" to this section ... because that implies that there are wolves at the gate other than mere competitors.  And that made me focus on reality:  the worst wolf isn't actually a wolf (which merely competes to survive) at all, but a 10-ton vicious predator ... the coercive T-Rex that is the politician surrounded by his retinue of lobbyists, litigants, Luddites, puritans, and vested interests.  The real enemy isn't competition, as the playing field is level there.  It's much worse. --[[User:Morgaine Dinova|Morgaine Dinova]] 06:38, 4 October 2007 (PDT)


=== Zha's comments on events ===
* Rob, good comment in the changelog about Strife's section title and the link to a commercial site. :-)  Perhaps Strife could abstract the key elements of that system for us instead.  After all, AWG's focus is not only on scalability but also on interoperability.  The existence of commercial offerings like that one certainly needs to be borne in mind, since they will be providing infrastructure for other virtual worlds with which in time we will need to interoperate.  And any claimed figures related to scalability are of particular interest! :-) --[[User:Morgaine Dinova|Morgaine Dinova]] 17:37, 10 October 2007 (PDT)


The event discussion came up at the AWG kickoff, and comes up from time to time in Zero's office hours. At the heart of the event discussion is the desire to host very large events inside the SecondLife environment. This raises the question, what will 200, 500, 1000, 10,000, 20,000 users be able to do in a single contiguous portion of second life space. Assuming for a moment, we could manage the simulator side space, what would a client see? At 100 avatars in a sim, my current screen is pretty much solid avatars with a cloud of tags floating over them, all in constant motion. (Granted we're also all in concrete, in the current sims, but we'll assume that can be fixed.)
:: Actually, my comment was about [http://en.wikipedia.org/wiki/Business-to-consumer consumer-facing] site.  Links to commercial sites aren't verboten, but they need to have appropriate context.  If one of the other (commercial) virtual world companies posts an interesting architecture document on their website, it's perfectly reasonable to cite it.  However, if the page being linked to is just a site geared toward attracting signups for a virtual world service (consumer-facing), that's very rarely appropriate. -- [[User:Rob Linden|Rob Linden]] 12:54, 17 October 2007 (PDT)
 
Somewhere north of 500 avatars, I can't see how I could render more than a fraction of them, nor could I interact with more than those I could see right near me. So, and I am quite serious about this question, what are we attempting to achieve. If the answer is "let us all share the stream" I'll point out that the streams are orthogonal to SecondLife. If it is interactivity, in the current style of SecondLife, I'd like to see a use case for how we could produce an interesting user experience with the number of avatars I listed above in ear shot. How fast will the chat window scroll? How fast will people's "nearby" windows update? How many avatars do we expect our scripted objects to be able to sense, and how will we even see most of the avatars
 
Beyond the user experience, we also should look at some hard technical questions. How many Kbits per seconds of updates are needed to support each of these size points? Can we get that from current networking hardware. Look at these questoins, Simulator to Client, Simulator to adjacent Simulators, and Simulator to utilities, and agent domains.
 
This isn't a simple "let's quash the idea" post, far from it. But If we are asserting this as a desire, lets actually produce some use cases which describe what we are trying to enable.  "20,000 in an event" isn't a requirement I can design against. Give use some use cases which describe the actual user experiences that we wish to enable. Look hard at questions like "How will chat look, how will visibility work, how would scripting behave." Capture these in use cases.
 
I will suggest, for example, that some use case can be solved by better inter-region behavior. Others, would only be solved by attempting to limit the interactions between avatars in significant ways. Serious discussion, backed by used cases, would be invaluable here.
 
- [[User:Zha Ewry]] 9/25/2007
 
=== Basic questions: why, what, how? ===
Hooray, comments at last. :-)
 
* Good, let me start off with a serious but not particularly helpful response in the form of a rebuffal:  we have 20k-100k+ people events in RL taking place every weekend in thousands of places worldwide, and it seems to work just fine.  So, we know that it can work in the physical world, and that it is a very human thing to do.  And the 3D virtual world is to a very large extent a recreation of physical space, but with added capabilities, so this is both desireable for people and natural in a virtual recreation of physical space.  The only problem is that it's hard to do, and it's not on a well beaten trail.
 
* Seen in that light, the question I want to entertain is "How can we achieve this?".  I don't feel the need to defend the desire for it, and anyone who follows the SL live music scene and is hitting their head daily against lack of scalability for events would I'm sure express that same feeling just as forcefully.  It's a bad state of affairs, and it needs fixing, particularly in the context of an ambitious project that addresses all other areas of scalability.  Let's just do it.  (Bit by bit of course.)
 
* Now to answer your questions specifically:
:* '''What will 200-20,000 users be able to do in a single contiguous portion of SL space?'''
:: Exactly what they do in RL.  Sit in seats in stadia.  Gather in crowds at rallies and concerts.  Roam in the park in smaller groups.  Join hands in a 2000-person line dance.  Sky-dive in 500-person snowflake patterns.  I don't know, anything.  That's up to them.  I really don't think we need use cases for this.  Just open the curtains or turn on the telly for use cases.  :-)  The first candidate is among us right now though:  SL live music needs 500-person capability today.
 
:* '''What would a client see?  ... Somewhere north of 500 avatars, I can't see how I could render more than a fraction of them.'''
:: First of all, let's not be hung up on the current client.  This will change drastically, and in any case there will be umpteen different clients, each suitable for a different purpose.  (It's one of the reasons why I'm trying to partition the client into graphics + front-end.)  No doubt we will be creating crowd-capable clients as well ... if region scalability allows a crowd to gather in the first place.
 
:: So, the client would see exactly what a person sees in a crowd in RL, but much more flexibly.  Numerous options for this have been explored in the SL forums, from simple reduced detail rendering, rapid-falloff CLOD, to performance-driven culling, and selective viewing.  Unlike in RL, you could select to render only those in your group, or only furries, or only pretty girls (OK, that's not much of an object reduction :P).  Many people have suggested that ghost outlines would suit them just fine, and even more want a GuildWars-type "'''Observer Mode'''" in which their avatars are not rendered at all for others to see, which would reduce the problem substantially if it proved popular.  So, there are lots of options.
 
:* '''nor could I interact with more than those I could see right near me.'''
:: And nor would you in RL, unless you're shouting, so this works pretty accurately.  It would however be much easier to interact with your friends here since you could make everyone else disappear.  Fortunately sound volume already falls off with distance in SL so that part of interaction is covered.  Reading vicinity text scroll is clearly not viable in crowds, so this would need to be filtered in some manner chosen by each person, such as by group membership or friends only, or by distance just like sound.  None of this is hard.
 
:* '''How many avatars do we expect our scripted objects to be able to sense?'''
:: This is actually a much more interesting question than the others.  Even with the huge improvement that Mono will bring about, it's going to need more than faster LSL processing to do a good job in this area.  It's going to require substantial improvements in sensing functions, and probably some language assist in the form of proper O(1) indexible arrays (at long last).  But then, land owners have been crying out for better sensing functions for ages.  It's time for it.
 
I think I've answered your general questions in debating style Zha (the questions were in that style too), but the detail has to be tackled far more precisely of course, and I'm ready for that.  At this stage though, I'm looking merely for acceptance of the basic premise, particularly from Zero.  I don't want to be on the defensive, as if this single area of scalability were somehow taboo.  And that's how it has seemed over these past 3-4 years. :-) --[[User:Morgaine Dinova|Morgaine Dinova]] 19:43, 25 September 2007 (PDT)
 
 
* It's a new day and now I'm going to write up some proper use cases.  This will need a separate namespace page, or a tree of them. --[[User:Morgaine Dinova|Morgaine Dinova]]
 
== Scary numbers ==
Each of the areas of scalability in [[Project_Motivation]] actually needs its own assessment.  It's not really as simple as just deciding on an arbitrary fraction of world population.  Scalability of a region derives from size of user base, but what about the other 3 numbers?
 
Also, each area introduces its own particular problems and contains its own set of possible solutions, which should be listed.  One of these should then link to the chosen implementation, with appropriate engineering reasoning given.  All of this seems to be missing at the moment, and we're just presented with a ''fait acompli'', which is not engineering.  This needs some improvement. --[[User:Morgaine Dinova|Morgaine Dinova]] 03:44, 26 September 2007 (PDT)

Latest revision as of 02:24, 19 October 2007

Architecture Working Group main Project Motivation Proposed Architecture Use Cases In World Chatlogs

Notice

This page has grown too large. Please move the discussion of events and event sizes to a new set of pages. Zero Linden 10:42, 16 October 2007 (PDT)

  • Done. All event scalability discussion now in Talk:Event_Scalability_VAG. --Morgaine Dinova 03:17, 19 October 2007 (PDT)
  • Scalability for events seemed to have vanished from the 4-point list of dimensions of scalability earlier. I can't see any discussion here related to that, so I reinstated the two lost lines since the need to scale for events has already endured many weeks of scrutiny and agreement from numerous wiki participants. --Morgaine Dinova 13:11, 17 October 2007 (PDT)
  • The paragraph on discussion control has been moved to Talk:Event_Scalability_VAG#Discussion_control. --Morgaine Dinova 03:24, 19 October 2007 (PDT)


First paragraph

Shouldn't the first paragraph explain for which project this is the motivation off? Or there be some link back at the top, that says part off..

I just came to this page accidently, when searching for something else. I know what it is about, but for someone who doesn't, it isn't clear. Also the title makes you think this is a Project named Motivation and not the motivation for a project. The same goes for other pages, like the use cases. Frans Charming 05:23, 7 October 2007 (PDT)

  • There could be some confusion, yes. I'm surprised that there isn't a link to the parent in the title of each of these main namespace pages that are children of Architecture_Working_Group. However, note that this is not possible in the wiki generally, since many pages can point to the same child as a top-level entry. In this particular case it would probably work. As for changing all the children's names to make the AWG: namespace explicit ... that would break an immense number of links! Unless there is a tool to automatically change all references suitably, it's best avoided. And it wouldn't fix the offsite references and bookmarks that already exist anyway. :-) There are probably other solutions though. Anyone? --Morgaine Dinova 08:55, 8 October 2007 (PDT)


Wolves at the gates

  • Excellent addition, Strife, and central to Project Motivation! I guess Sony HOME and Google MyWorld will be candidates for this section too. --Morgaine Dinova 03:59, 2 October 2007 (PDT)
  • A shiver ran through me Strife, when I realized that you'd added the subtitle "Competitors" to this section ... because that implies that there are wolves at the gate other than mere competitors. And that made me focus on reality: the worst wolf isn't actually a wolf (which merely competes to survive) at all, but a 10-ton vicious predator ... the coercive T-Rex that is the politician surrounded by his retinue of lobbyists, litigants, Luddites, puritans, and vested interests. The real enemy isn't competition, as the playing field is level there. It's much worse. --Morgaine Dinova 06:38, 4 October 2007 (PDT)
  • Rob, good comment in the changelog about Strife's section title and the link to a commercial site. :-) Perhaps Strife could abstract the key elements of that system for us instead. After all, AWG's focus is not only on scalability but also on interoperability. The existence of commercial offerings like that one certainly needs to be borne in mind, since they will be providing infrastructure for other virtual worlds with which in time we will need to interoperate. And any claimed figures related to scalability are of particular interest! :-) --Morgaine Dinova 17:37, 10 October 2007 (PDT)
Actually, my comment was about consumer-facing site. Links to commercial sites aren't verboten, but they need to have appropriate context. If one of the other (commercial) virtual world companies posts an interesting architecture document on their website, it's perfectly reasonable to cite it. However, if the page being linked to is just a site geared toward attracting signups for a virtual world service (consumer-facing), that's very rarely appropriate. -- Rob Linden 12:54, 17 October 2007 (PDT)
Retrieved from "https://wiki.secondlife.com/w/index.php?title=Talk:Project_Motivation&oldid=36912"