http://secondthoughts.typepad.com/second_thoughts/2007/11/ten-reasons-we-.html

I see more clearly now what a World Transhumanist Society *conspiracy* all this hacking and open-sim stuff is : )

Morgaine is in full regalia here ROFL.

Well, transhumanism is pretty much on hold, waiting for nanotech, which got delayed by Bush and vested interests. Annoying

Actually…it’s not that this sectarian and esoteric ideology is “on hold” — it’s just that it can’t find adherents because it is too rigid and too wacky. Bush is hardly responsible for “delaying nanotech” (?!) and the concept that “vested interests” are to blame sounds like some kind of nutty conspiracy! Maybe nobody will pay for Morgaine’s nanotech sandbox *shrugs*.
http://slrecord.typepad.com/the_second_life_record/2007/11/a-jointly-arriv.html#more

Still, there is a fundamental flaw in the overall SL system, and the OS Grid will not address it immediately. SL simulators were designed to work similarly to a web server: they have an amount of finite space and allow a finite amount of users. Massive distribution exists on the Web because people can easily copy a whole site on a second server and balance the load among both. If you need to support more users, you just keep adding servers. The Web, being a stateless protocol, is very good at this sort of copy-content-and-paste-it-on-another-server-to-split-the-load.

SL, however, is far from stateless! Thus, a different architecture will have to emerge, and we’re far from even imagining how that would work. Dynamic allocation of CPUs on a massively distributed system is way beyond what SL is able to do right now.

SETI@Home, and its successor, Boinc, work at parallel computing. Under this scenario, the data to be processed is simply split into “chunks”, and each CPU (on a user’s home computer) gets a chunk and processes a bit of the data, and then all gets assembled back again. A similar model is p2p networking for sharing files: you just split them up in chunks and download each chunk separately from different servers running on people’s homes.

SL does not work well under this model. Or, if you wish, part of it is actually similar, but not the critical bits. For instance, currently, textures (well, all assets really) are spread across the 12,000 simulators. In theory, your computer could open 12,000 connections to each simulator and get the textures directly from each of them; this way, overall, the simulators would have less work, since the “empty” sims would be helping out spreading the huge load of streaming textures.

However, this doesn’t scale well. With 50,000 people online simultaneously, the sheer number of open connections required for this model to work would exhaust a server’s ability to handle them (connections are limited to a certain number; this can be tweaked, but it’s not “infinite”; also, you can tweak them on the servers, but what about the clients running on a computer from their homes?). What Linden Lab devised instead is placing a proxy server for assets on each simulator, and making the client’s computer just connect to the proxy server instead, while on the background, all textures required for a particular sim are funneled from all over the grid and stored locally. So while the assets are totally distributed over the grid, when connecting to a sim, a local copy of all the textures you need (around 100,000 for a regular sim; more, of course, when avatars with attachments start logging in) will be ready for download as soon as your teleport finishes.

If you look at your texture cache in your computer, you’ll see that they are anywhere between 10k and 100k in size (some are way bigger). I didn’t compute an average, but this basically means that a whole sim could very well take about 1-10 GBytes to download. You don’t get all the textures in a sim, however — things like occlusion will prevent some faces to be displayed, and it’s worthless to send textures that will never be seen. All this is rather cleverly done. But as you know, your local cache can be set only to 1 GByte, meaning that a single sim can simply exhaust the size of your own computer’s cache. Walk across a dozen of sims, and it’s the end of your computer’s disk space

Now, how can this be solved? Right now, as you said, figuring an alternative solution will most definitely “win the jackpot”. All we know is that things are way complex — more than the average programmer imagines — and that LL’s solution, while certainly not perfect, was not so silly at all. I just think that they grossly underestimated user mobility (ie. people are hopping from sim to sim at all the times) and, of course, the amount of people that will gather on events.

I imagine that a first way to deal with this problem of massively distributing the grid would be to separate three aspects of a simulator’s job: tracking users, streaming textures, handling physics. The reason why most MMORPGS can get far more users per CPU is because they don’t need to stream textures, and to a degree, the physics engine is loaded on the client. So the servers only handle tracking data, which is the least demanding issue on the sim. The problem is that the “tracking engine” in SL is starved for CPU resources in a busy sim, full with textures of all avatars that are dropping by, and with the physics engine dealing with all the movements and bumping into walls and other avatars. If the solution is to separate the three things between different hardware — I don’t know. I can imagine that “dynamically” tracking users — not unlike what OpenCroquet does — might help to make it more distributed. Assets can be offloaded into separate systems — in fact, weren’t it for the costs, LL could simply put all textures on Amazon’s S3 distributed infrastructure, and just handle tracking & physics. In fact, even with the current costs, it might pay out (I haven’t made the calculations). The physics engine, of course, is a major culprit. Havok 1.0 simply cannot handle this. Havok 4.5 might help, as well as splitting the task of handling physics between the client and the server. However, this would mean that the client could not remain open source any more. Plan B, of course, is to use an open source physics engine running on the client — many exist — but that is definitely a major development for many years…

So, in the short term, I fail to see how things could be made “better”, except for delegating the responsibility of the asset server and the other centralised servers. This will naturally help a lot — even allow parts of the grid to keep running when a “local” asset server dies — and the nice part of those changes is that they can be performed on a “live” grid, over time. And offloading the stress of streaming textures to a separate infrastructure would also help a lot. The rest, well, requires some genial breakthrough never attempted before — coming from the “bunch of kids” or LL

The future grids must have a different architecture than LL’s model. Instead of fixing a CPU to serve a number sims, they’ll redistribute processing power in response to avatar density, through paralell processing. In other words, if you visit a sim, you share part of your CPU to process that environment. The SETI project used paralell processing years ago, why couldn’t it be applied in the metaverse? With proper algorithms, that should greatly decrease server overload and bandwith demand, and get us closer to the 1CPU’s avatar dream.

The metaverse must apply the web 2.0 core principle: more users automaticaly strenghten the grid, the inverse of overloading it.

The first team that gets such a grid working wins the jackpot, no matter if they’re a bunch of kids.

Why don’t you like the idea of owners of objects being able to sell them? I thought that the trans/no trans permission dealt with that in any case.

As to .NET, there’s nothing to stop that being opensource – there’s always Mono

As these are significant aspects of content you’d pretty much have to recreate all content from scratch.

I’ve never been impressed with LL’s permissions system, nor the economics of ‘owner’ selling vrs ‘creator’ selling.

What struck me half way through was, “How can this be OS grid if it’s based on .NET?”

I’d like to see a sports arena sim where the players are renderd and the ‘field’ but non of the spectators(ghost viewers). How many spectators could such a sim maintain? What would the lag increase per spectator be compared to rendered AVs?