Difference between revisions of "Project Motivation"

From Second Life Wiki
Jump to navigation Jump to search
 
(6 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{Template:AWG_NavBox}}
According to Zero Linden, the project was motivated by thoughts a year ago when Second Life was growing rapidly and Linden Lab was thinking about how to scale the grid.
According to Zero Linden, the project was motivated by thoughts a year ago when Second Life was growing rapidly and Linden Lab was thinking about how to scale the grid.


Line 5: Line 8:
== Scary numbers ==
== Scary numbers ==


If we assume that virtual worlds will be a significant part of the future, then the following numbers might not be so far off:
If we assume that virtual worlds will be a significant part of the future, then the following numbers along the 4 population-related dimensions of scalability might not be so far off:
 


Scalability of world extent:
#Scalability of world extent:
:* 60 million regions (probably more) (60 was mentioned [http://wiki.secondlife.com/wiki/User:Zero_Linden/Office_Hours/2007_Sep_18 here] by Zero Linden )
#:* 60 million regions (probably more) (60 was mentioned [http://wiki.secondlife.com/wiki/User:Zero_Linden/Office_Hours/2007_Sep_18 here] by Zero Linden )
Scalability of world population:
#Scalability of world population:
:* 2 billion users
#:* 2 billion users
Scalability of concurrent users:
#Scalability of concurrent users:
:* 50 - 100 million concurrency (on whatever device)
#:* 50 - 100 million concurrency (on whatever device)
Scalability for events (concurrent users in a single region):  
#Scalability for events (concurrent users in a single region):  
:* <strike>20 thousand</strike> per region ([[Talk:Project_Motivation|the previous population-based figures are currently being revised to include other factors]])
#:* <strike>20 thousand</strike> per region ([[Event_Scalability_VAG|the raw population-based figures are currently being revised to include other factors]])




These are the primary numbers that drive the need for the architecture.  In Zero's view, these numbers will almost certainly happen, no matter what form virtual worlds take.  These numbers will not be possible with the grid right now and additionally some more use cases need to be solved like connecting 3rd party hosted regions to the grid.
These are the primary numbers that drive the need for a scalable architecture.  In Zero's view, these numbers will almost certainly happen, no matter what form virtual worlds take.  These numbers will not be possible with the grid right now and additionally some more use cases need to be solved like connecting 3rd party hosted regions to the grid.


== Additional scaling factors ==
== Additional scaling factors ==
Line 25: Line 29:


:* The number of online users wishing to attend a single event increases with the population.  By simple proportionality:
:* The number of online users wishing to attend a single event increases with the population.  By simple proportionality:
:** from total population growth, 100 people today rises to ([[Talk:Project_Motivation|20,000 per event]]) (this is arithmetic, not opinion)
:** from total population growth, 100 people today rises to ([[Scalability_VAG|20,000 per event]]) (this is arithmetic, not opinion)
:** from concurrent population growth, 100 people today rises to ([[Talk:Project_Motivation|100,000 per event]]) (this is arithmetic, not opinion)
:** from concurrent population growth, 100 people today rises to ([[Scalability_VAG|100,000 per event]]) (this is arithmetic, not opinion)
:::* ''(These are end-limit figures derived by simple proportionality and should not be considered use cases.)''
:* Media-led scenarios ("Observer Mode") remove all client-side scaling barriers to allowing [[Use_Cases#SecondlifeTube|millions of event observers]].
:* Media-led scenarios ("Observer Mode") remove all client-side scaling barriers to allowing [[Use_Cases#SecondlifeTube|millions of event observers]].
:* Prim count expectations grow naturally.  Limiting them to current values is not tenable.
:* Prim count expectations grow naturally.  Limiting them to current values is not tenable.
Line 33: Line 38:


There also are numbers that are ''not'' expected to grow but still may have a significant impact on technical decisions regarding architecture, so they may be used to "anchor" anticipations and as a base for designing the rest of the architecture. These are the expected end-user capacities:
There also are numbers that are ''not'' expected to grow but still may have a significant impact on technical decisions regarding architecture, so they may be used to "anchor" anticipations and as a base for designing the rest of the architecture. These are the expected end-user capacities:
:* The maximum number of concurrent interactions with other people per player is not expected to increase. There is only so many people we can consider and be attentive to simultaneously, that making more people visible or heard makes no useful difference or even degrades experience.
:* The maximum number of concurrent interactions with other people per player is not expected to increase. There are only so many people we can consider and be attentive to simultaneously, that making more people visible or heard makes no useful difference or even degrades experience.
:* The maximum chatting output per player isn't growing anytime soon either.
:* The maximum chatting output per player isn't growing anytime soon either.
:* The maximum number of concurrent world interactions is pretty fixed: there is only so many prims we can modify, scripts we can interact with, objects we can manipulate simultaneously ; and we can only manage to maneuver so fast, that flying, driving and taking sharp turns faster is impractical.
:* The maximum number of concurrent world interactions is pretty fixed: there are only so many prims we can modify, scripts we can interact with, objects we can manipulate simultaneously ; and we can only manage to maneuver so fast, that flying, driving and taking sharp turns faster is impractical.
:* The update frequency required to simulate smooth movement or make a curved, arbitrary trajectory not appear disjointed or jerky is not going to increase over a few dozen Hz, and there is only so many moving objects we can be attentive to and in whose movement we can detect discrepancies.
:* The update frequency required to simulate smooth movement or make a curved, arbitrary trajectory not appear disjointed or jerky is not going to increase over a few dozen Hz, and there are only so many moving objects we can be attentive to and in whose movement we can detect discrepancies.
 


[[Category:Architecture Working Group]]
[[Category: AW Groupies]]

Latest revision as of 07:59, 20 November 2007


According to Zero Linden, the project was motivated by thoughts a year ago when Second Life was growing rapidly and Linden Lab was thinking about how to scale the grid.

There have been two timeframes set back then: The next few months and the next years. This architecture discussion is about the next years.

Scary numbers

If we assume that virtual worlds will be a significant part of the future, then the following numbers along the 4 population-related dimensions of scalability might not be so far off:


  1. Scalability of world extent:
    • 60 million regions (probably more) (60 was mentioned here by Zero Linden )
  2. Scalability of world population:
    • 2 billion users
  3. Scalability of concurrent users:
    • 50 - 100 million concurrency (on whatever device)
  4. Scalability for events (concurrent users in a single region):


These are the primary numbers that drive the need for a scalable architecture. In Zero's view, these numbers will almost certainly happen, no matter what form virtual worlds take. These numbers will not be possible with the grid right now and additionally some more use cases need to be solved like connecting 3rd party hosted regions to the grid.

Additional scaling factors

The above scary numbers stem from population pressure alone, but there are other areas of growth which compound the impact of those numbers still further. We might, or might not, take such numbers as guidelines that the architecture we devise should support. While we would like the architecture to support as many possible feature sets, and implementation strategies as possible, various numbers may or may not be achievable in any particular platform, but remain relevant anyway in a distributed platform that includes 3rd parties.


  • The number of online users wishing to attend a single event increases with the population. By simple proportionality:
    • from total population growth, 100 people today rises to (20,000 per event) (this is arithmetic, not opinion)
    • from concurrent population growth, 100 people today rises to (100,000 per event) (this is arithmetic, not opinion)
  • (These are end-limit figures derived by simple proportionality and should not be considered use cases.)
  • Media-led scenarios ("Observer Mode") remove all client-side scaling barriers to allowing millions of event observers.
  • Prim count expectations grow naturally. Limiting them to current values is not tenable.
  • Scripting load will grow roughly in proportion to prim numbers, as well as proportional to population through attachments.
  • Current growth is tiny compared to what will happen when TV-led events like CSI:NY/SL turn SL mainstream. Concurrent usage pressure will explode.

There also are numbers that are not expected to grow but still may have a significant impact on technical decisions regarding architecture, so they may be used to "anchor" anticipations and as a base for designing the rest of the architecture. These are the expected end-user capacities:

  • The maximum number of concurrent interactions with other people per player is not expected to increase. There are only so many people we can consider and be attentive to simultaneously, that making more people visible or heard makes no useful difference or even degrades experience.
  • The maximum chatting output per player isn't growing anytime soon either.
  • The maximum number of concurrent world interactions is pretty fixed: there are only so many prims we can modify, scripts we can interact with, objects we can manipulate simultaneously ; and we can only manage to maneuver so fast, that flying, driving and taking sharp turns faster is impractical.
  • The update frequency required to simulate smooth movement or make a curved, arbitrary trajectory not appear disjointed or jerky is not going to increase over a few dozen Hz, and there are only so many moving objects we can be attentive to and in whose movement we can detect discrepancies.