Re: openmosix-2.6

Robert-
  Main problem is that openmosix is about High Performance not High
availabilty. In fact avalilabilty reduced in an openmosix cluster as now a
single failure anywhere in teh cluster can potenitally take out the whole
cluster. IT often usually wipes out at least the currently migrated jobs.
There are methods like the checkpointing software to reduce the problems
this causes.The daemon was orginally in teh kernel in teh 2.4 series so this
is just a move back, and we know the effectiveness of the in kernel design,
so it should speed things up again.

Evan

On 7/8/06, pogson <[email protected]> wrote:
>
>  Matt wrote:
>
>  Hi Felipe, Gianluca, et al,
>
>    Regarding 2.6.
>
> One of the problems with 2.6 is that communications between remote and
> home nodes isn't done very well.  There are race conditions and no
> synchronicity between nodes, so it's very easy for a process to crash.
>
>
> This is a saddening surprise. I suspected there were problems from the
> length of time it was taking.
>
> The fix proposed seems like an unnecessary layer. This is open source. Are
> there not examples of similar inter-process communication that can be
> adapted? Would synchronicity help? How about synchronizing clocks in the
> manner of ntp and working on even/odd or phased clock time quanta? That
> might not scale or work well in different networks but with some tuning it
> would surely eliminate racing. This could be a problem where the speed of
> transactions must be very high. Should OpenMosix be that general? Perhaps
> limiting it to slower environments is necessary. Migration and monitoring
> should not need to be that quick. Transferring data should be as fast as
> possible. Are the methods from the TCP stack too slow? Send a packet. Wait
> for a response. When patience runs out, send again.
>
> Recently, I have been looking at high-availability clusters. It seems to
> me the actions of OpenMosix and HA are similar in that under certain
> conditions on one node, changes must be made on another. They do that simply
> with Heartbeat for two nodes. OpenMosix is much more interesting, but should
> not some of the same techniques work? Can any size of network be made up of
> two-node clusters?  Cannot a node be a cluster?
>
> Perhaps I am naive, but I thought going to userland for most things was
> supposed to make life easier, or at least, limited only by our imaginations.
>
>
> I hope some of my rant will help stimulate discussion/ideas.
>
> Thanks, all
> Robert
>
> --
> A problem is an opportunity.
>
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>
>
> _______________________________________________
> openMosix-general mailing list
> openMosix-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/openmosix-general
>
>
>


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

_______________________________________________
openMosix-general mailing list
openMosix-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/openmosix-general