[Quantian-general] how the process migration happen

[Bruce Knox]

While it is very unlikely that a single instance of a program written for a single-processor will, unchanged, approach running five times faster on an openMosix cluster of five processors, very often that unchanged program can make very good use of openMosix by running multiple copies concurrently.

Most of us are good enough programmers automate the splitting of the data for multiple runs, but most of us either lack the skills or perhaps more often lack the time to rewrite sequential applications into parallel.   That is were openMosix excels because in most cases there is no need to rewrite the application to benefit from the cluster.

Often I find that openMosix users think only of running one program per processor, but the better solution with openMosix is often to concurrently run more programs than processors.  This allows openMosix to dynamically optimize the whole cluster in ways that often exceed the results one could achieve by manually assigning programs to processors.  

After seeing many applications perform better than I expected on openMosix, I have concluded that the best way to evaluate the usefulness of openMosix is to test the application on the cluster.

There are few ways to test on openMosix faster than using a cluster based upon Quantian.  Bruce

>>> <vputz at nyx.net> 11/11/05 09:38AM >>>
On Fri, Nov 11, 2005 at 06:44:36AM -0600, Bruce Knox wrote:
> Chinchu, a Quantian cluster is an openMosix cluster.  http://openmosix.sourceforge.net/#Documentation will answer how the migration occurs and http://howto.x-tend.be/openMosixWiki/index.php/work%20smoothly will give you a quick idea of the kind of applications that can make good use of the process migration.  Quantian will get your running quickly so that you can test your actual applications.  Bruce

An addendum to this.  An OpenMosix cluster does migrate processes
automatically.  This means that any problem you can phrase as "start a
bunch of processes, each of which has a bit of the problem" migrate
automatically and easily.  Raytracing a complex image works well for
this and was the example I showed my students ("5 nodes, each one taking
1/5 of the scan lines").  It works well when the problems a) demand a
lot of processor time, b) don't need to interact, and c) don't need a
lot of data shuffled over the network.

(I tried something superficially similar, having an OpenMosix cluster
rip a CD's worth of songs to mp3--figured it would appeal to the
students--but shuffling the raw sound data over the network was so
costly that very few processes migrated).

If you're doing something a bit more serious (say a particle-in-cell
spatial simulation where boundary conditions must be exchanged between
large cells) you may have to get a bit more low-level.

None of these really have the holy grail of "I wrote this program
single-processor, and when I run it on a cluster of five processers it
will go five times as fast"--that doesn't work at all.  But OpenMosix is
really nice for some sorts of problems.

-->VPutz