[MUD-Dev] Architecture (Cell Rebalancing)

Peter Peter
Tue Jul 1 16:19:47 CEST 2003


"Zach Collins (Siege)" <zcollins at seidata.com> Wrote:

> Being inexperienced with this sort of thing, I have to ask: how
> does the algorithm know the physical layout of the equipment it's
> using?

Physical layout doesn't matter, as all cell handlers would be
co-located, crosconnected through equivalent
connection. (e.g. gigaeth/gigaswitch, few years ago would i say fddi
and many years ago would i say token ring :))

> If not, I would suggest simply measuring average ping times
> between units in the cell, and offering nearby Cell Handlers (also
> defined

if i would measure anything different than few microseconds (and
nonstable), the things would go very wrong :) the whole idea of
low-latency high-bandwith is that the latency is "almost" not
influenced by the bandwith used - or, to be more precise, the limit
where the latency is beginning to manifest is reasonably high.  The
latency should not be influenced by cpu utilisation neighter,
e.g. by utilising smp. actually with todays server network adapters,
even the non-smp should not be influenced. To some extent :)

actually, i believe i will abandon the whole idea of dynamycaly
resized cells in favor to non-spatialy localised cell handlers. (see
my other post), if that really proves to be better.

But if i choose any system, i will always need to have some
"overload monitoring & handling" subsystem, which will monitor the
high load, even predict the high load and do appropriate actions -
eighter hand-overs to less loaded components, or guard the system
not to allow certain actions(?)  etc.

But that would be much more than ping monitoring. that would be
monitoring of all mission critical resources, as for example:
bandwith/latency, cpu utilisation, memory utilisation.

Peter "Pietro" Rossmann
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list