<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: The Imaginary 45K Wall</title>
	<atom:link href="http://www.adamfrisby.com/blog/2009/11/the-imaginary-45k-wall/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.adamfrisby.com/blog/2009/11/the-imaginary-45k-wall/</link>
	<description>ZOMGWTFHAI</description>
	<lastBuildDate>Tue, 02 Feb 2010 23:36:21 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Intari Marjeta</title>
		<link>http://www.adamfrisby.com/blog/2009/11/the-imaginary-45k-wall/comment-page-1/#comment-8568</link>
		<dc:creator>Intari Marjeta</dc:creator>
		<pubDate>Fri, 13 Nov 2009 05:10:29 +0000</pubDate>
		<guid isPermaLink="false">http://www.adamfrisby.com/blog/?p=487#comment-8568</guid>
		<description>What is _more_ of problem with small-more-specific-regions is that border crossings between regions even if they on same host is currently laggy.(Megaregions could solve this but ...I&#039;m under influence that megaregion supports almost same number of concurrent users as normal one)...

of course there is TPs but TPs introduce artificiaul borders....</description>
		<content:encoded><![CDATA[<p>What is _more_ of problem with small-more-specific-regions is that border crossings between regions even if they on same host is currently laggy.(Megaregions could solve this but &#8230;I&#8217;m under influence that megaregion supports almost same number of concurrent users as normal one)&#8230;</p>
<p>of course there is TPs but TPs introduce artificiaul borders&#8230;.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rob Knop</title>
		<link>http://www.adamfrisby.com/blog/2009/11/the-imaginary-45k-wall/comment-page-1/#comment-8559</link>
		<dc:creator>Rob Knop</dc:creator>
		<pubDate>Wed, 04 Nov 2009 17:33:11 +0000</pubDate>
		<guid isPermaLink="false">http://www.adamfrisby.com/blog/?p=487#comment-8559</guid>
		<description>I don&#039;t know if they&#039;ve done any experiments at Linden, but when I was there there was a recognition among the engineers at least that prims were a very poor standin for resource limits; it&#039;s just easy to implement, and it&#039;s all they&#039;ve got right now.  15,000 prims &quot;sort of worked&quot; most of the time, but it was of course an arbitrary limit.  The real limits are harder to quantify, and as Adam says depend on avatars in region, what the region is doing, etc.  Memory was usually a bigger deal than processor time, and from the user&#039;s point of view, bandwidth is a huge issue.  (The fact that we&#039;re all used to popping into a region and waiting at least seconds while everything rezzes, and then turns from grey to textured, indicates that bandwidth is limiting our experience.)  The number of prims does matter-- they do take memory, and they take bandwidth to send down to each and every viewer-- but the number of avatars in region and what they&#039;re doing matters more.</description>
		<content:encoded><![CDATA[<p>I don&#8217;t know if they&#8217;ve done any experiments at Linden, but when I was there there was a recognition among the engineers at least that prims were a very poor standin for resource limits; it&#8217;s just easy to implement, and it&#8217;s all they&#8217;ve got right now.  15,000 prims &#8220;sort of worked&#8221; most of the time, but it was of course an arbitrary limit.  The real limits are harder to quantify, and as Adam says depend on avatars in region, what the region is doing, etc.  Memory was usually a bigger deal than processor time, and from the user&#8217;s point of view, bandwidth is a huge issue.  (The fact that we&#8217;re all used to popping into a region and waiting at least seconds while everything rezzes, and then turns from grey to textured, indicates that bandwidth is limiting our experience.)  The number of prims does matter&#8211; they do take memory, and they take bandwidth to send down to each and every viewer&#8211; but the number of avatars in region and what they&#8217;re doing matters more.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ener Hax</title>
		<link>http://www.adamfrisby.com/blog/2009/11/the-imaginary-45k-wall/comment-page-1/#comment-8556</link>
		<dc:creator>Ener Hax</dc:creator>
		<pubDate>Tue, 03 Nov 2009 13:48:25 +0000</pubDate>
		<guid isPermaLink="false">http://www.adamfrisby.com/blog/?p=487#comment-8556</guid>
		<description>an outstanding explanation and one that makes me excited about venturing into OpenSim more.  with a big commitment to SL (12 sims), i tend to hesitate putting ener-gies elsewhere

but by staying &quot;bound&quot; to sl it prevents me from moving forward

thank you for the excellent explanation and for sparking my curiosity</description>
		<content:encoded><![CDATA[<p>an outstanding explanation and one that makes me excited about venturing into OpenSim more.  with a big commitment to SL (12 sims), i tend to hesitate putting ener-gies elsewhere</p>
<p>but by staying &#8220;bound&#8221; to sl it prevents me from moving forward</p>
<p>thank you for the excellent explanation and for sparking my curiosity</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: rightasrain</title>
		<link>http://www.adamfrisby.com/blog/2009/11/the-imaginary-45k-wall/comment-page-1/#comment-8555</link>
		<dc:creator>rightasrain</dc:creator>
		<pubDate>Tue, 03 Nov 2009 10:48:51 +0000</pubDate>
		<guid isPermaLink="false">http://www.adamfrisby.com/blog/?p=487#comment-8555</guid>
		<description>interesting post ty. We think we can get 400 concurrent on a server, mainly by making regions smaller and more specific experiences. While a region may only hold 10-20 concurrent, moving people across regions (notwithstanding tp crashes) is our best idea on maximizing content/user flow. Personally I think overloading a region with prims makes no sense atm with OpenSim as the download will take too long.</description>
		<content:encoded><![CDATA[<p>interesting post ty. We think we can get 400 concurrent on a server, mainly by making regions smaller and more specific experiences. While a region may only hold 10-20 concurrent, moving people across regions (notwithstanding tp crashes) is our best idea on maximizing content/user flow. Personally I think overloading a region with prims makes no sense atm with OpenSim as the download will take too long.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mo Hax</title>
		<link>http://www.adamfrisby.com/blog/2009/11/the-imaginary-45k-wall/comment-page-1/#comment-8554</link>
		<dc:creator>Mo Hax</dc:creator>
		<pubDate>Tue, 03 Nov 2009 01:34:08 +0000</pubDate>
		<guid isPermaLink="false">http://www.adamfrisby.com/blog/?p=487#comment-8554</guid>
		<description>Very informative post. Thanks very much for making it Adam.</description>
		<content:encoded><![CDATA[<p>Very informative post. Thanks very much for making it Adam.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: dahlia</title>
		<link>http://www.adamfrisby.com/blog/2009/11/the-imaginary-45k-wall/comment-page-1/#comment-8553</link>
		<dc:creator>dahlia</dc:creator>
		<pubDate>Tue, 03 Nov 2009 01:00:01 +0000</pubDate>
		<guid isPermaLink="false">http://www.adamfrisby.com/blog/?p=487#comment-8553</guid>
		<description>OpenSim users should bear in mind that prims used as avatar attachments are also managed by the simulator, and potentially a single avatar could wear attachments totaling several thousand prims. These prims will also consume sim resources and network bandwidth.</description>
		<content:encoded><![CDATA[<p>OpenSim users should bear in mind that prims used as avatar attachments are also managed by the simulator, and potentially a single avatar could wear attachments totaling several thousand prims. These prims will also consume sim resources and network bandwidth.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Wayfinder Wishbringer</title>
		<link>http://www.adamfrisby.com/blog/2009/11/the-imaginary-45k-wall/comment-page-1/#comment-8551</link>
		<dc:creator>Wayfinder Wishbringer</dc:creator>
		<pubDate>Mon, 02 Nov 2009 19:28:37 +0000</pubDate>
		<guid isPermaLink="false">http://www.adamfrisby.com/blog/?p=487#comment-8551</guid>
		<description>Oh a quick follow-up comment:  one of the great things about OpenSim is that prim count becomes far less critical due to the allowance of mega-prims.  When one can build a large floor with one prim instead of 25, and castle walls with one prim instead of a dozen... prim count becomes even less important an issue.  

When we opened our OpenSim, I built an entire castle using only 150 prims.  The same castle would have cost me nearly 1000 prims in Second Life.  The availability of megaprims has revealed a lot about just how limiting and arbitrary Linden Lab has been in their forcing users in to their company-defined mold.  Now that we are free of thos constraints-- and free of the Linden Lab stranglehold-- the potential of virtual worlds becomes apparent.  We come to realize that rather than promoting VR, LL has been holding it back from what it could hve been all this time.  Limited prim count, limited prim size and excessive prices have done more to strangle VR expansion than promote it.  

Fortunately, with the advent of OpenSim that will soon no longer be the case.  There will come a time when users will be able to relax when it comes to prim count and concentrate on issues of sim operation and maintenance that really matter.</description>
		<content:encoded><![CDATA[<p>Oh a quick follow-up comment:  one of the great things about OpenSim is that prim count becomes far less critical due to the allowance of mega-prims.  When one can build a large floor with one prim instead of 25, and castle walls with one prim instead of a dozen&#8230; prim count becomes even less important an issue.  </p>
<p>When we opened our OpenSim, I built an entire castle using only 150 prims.  The same castle would have cost me nearly 1000 prims in Second Life.  The availability of megaprims has revealed a lot about just how limiting and arbitrary Linden Lab has been in their forcing users in to their company-defined mold.  Now that we are free of thos constraints&#8211; and free of the Linden Lab stranglehold&#8211; the potential of virtual worlds becomes apparent.  We come to realize that rather than promoting VR, LL has been holding it back from what it could hve been all this time.  Limited prim count, limited prim size and excessive prices have done more to strangle VR expansion than promote it.  </p>
<p>Fortunately, with the advent of OpenSim that will soon no longer be the case.  There will come a time when users will be able to relax when it comes to prim count and concentrate on issues of sim operation and maintenance that really matter.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Wayfinder Wishbringer</title>
		<link>http://www.adamfrisby.com/blog/2009/11/the-imaginary-45k-wall/comment-page-1/#comment-8550</link>
		<dc:creator>Wayfinder Wishbringer</dc:creator>
		<pubDate>Mon, 02 Nov 2009 19:21:34 +0000</pubDate>
		<guid isPermaLink="false">http://www.adamfrisby.com/blog/?p=487#comment-8550</guid>
		<description>I&#039;m glad to see a blog that deals with realities of hosting a virtual world.  Linden Lab has long propagandized their customers into thinking that sims are measured in terms of prims-- when in fact that&#039;s probably one of the LEAST important aspects of sim measurement.

We discovered this back in 2004, when someone loaned us a totally blank, new sim for a couple of hours to let us test the effect of prim count.  Even back then we were able to determine that the effect of prims themselves on sim performance was insignificant.

As you&#039;ve pointed out to an extent, avatars themselves are the largest drag on sim resources, followed by (at least in the case of Second Life) redundant texture loading, teleporting, rezzing, physics and finally scripting. 

I say finally scripting because in the case of most well-behaved scripts, it takes quite a few of them to impact sim performance (upwards of 3,000--7,000 or more). Of course, one badly coded script can do more damage than a thousand well-coded scripts.  

The primary point you make is excellent:  prims really aren&#039;t that big an issue on OpenSim with the sole exception of use of RAM. I admit I am not all that well acqainted with the ways that SL / OS impacts RAM, but I do know the more you have, the more RAM it takes.  In hosting situations, RAM costs.  

So in the end game, when it comes to designing sims I have to agree-- RAM is likely the primary concern.  I would like to see some kind of list showing general RAM usage (ie, 1000 prims = X amount of RAM) as well as how different aspects of sim design impact RAM. 

Most folks are under the impression that 512 megs RAM is sufficient to run a sim.  I have heard that 2 gigs is more viable... but then, 2 gigs can be pricey when it comes to purchasing host space.  

I am most fascinated by your take on core usage.  If the core rarely exceeds 10% impact, that means that a single core is more than sufficient to run a sim-- if processes are coded and handled correctly.  I have for some time been of the opinion that dividing processes between dual cores would be far more efficient.  It&#039;s not always the amount of core time that is important-- but WHAT is taking up that core time and the way that time is being used.  If one has two major functions demannding core processes at the same time... it doesn&#039;t matter if that core is only running at 10% or not, those processes will butt heads, resulting in stand-still lag (we&#039;re seeing that happen now on Second life whenever avatars teleport and lag the entire sim as a result).

Bottom line, I agree with the points you&#039;re making-- that prim count and sim performance has long been distorted and misunderstood.  The real issues of sim operation have little to do with number of prims.  It&#039;s my opinion that the ideal &quot;golden&quot; count for a 256m sim prim-wise is about 2,000 prims per 4096m (or 32000 prims total... more than double what Second Life allows).  But this could potentially be doubled even further by building on two separated levels (a second level at 2000m altitude, with ANOTHER 32000 prims).  

As far as I am aware... the only drawbacks in such would be 1. The tendency to use too many scripts  2. RAM demands.

Beyond this, we really should be able to use a truck-load of prims on OpenSim without serious performance impact.</description>
		<content:encoded><![CDATA[<p>I&#8217;m glad to see a blog that deals with realities of hosting a virtual world.  Linden Lab has long propagandized their customers into thinking that sims are measured in terms of prims&#8211; when in fact that&#8217;s probably one of the LEAST important aspects of sim measurement.</p>
<p>We discovered this back in 2004, when someone loaned us a totally blank, new sim for a couple of hours to let us test the effect of prim count.  Even back then we were able to determine that the effect of prims themselves on sim performance was insignificant.</p>
<p>As you&#8217;ve pointed out to an extent, avatars themselves are the largest drag on sim resources, followed by (at least in the case of Second Life) redundant texture loading, teleporting, rezzing, physics and finally scripting. </p>
<p>I say finally scripting because in the case of most well-behaved scripts, it takes quite a few of them to impact sim performance (upwards of 3,000&#8211;7,000 or more). Of course, one badly coded script can do more damage than a thousand well-coded scripts.  </p>
<p>The primary point you make is excellent:  prims really aren&#8217;t that big an issue on OpenSim with the sole exception of use of RAM. I admit I am not all that well acqainted with the ways that SL / OS impacts RAM, but I do know the more you have, the more RAM it takes.  In hosting situations, RAM costs.  </p>
<p>So in the end game, when it comes to designing sims I have to agree&#8211; RAM is likely the primary concern.  I would like to see some kind of list showing general RAM usage (ie, 1000 prims = X amount of RAM) as well as how different aspects of sim design impact RAM. </p>
<p>Most folks are under the impression that 512 megs RAM is sufficient to run a sim.  I have heard that 2 gigs is more viable&#8230; but then, 2 gigs can be pricey when it comes to purchasing host space.  </p>
<p>I am most fascinated by your take on core usage.  If the core rarely exceeds 10% impact, that means that a single core is more than sufficient to run a sim&#8211; if processes are coded and handled correctly.  I have for some time been of the opinion that dividing processes between dual cores would be far more efficient.  It&#8217;s not always the amount of core time that is important&#8211; but WHAT is taking up that core time and the way that time is being used.  If one has two major functions demannding core processes at the same time&#8230; it doesn&#8217;t matter if that core is only running at 10% or not, those processes will butt heads, resulting in stand-still lag (we&#8217;re seeing that happen now on Second life whenever avatars teleport and lag the entire sim as a result).</p>
<p>Bottom line, I agree with the points you&#8217;re making&#8211; that prim count and sim performance has long been distorted and misunderstood.  The real issues of sim operation have little to do with number of prims.  It&#8217;s my opinion that the ideal &#8220;golden&#8221; count for a 256m sim prim-wise is about 2,000 prims per 4096m (or 32000 prims total&#8230; more than double what Second Life allows).  But this could potentially be doubled even further by building on two separated levels (a second level at 2000m altitude, with ANOTHER 32000 prims).  </p>
<p>As far as I am aware&#8230; the only drawbacks in such would be 1. The tendency to use too many scripts  2. RAM demands.</p>
<p>Beyond this, we really should be able to use a truck-load of prims on OpenSim without serious performance impact.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
