Technical Solutions

One issue, and one that LL seem to have neglected to comment upon, is that of technical solutions to the open-space "problem" whereby they are using more resources than they should.

As it stands currently, simulators run on four-core servers, capable of running up to four regular simulators, or up to sixteen open-space simulators, or a combination of both.

The implication here is that each processor core of the server will run either a single normal simulator, or up to four open-space simulators. Likewise, the server's other resources should be similarly divided. And yet, somehow, the open-space simulators are currently able to consume more than their share of hardware resources.

My question then, is why isn't the hardware usage of simulators actually restricted? Prim, and avatar limits are an incredibly unreliable way of restricting a simulator. So, why is LL not using one of the many industry-standard solutions for limiting a program's hardware impact?

The main one that comes to mind is virtual machines. These have been used for decades now by web-hosting companies to allow multiple web-sites to run on a single machine, without any one site being able to eat up the entire server's resources. With virtual machines we can limit open-space sims to 25% of a processor core, 1/16th of available RAM, 1/16th of available bandwidth and so-on, making it impossible for an open-space sim to use any more than its fair-share.

Hiking prices, and reducing prim and avatar limits, do not solve the problem! This is a technical issue, and needs a technical solution. The problem is one of LL's own creation, and it's one that LL needs to fix, not the customers, who are being driven away en masse.

! dought Linden Lab tell us the truth un hardware usage on this, if they would ther would be no reason for all this.

Then they need to realise that they cannot lie to their community, as its diversity means that it contains people who are extremely knowledgeable about the various issues regarding SL's implementation. Indeed, the combined knowledge of the community far outweighs that of Linden Labs, we have computer scientists, business-owners, lawyers etc. etc.

It would take an incredible effort to find a concept that /someone/ in the community isn't familiar with.

The reason it isn't actually limited is because doing so would be a bad idea in a world where probably 80% of the regions are empty 80% of the time. Not imposing hard limits means that when regions are empty, other regions on the same server can benefit.

An alternative technical solution would be to just purchase a quarter-sim plot and then modify the client to scale up all coordinates by 4, so that the quarter-sim renders as being the size of a sim..

The majority of current VM solutions allow programs to take up any available slack, but scales them back if other programs on the same machine require more of their share.

Because that's not what virtual machines are for. When you're hosting virtual machines, you eat 20% of your CPU right off the top with the VMs overhead (VMWare claims 3-6% but that's only for CPU-bound tasks - and sims are heavy I/O users as well), plus you need to make sure you have additional CPU available for the host OS, and you'd need more memory to hold multiple copies of the OS kernel for each VM...

VMs have many benefits, but efficiency isn't one of them.

You'd end up with fewer sims per server to get the same performance you have now. They would have to charge even more than they are now.
Which would still be perceived as lag caused by other sims on th same CPU, even if they were only increasing to their "fair share".

Unfortunately you can't reduce the size of the avatar by a factor of 4.

You can render it on the screen as whatever size you like. Ok, the server would report collisions for the standard avatar size, but you'd have to build around that (most builds have a lot of space around the avatar anyway, to allow the camera to move). Or the client can just ignore them or use one of the known methods for pushing an av through a wall.

That is, of course, the point. That's already difficult to do with Tinies, and they're only half the current smallest avatar size.

You could also get rid of avatars, set your draw distance to 512, and just have everyone represented by scripted prims driven about by the camera, but the results are less than desirable.

Well, or you could have the avatars on the expanded parcel use a hidden chat or IM protocol to send location information to each other, bypassing the actual server completely. Ok, it means that collisions become client side, which is much less secure, but it creates the right effects.

(I've seen someone have the idea of letting people create private islands which are encoded onto notecards. The client reads codes from the notecard describing prims, renders them and then runs like it's a local sim. Every prim on them is phantom (no server to do collisions), they have no scripting (again no server), and you can't chat (..ditto) but you can IM (different service) - but if you just have a big piece of artwork you want to show off, or to build (just build) in privacy, that's enough..)

I think it would be much simpler to just use the regular client on an OpenSim with a larger area. It would be a lot less work, and just as relevant to SL. I mean, really, you're talking about more or less replacing everything the sim does with scripts and notecards... why re-invent the wheel when the OpenSim people have already done it for you?

OpenSim doesn't have the content base of SL, an alternate client running on the main grid does.

Oh, and I wasn't talking about scripts in particular, I was talking about a modified client.

If you have to rewrite all the scripts to operate on pseudo-avatars, and recreate all the content to suit the modified client, it doesn't matter... you're starting from ground zero either way.

Also... I thought that all that content didn't matter? It sure sounded like you didn't think that user-created content was much of a draw for SL when you were comparing it with Blue Mars.

Well, the clients would have to be written to deal with this. For example, for scripts, perhaps while the client renders the avatar happily flying onto the parcel, the client actually sits the avatar on a prim (so it's non-phys) - it doesn't render that, though - and then the client can position the avatar wherever it likes within the parcel, thus triggering scripts in the normal way.



The content _existing_ in SL is a draw compared to OpenSim. I can't say what the content would be like on Blue Mars. What I'm saying is that **the ability for a user to _create_ content** is not sustainable as SL's only unique draw - although it _is_ a unique draw, it doesn't draw that many people, and they alone can't populate a world (how many content creators think that they have "failed" if they are contributing their own money to SL's upkeep?)

That's great, unless the scripts the avatar wants to use are calling llUnSit() or llApplyImpulse() or llMoveToTarget(), and once you eliminate the scripts that depend on physics and anything else that gets broken by this model, and the content that doesn't scale, and everything else... you might as well be in OpenSim.

And given that you're pretty much re-implementing everything that a sim does, other than serve files...
In other words, it's both simpler and more effective to just use OpenSim instead of trying to create yet another incompatible sim environment.

The bulk of builds on SL are private houses where the only scripts are security orbs, media players, poseballs, and puppets. They don't generally need any of the functions you mention above. (Puppets here meaning any object that changes prim state in response to a click or menu, such as a door - after Puppeteer.)



Except that then you have the problem that the content won't move...

Poseballs and furniture would ALL be broken by the proposed changes, as would teleporters, and any puppets that used any non-local movement such as scripted pets (even if they're non-physical) because they'll be moving 4 times as far as they should.

And none of this has anything to do with the original idea of using virtual machine software to manage resources, except that it's a couple of orders of magnitude harder to implement, so I'm bowing out. OpenSim is already much more advanced than what you're talking about, and can probably use more of the same content as SL.

Ahh... no, they're not, because the actual coordinate system hasn't changed, only its visualisation. Think of it as, you rez a dollhouse on your sim. All the doors work correctly in the dollhouse, and then when the client renders everything bigger, it becomes a full-size house that your avatar can walk into and explore (provided it's phantom, or server collisions are ignored). But all the doors still work with the same region coordinates, it's just that 1.0m is now visualised as a greater distance on the client's screen.



It could use it, but creators don't seem to be interested in taking it there.

The main tech issues with OS seem to be a) Havok4 needing more memory than Havoc1, and b) failure of viewers to cache textures, resulting in excessive load on Asset servers. The former can be fixed with some code and more ram, plus limiting the number of avatars in the OS to 13 (1/4 a full sim maxAvatars). The latter is just shoddy programming, imho. I would much rather they raise the price to 90$ with current prims and a 13 avatar limit and go buy some ram for the OS servers than go off on this silly half-cocked solution that NOBODY likes or will follow.

The business model of selling somebody something and then forcibly exchanging it for a lesser product at a higher price, that's beyond any technical fix except maybe those involving clue-by-fours. And blaming the users for following the examples set in Mos Ainsley... that's just icing on the poop cake.

Well said, Shockwave. If only LL would pay attention to this kind of thinking. Not that it's too late, although I don't hold out much hope.

I'm sorry to say I agree with earlier posters, this isn't a technical problem, it's a corporate culture problem.

ATM LL has the only game in town. OpenLife AFAICT is pretty much non-functional, and OSGrid is a science fair project (albeit a very cool one).

As the only purveyors, LL can behave very badly and for the most part get away with it. Having a monopoly means never having to say you're sorry.

You seem to be looking at the wrong solutions, VMWare is more oriented towards running different OSes on a single host OS, e.g - Windows within Mac OS X.
What I'm describing is the use of virtual machines to partition up the system resources available to the host OS, in a way that is invisible to the program; i.e - as far as the program(s) are concerned they are just on a machine with limited, or constantly changing resources.
Current solutions like this include FreeVPS and Xen, which are often used for running multiple web-servers on a single physical machine, as they allow distinct versions of Apache or Apache processes to be run independent of one-another, while controlling their resource usage.

You still have all the overhead of multiple instances of the kernel and all supporting applications in memory, which increases the per-sim memory overhead. This kind of overhead can even a problem for things like FreeBSD jails... which provide a single kernel protection domain... when you have multiple instance of other daemons running. Given that the basic memory overhead of a sim is already a critical problem, I still don't see this as a good solution.

If you had a good single-kernel resource domain system, I could see it, but that doesn't seem to be available except commercially.

All it needs is a load balancer to distribute the multi-threaded code. That is assuming that the code is writing in multi-threads. So it is a good project for the OpenSim folks. SL is a dinosaur, so give it up...

It all depends on how the LL simulator currently operates, if I knew that then I could give more specific, or more specialised solutions. However, the memory overhead I think is an extremely minor one, the kernel only needs to be loaded once, and simulators are likely running as multiple distinct instances already, the extra overhead is on managing them which isn't huge, most virtual-server solutions, even open-source ones are pretty lean.

Considering the ridiculous amount of money LL is charging for simulators as it is they can afford to upgrade the RAM so the damned things have enough, even server-grade RAM is extremely cheap nowadays. Hell, my home-computer has 10gb of 800mhz ECC RAM.