Difference between revisions of "Project Motivation"
(26 intermediate revisions by 8 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. | ||
There have been two timeframes set back then: The next few months and the next years. This architecture discussion is about the next years. | 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== | == 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: | |||
#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 ) | |||
#Scalability of world population: | |||
#:* 2 billion users | |||
#Scalability of concurrent users: | |||
#:* 50 - 100 million concurrency (on whatever device) | |||
#Scalability for events (concurrent users in a single region): | |||
#:* <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 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 ([[Scalability_VAG|20,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]]. | |||
:* 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 [http://www.nytimes.com/2007/10/04/arts/television/04CSI.html 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. | |||
[[Category: | [[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:
- Scalability of world extent:
- 60 million regions (probably more) (60 was mentioned here by Zero Linden )
- Scalability of world population:
- 2 billion users
- Scalability of concurrent users:
- 50 - 100 million concurrency (on whatever device)
- Scalability for events (concurrent users in a single region):
20 thousandper region (the raw population-based figures are currently being revised to include other factors)
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.
- The number of online users wishing to attend a single event increases with the population. By simple proportionality:
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.