I see on a fairly regularly basis reports that OpenSim supports 45,000 prims versus Second Life®’s 15,000. It’s rubbish; but it comes from a somewhat logical source. The viewer itself will not display more than 45,000 objects in the ‘prims parcel supports’ field. There’s no technical reason for it – it just clamps the value (and I’m not entirely sure why). If OpenSim is set to unlimited prims (or 99,999,999), the viewer will show it as ‘Supports 45,000 Prims’ and not what it really is (’Supports “99,999,999″ prims’).
But, you can go well above that boundary. Some of Shenlei’s Leviathan builds are now breaking the 160,000 primitive count mark (and I have no doubt she intends to push it further!), but those builds are incredibly intensive on other aspects of the system, particularly memory usage. Primitive counts as a resource delimiter have never been accurate as far as underlying consumption goes; how they evolved goes straight back to when SL was still a MMORPG with nifty building tools (circa 2002-2004).
This is evident in SL – certain scripts cause “lag”, popular clubs can block other users from accessing the region (by eating up the whole max avatar count) – neither of these is factored into the current resource limits. This is applicable in OpenSim too – an unscripted region will behave better than a scripted one, an empty region will have uptimes measured in months, a popular one in days (or hours).
So, with this entry I aim to do two things – first dispell the myth that OpenSim supports 45K primitives. That is incorrect – OpenSim supports whatever you tell it to handle, whether it behaves is up to the underlying consumption required for your build, and what you are hosting it on. And second – clarify where the limits really are, and how you can optimise them.
With SimHost, we needed to give a number to our potential customers that is indicative of their usage, in a manner that can be understood like prim counts, but reflects the actual capacity used. We decided to go with RAM usage – this is because memory is the primary requirement of the OpenSim software. The amount of memory a region needs is pretty much directly proportional to all the other requirements (scripts need a roughly equal amount of memory as CPU, so do avatars, prims, etc.). There are other limits too – network bandwidth, processor usage, etc. All of these can become a bottleneck depending on the design of a region.
To give you a rough estimate of capacity-by-memory, one of our heavier customers has a 10,000 prim sim which hosts weekly meetings; it’s somewhat scripted – memory use for this region is between 405MB (Resident) and 1070MB (Total). Each avatar to the region adds between 20 and 50mb to the “resident” figure (and when occupied, some of the paged memory moves into the resident as it is accessed). If you use this as an example – 1024MB of resident memory should get you a “standard region equivilent”; if you want to start pushing on it further, then you might want to allocate 2GB dedicated to the region.
Network bandwidth is directly tied to # of avatars plus, # of primitives plus, # and size of textures. You can drop your bandwidth requirements fairly dramatically simply by building more efficiently, encouraging texture re-use, optimising your textures, etc. Sculpties actually work to your benefit here – since they can replace many prims with just one; and that one is ‘instanced’ – so that every copy you use, is only downloaded once by the viewer.
Processor usage is generally not a problem; to avoid any issues – giving a region a dedicated core will let it do it’s own thing. Scripts are about the only thing that can really push this figure (and physics to a much lesser degree). With recent updates to OpenSim enabling much larger concurrencies – processor usage is beggining to appear; but an average user will often struggle to push an average CPU core usage of more than 10%.
So, next time you see the claim that ‘OpenSim supports 45,000 prims’ (as I often do) – think of it not as a hard limit, or even a ballpark figure that is remotely accurate. OpenSim will try serve whatever you tell it to — but whether it does so successfully is more likely to be up to other factors relating to the underlying hardware; than the software itself.
I’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’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’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’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’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’t matter if that core is only running at 10% or not, those processes will butt heads, resulting in stand-still lag (we’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’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’s my opinion that the ideal “golden” 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.
Wayfinder Wishbringer
2 Nov 09 at 7:21 pm
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.
Wayfinder Wishbringer
2 Nov 09 at 7:28 pm
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.
dahlia
3 Nov 09 at 1:00 am
Very informative post. Thanks very much for making it Adam.
Mo Hax
3 Nov 09 at 1:34 am
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.
rightasrain
3 Nov 09 at 10:48 am
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 “bound” to sl it prevents me from moving forward
thank you for the excellent explanation and for sparking my curiosity
Ener Hax
3 Nov 09 at 1:48 pm
I don’t know if they’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’s just easy to implement, and it’s all they’ve got right now. 15,000 prims “sort of worked” 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’s point of view, bandwidth is a huge issue. (The fact that we’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’re doing matters more.
Rob Knop
4 Nov 09 at 5:33 pm
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’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….
Intari Marjeta
13 Nov 09 at 5:10 am