jack linden Talks on concierge site these r his replies:

Unless there's been a complete change in the design in the past year, they're not using virtual machines.

And going to virtual machines would require buying a whole boatload more hardware. VMware claims a 3-6% overhead for computationally intensive applications, and that's the best case. 20% overhead is more typical. It would be almost like running an extra OpenSim or two on every server.

But it addresses the social aspects that cause the problem.
If Linden Labs was worried about that, they'd snapshot sims to disk and turn them off when there weren't any avatars in them.

Last infos i have (2007) were referring to vm's running on debian (vmware?). When a region restarts it finds a free spot on a server (*if it's not forced to go on a precise machine a/o specific datacenter) and there it goes. But vm or multiple istances, it doesn't change the substance of resource allocation and load balancing, because you can apply if not per vm/OS, but per daemon/application, it would be (almost) the same.
To be short i think they know perfectly how to have indipendent simulator on a single server (with any of them not affecting the others)... it's not a "new technology" and i'm not (i would be! ) the inventor of this.

Why addressing it (limiting anyone), when you can prevent the problem from the start, and with the advantage of not affecting the whole mass of "honest" users? There's the technology, let's use it, instead doing politic.

Another solution to the problem would be if Linden labs started to use computer newer then Commodore 64

It would help if you had a reference to that, because the descriptions I read make it seem like a sim is simply a collection of data and scripts that start a new instance of the squid cache and server software on that data. The snapshot process is handled by the sim application(s). If it was a VM you wouldn't need a region "restart" to move a region, you could snapshot the whole VM and restart the snapshot and the programs running inside it would never know.

I suspect you're confusing two different uses of the term "virtual machine". The Mono interpreter and workspace is referred to as a virtual machine, in that it's simulating a processor that doesn't exist. In this context a "VM" is a bytecode interpreter and a runtime environment. It's not really related to the VMWare or IBM 360 sense of the term.

So the sim doesn't run under the Mono VM. The Mono VM is a component of the sim software that interprets Mono p-code through just-in-time recompilation.
Have you done that kind of thing, on recent versions of Linux? The last time I looked into it they still really hadn't gone that far beyond "nice", and "nice" is too crude a tool for this.

It would be alot more complicate to handle the "mobility" of regions (across the grid) with a bunch of scripts while you may have a easy setup using virtual machines, even if it would eat "some" in terms of resources, since until now we are kept as reference vmware (OS virtualization) while you can virtualize a server at system level (sharing the same kernel).



This is exact what they told to me it happens, and u need necessarily to restart the region because of host/IP change.. anyway.



No i'm far to know what will happens if you try resource allocating with their server, did you tried to check if it works? But it's not me or you: don't you think that if a solution is needed they should look into it? Because sharing a server with other 15 "users" without any sort of resources managment will sure drive you into problems... and they are not a small company, anything here is network and databases, manage with this matters should be their first priority. A reply like: "we don't know how to do it" is not acceptable.

If they're designed to be standalone, it's not any harder. It's no harder on (say) a webserver to do:

cp -pR /nfs/master/sites/foo.com /nfs/slave/sites/foo.com; ssh slave "cd /sites/foo.com; ./starthttp"

Than to do:

cp -pR /nfs/master/sites/foo.com /nfs/slave/sites/foo.com; ssh slave "cd /sites/foo.com; vmware slave1.vmx"

All a "virtual machine" is, is a bunch of data files and scripts, that happen to contain a disk image, a memory image, and a configuration file.
If you're using the same kernel you're not using virtual machines, you're using something like domains or FreeBSD jails. I've done that too, in fact I have a number of clients I'm supporting remotely using jails. One difference between jails and VMs is that the jails are all on the same kernel, there's no VM overhead.
Can you provide a reference?
Try what to check if what works? On what server? I'm not at Linden Labs... but I've been working with UNIX (including Linux and BSD) systems for 30 years... including kernel and driver work, as well as big systems, running big applications and running many many small ones, as well as things like web applications, I've got a pretty good idea by now of what works.
What makes you think they haven't looked into it?
I've supported systems with 50 developers running on the same server, running some pretty heavy duty stuff... simulations of real-world processes running while other people are running compiles... with good response. UNIX is getting on for 40 years old now, and it's designed to handle many users efficiently, WITHOUT fine grained resource control.

Nope, otherwise i would have posted em from the start. If can collect more precise informations i'll let you know where "we uses virtual machines" comes from.



The fact that they are repeating: "a simulator usage would affect the other simulators on the same server"... since i simply can't believe they didn't found a solution to allocate resources per sim, it would means only two things: a) they never looked into it; b) they won't do it. Or it's expected that they need to hire you to show how it would works? Do you ever believe that a solution like this wouldn't be applicable? Sorry i don't, because this is the basic concept of a shared server: share the resource allocating em per user; and not fight with others to keep what you need.
When you design a network like this (multiple istances of an application per server) the VERY FIRST thing that comes to your mind is: "i have think how to allocate the resource before anything else"; hoping that the users will manage the server utilization themself is crazy, especially because they doesn't know how much resources they are really using in a precise moment... what's is supposed to do? Asking your sim neighborn about how many scripts he is running and adeguate yours?

c) they have a mechanism that works well enough already, when combined with application-internal resource management (like script throttling).

VMWare isn't free, and it adds significant overhead to the whole system, and there's no guarantee that it would work any better than sticking to one core per sim. Or even as well. I've used VMs extensively, and they're a long way from perfect.
Not really. Because 99% of the time the UNIX priority mechanism does a better job of allocating CPU to processes than anything you can do manually. It's a stable, robust mechanism that has worked very well for many thousands of networks with millions of users for decades.
Scripts are already effectively throttled by the sim. They are not an issue.

That would be a stupid solution, because the resources aren't calculate by a single (then subject to throttling) factor (such as the scripts), but by many others: avatars (you gonna trotthle the av numbers?), number of prims (limited really but it impacts a minimum; u gonna throttle em erasing contents?), textures (same as before, u downscale em on the fly?). You cannot control how these resources are being used internally to the application (you may check them but you cannot adjust em in realtime), it would be stupid to do so because they are dynamic (and they MUST be dynamic), the proper way is to "top" the resources used all together, so you don't have to care about what the task is doing internally.



They designed an unreliable network to save money on hardware and software? Then this is the result. B/w are you sure they aren't using vmware already?



I'm sure it WON'T work any better than using one core per SIM, but the point is that we are talking about OS, there are 4 of them per core, so the same solution they are using for the regular SIM is NOT applicable... unless they upgrade all the servers to 16 cores (!) machines.



As i mentioned before, there's no sense to throttle the scripts if the resources are already "abused" by other tasks (because the scripts will never top their maximum, the SIM (and all the other SIMs on the same core, if they do not allocate the resources in the proper way) will stall before then).

You can't control them outside the application, because only the application knows what they are.

If you just want to throttle the overall CPU available to the whole sim, you already have that with the regular sims, because they each dedicate a core to each, so each gets pretty close to 100% of a CPU. The only problem is the OpenSpaces, and the only reason they were even introduced was because they thought they wouldn't have the kind of impact they do. That was obviously naive, and some of us said as much at the time, but that's got nothing to do with the mud you're flinging about the original design.
This has nothing to do with the network. THis is all about the server design.
They weren't a few years ago, and there's been no announcement otherwise.
In other words, OpenSpaces were a poor decision. We're agreed on that. That's a completely separate issue from what I'm talking about.

If they had to add the cost of VMware licenses and extra servers they'd probably have to charge MORE for OpenSpaces than for complete sims.
Scripts weren't throttled to prevent abuse by other sims, they were throttled to provide more CPU within the sim for the physics engine. That work has nothing to do with OpenSpaces and inter-sim resource contention, could not have been accomplished using VMware, and was absolutely required.

That is: since that has already been done, there is NO ISSUE with scripts that requires VMware, and VMware WOULD NOT HELP with the script problem that led to throttling.

VMWare is not a magic wand, and comes with its own problems.

Sure you can control it outside the application, i do this everytime on my home PC... I can assign resource (any kind of resource, from CPU to network bandiwidth) to a running task and it NEVER hits other running applications on my OS. I can do this on my PC, they can't do this as "private", they can't do the same on a "commercial" server that should be designed to work like this from the start?



Eheh, so not only bad network design but bad business plan.



Of a network... (talking about the grid), im not talking just about a server, don't being confused by the bandwidth (that is also something affected anyway...).



They should have designed a resource allocator from start (with our without wvware). If they aren't using vms already, they should have if no other solution were available. We're talking about essential software to run your company, you can't save money and expect that anything will run itself without problems.



So why you mentioned them? We're talking about single how SIM impacts on the server.



In fact the problem is not only the scripts: it is the scripts. the prims.. the avs.. the textures... etc. That's why u need to control em at the top (not individually from inside the application).

They did, and I'm tired of explaining it.

They are not, because with my "lagging" OS i may slow down the other 3 OS that are sharing the same core (their admission). So you are not correct, or they are lying. I leave the decision to you.

Originaly OS price 3750 for $75. That's 50 prims/$1. With price increase to $125, its becomes 30 prims/$1. Lower prim count to 1500 at $50, its still 30 prims/$1.

Jake, you suggest 900 prims for $50? That means it will be 18 prims/$1. I believe LL will kiss your butt and offer you a job.

Plese re-read where I wrote that I agree that the OS experiment was a mistake. I am objecting to your characterization of the fundamental design of SL as broken. I've pointed THAT out multiple times as well, and you keep missing the point.

Argent, i perfectly understand what you mean and i suspect we're talking about two separate matters, when you say: "they are applying already a resource allocator", you mean they are allocating the resources internally to the application so (example) the scripts loading doesn't affect the physics processing; while i am not talking about how a "single" sim works, but how a SIM would affect *others* sim on the same server/core.
When you point to the fact that a regular SIM is already allocated correctly (and potentially won't affect too much the other simulators running on the same machine) it's because a regular sim is running on its own core and forced to use a single core, so we have today a majority of Class5 servers, that are Quad Core, the "exact" number to accomplish to that configuration *without* using a proper resource allocator.
While we're talking about OS here: four process are running on the same core, so clearly that configuration won't works, and you need to hard/dynamically limit each running process at its top.
We ended to discuss because your opinion is that these OpenSpace are new, and the system was originally designed to work under a different enviroment, so the problem is not a bad designed configuration, but a new "usage" of the servers that won't "fit" the current configuration. I don't agree on this for a reason: the Class5 server (quad core) arrived later, we used to have dual cores ones, so on each of them we had TWO (regular) Simulators running per core, reproducing the exact same problem we have today: an overloaded simulator were affecting the other ones "sharing" the same core (it was a common problem, and this site: http://neighbours.maxcase.info/index.php were pretty famous to find your "bad" neighbour). This demostrate that LL didn't designed correctly the system from the start, and instead of find a solution to allocate correctly each process via software, they decided to adopt the forced hardware solution: quad core > 4 sim. But again this solution won't work for OS's because it is unrealistic to upgrade to a 16 core (!) server. There's not suitable solution to resolve the problem, apart using (again) a correct resource allocator (it's what im proposing), or eliminate totally the OS'es so anyone will have a regular SIM running on its own core.

No. I'm also talking about the standard CPU allocation, memory allocation, and so on in UNIX. But I've also explained that as well.

You believe it is not possibile (or it won't work correctly) to allocate resources like i've explained on Linux? A simple "Yes it is possible", or "No it's not possibile", would be enough. Thanks.