[Beowulf] Re: Cheap SDR IB

[Robert G. Brown]

On Tue, 5 Feb 2008, Eugen Leitl wrote:

> On Tue, Feb 05, 2008 at 09:53:10AM -0500, Robert G. Brown wrote:
>
>> And they may well do this.  There are a lot of problems in provisioning
>> online MMRPGs with "Universes" that are shared with HPC clusters and
>> with HA clusters.  Most of the sane ones spin off the actual rendering
>> onto the clients, but they are still responsible for managing a huge
>> inventory of objects as well as all the NPCs, in realtime interaction
>> with PCs, in a large distributed "space".  In some cases e.g. WoW the
>
> The Second Life does the physics server-side. With the given technology,
> a region (one virtual server) will become sluggish (and soon herafter
> crash) after some 60-70 avatars frolick in the area.
>
> There's definitely potential for better interconnects and game
> clusters (deja vu, we must have discussed this some 5-8 years ago).

Yeah, and my experiences with 2ndL are highly negatory as a consequence.
It is a bad cluster design.  It does not scale.

>> space has some fairly obvious boundaries -- different continents are
>> plausibly on different servers in a realm cluster, ditto instances,
>
> SL islands are rectangular boxes (the client used to crash spectacularly
> when altitude exceeded a signed short int). The world tesselates trivially
> on a 2d or 3rd grid/torus.

SL needs to adopt some of the technologies of other MMRPGs -- the ones
that work.  It makes the result more complex on the client side -- one
has to update WoW every six months or so with new textures, maps, and
display side bugfixes -- but it scales much, much better on the server
side and is much less bottlenecked at the client side network (which may
be "only" DSL).  SL is a resource hog all around.

I note that people are most impressed with it if they've never hung out
in one of the well-designed, scalable worlds of WoW.  Any player of WoW
would laugh and cry to see how primitive, slow, clumsy it is.  It has a
good idea -- the ability of users to create objects and add them to the
environment -- but it needs a much better algorithm for managing the
construction process and an object-oriented look-ahead synchronization
process that reduces the bottlenecks to something endurable.

   rgb

-- 
Robert G. Brown                            Phone(cell): 1-919-280-8443
Duke University Physics Dept, Box 90305
Durham, N.C. 27708-0305
Web: http://www.phy.duke.edu/~rgb
Book of Lilith Website: http://www.phy.duke.edu/~rgb/Lilith/Lilith.php
Lulu Bookstore: http://stores.lulu.com/store.php?fAcctID=877977