From: "Greg Chesson" <greg@xtp.engr.sgi.com>
To: ralf@uni-koblenz.de, "William J. Earl" <wje@fir.engr.sgi.com>
Cc: Alex deVries <adevries@engsoc.carleton.ca>,
Igor Loncarevic <anubis@BanjaLuka.NET>,
SGI Linux <linux@cthulhu.engr.sgi.com>
Subject: Re: What about...
Date: Fri, 17 Jul 1998 11:01:42 -0700 [thread overview]
Message-ID: <9807171101.ZM18755@xtp.engr.sgi.com> (raw)
In-Reply-To: ralf@uni-koblenz.de "Re: What about..." (Jul 17, 7:29pm)
Ralf,
Beowolf machines don't have adequate IO for applications other than
things that resemble Linpack. The teraflop machine at Sandia would like
to generate output every 5 or 10 minutes, but it takes an hour to get
the computation result out of the machine. Beowolf machines tend to not
have adequate bisection bandwidth more many kinds of codes. Anything that
requires a cornerturn (transpose) is a good example. Also, Beowolf machines
tend to run a single code for many hours: they don't multiplex well,
or sometimes at all. But multiplexing and adapting to a dynamic load
is expected of many large scale machines and that requires some OS support
not found in the single-cpu or small-cpu-count OS or existing middleware.
We cannot afford to build
machines that are good only for Linpack.... it is better
to build a Beowolf cluster if that is the best fit for the job.
It is rather ignorant to think that because something like Beowolf can do some
some types of applications well, that some software work can make it do
all jobs well. That's like saying a Volkswagon could go 300 kph
if you drive carefully.
Linux has proven to be worthwhile as a node controller in an MPP architecture -
that's what a Beowolf is. But that does not make it ready for SMP nodes
that scale to large numbers. It seems wasteful to program a large scale
ccNUMA machine the same way as a Beowolf cluster: you'd be throwing away
most of the capabilities of the hardware. That's why I don't
think it is interesting or particularly useful... unless a massive amount
of work went into rewriting the io and memory management subsystems,
not to mention scheduling, administration, etc.
g
--
Greg Chesson
next prev parent reply other threads:[~1998-07-17 18:02 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <35ADF6D0.46FCB21E@BanjaLuka.NET>
1998-07-17 5:24 ` What about Alex deVries
1998-07-17 5:30 ` Greg Chesson
1998-07-17 14:11 ` William J. Earl
1998-07-17 15:07 ` Alan Cox
1998-07-17 15:07 ` Alan Cox
1998-07-17 17:43 ` ralf
1998-07-17 17:53 ` Alan Cox
1998-07-17 22:15 ` Jeffrey Watts
1998-07-17 17:29 ` ralf
1998-07-17 18:01 ` Greg Chesson [this message]
1998-07-17 18:19 ` William J. Earl
1998-07-18 1:57 ` ralf
1998-07-18 2:00 ` Greg Chesson
[not found] ` <wje@fir>
1998-07-17 17:47 ` Greg Chesson
1998-07-17 18:14 ` Alan Cox
1998-07-17 18:14 ` Alan Cox
1998-07-17 18:21 ` William J. Earl
1998-07-17 18:21 ` William J. Earl
1998-07-18 1:37 ` ralf
1998-07-18 1:58 ` Greg Chesson
1998-07-18 2:44 ` ralf
1998-07-18 10:47 ` ralf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9807171101.ZM18755@xtp.engr.sgi.com \
--to=greg@xtp.engr.sgi.com \
--cc=adevries@engsoc.carleton.ca \
--cc=anubis@BanjaLuka.NET \
--cc=linux@cthulhu.engr.sgi.com \
--cc=ralf@uni-koblenz.de \
--cc=wje@fir.engr.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox