Re: [Openmosix-Devel] Recommendations

Paul, Wes, all

I actually meant to write to the list before the week-end, but this is
a good opportunity.

It's great to see that a few people have jumped into action (incl.
Florian) to try to finish the port of oM to 2.6.

As to the reasons for my decision:

It is true that time and resource constraints have played a role, but
only a minor one. After all, I have been able to keep the project
going while I started no less than 5 companies and keep them all
running, am involved with several others, wrote two books, and did
several of the other items on my list "things to do before I die".

The real reasons for my decisions are indeed tied more to the
long-term vision and feasibility of the project. openMosix is about
high performance computing, in other words let  CPU (and to some
extent) RAM intensive apps run as fast as possible without hindrance
from the limitation of resources on local computers. We have all seen
that there are severe limitations to the SSI model due to the extreme
high impact of network latency, and due to the infeasible cost of
fully virtualizing the memory model (ie DSM), and the OS control block
across several nodes.

It is tempting to think that with massive multi-cores, the advantage
of an SSI cluster stays because then you have "even more CPUs to play
with". That is not so. The migration from a  multi-core system where
multi-threaded applications (as all apps are currently being
re-written as) thrive and performe well to another such node, implies
a DSM model capable to relocate threads either in gangs or single
across nodes. In other words multi-cores are changing the application
landscape towards a massively threaded one, and these apps will not
perform well in a DSM cluster by definition due to very high true and
false sharing.

Tests we performed at my company Qlusters with very low latency
inter-connects (< 1microsecond round-trip latency) with a very
efficient implementation of DSM have shown an regular performance
impacts of 100x to 1000x.

Even the sgi Altix let's threads run in the same SMP quadrant.


The other big reason is that I have over the last two years
intensively looked for a successor and was not able to find somebody
with the willingness, stamina, maturity, leadership, and coding
expertise to take over.

If this announcement brings forward somebody to deal with this latter
issue, that doesn't solve the prior issue of multi-core application
models.

Finally, another reason is that user numbers have been going down very
quickly and mostly these were users with, say,  4 or 5 nodes with a
total of 4 to 6 CPUs. Well, you can get all of that with much simpler
ease of use with a dual socket, quad core system today.

Please hammer away with comments. :-)

Moshe



On 7/18/07, Wes Wagner <[email protected]> wrote:
> Paul,
>
> I am working with the author of omuscd on a 2.6 openmosix port to the 2.6.22
> Kernel... I need to talk with him some more, but you should expect that the
> openmosix cluster will be picked up by another team.
>
> I just need until this weekend to get things organized. I believe Moshe
> underestimates the need for using multicore systems in a massive set and
> forget mode so people can do without the overhead of being concerned with
> queue and batch management.
>
> We have such a need and are currently building a 40 core farm expected to
> grow to the thousands of cores. It is my personal opinion that this
> announcement came mostly due to time and resource constraints, not the lack
> of a need for SSI style clustering.
>
> Please watch this space in the coming weeks:
>
> https://sourceforge.net/projects/om-2-6
>
> Our intent was originally to provide a source tree where you could download
> an x386 x686 x64_86 source that included the omuscd management daemon and
> went clean onto a vanilla kernel. I expect that the project will expand.
>
> Sincerely,
> Wes Wagner
>
>
>
>
>
>
> On 7/18/07, Paul Bennett <[email protected] > wrote:
> >
> > Hi List,
> >
> > I just found out that openMosix was getting end-of-lifed.  Does anyone
> have any recommendations for another clustering option?
> >
> > I would like to go with something based on the 2.6 kernel and amd_64.
> >
> > http://sourceforge.net/forum/forum.php?forum_id=715406
> >
> > Thanks,
> >
> > Paul
> >
> >
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2 express and take
> > control of your XML. No limits. Just data. Click to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > openMosix-devel mailing list
> > openMosix-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> >
> https://lists.sourceforge.net/lists/listinfo/openmosix-devel
> >
> >
>
>
>
> --
> Wes Wagner
>
> Join a libertarian network of person-to-person lending on Prosper:
>
> http://www.prosper.com/groups/group_home.aspx?group_short_name=freelibertarians&referrer=AiriusTorpora&utm_source=referrer-AiriusTorpora&utm_medium=referral-link&utm_content=join_my_group-160x33&utm_campaign=referrals-group
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> openMosix-devel mailing list
> openMosix-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/openmosix-devel
>
>

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/