The good news is that the ``standard'' beowulf recipe, as simple as it
is, is very likely to result in a beowulf that can accomplish certain
kinds of work much faster than a single computer working alone. For
that matter, so is any OLD network - for some problems (examples will
be given later) the entire Internet can be put to work in parallel on
parts of the problem with tremendous increases in the amount of work
accomplished per unit time.

The bad news is that the phrase ``certain kinds of work'' fails to
encompass all sorts of common tasks. I really mean it. Only certain
kinds of work can be run profitably (that is, faster) on a
parallel processing supercomputer (of any design).

Even worse, as a general rule a task that can be run profitably on
a parallel supercomputer will generally not run any faster on one
unless it is specially designed and written to take advantage of the
parallel environment. Very little commercial software has yet been
written that is designed a priori to run in a parallel environment
and that which exists is intended for very narrow and specialized
applications.

Writing parallel software is not particularly difficult, but neither is
it particularly easy. Of course, some people would say that writing
serial software isn't particularly easy, and parallel is
definitely harder. Well, OK, for many people maybe writing parallel
software is particularly difficult. For one thing, any kind of
parallel environment is a lot more complex than the already complex
serial environment (which these days has lots of parallel features) and
this complexity can interact with your software in odd and unexpected
ways.

From this might guess that the design of the software to be run on
your beowulf-style cluster is likely to be at least as important to the
success of your beowulf effort as the design of the beowulf itself.
Actually, it is probably more important. As this work will
explore in great detail, a cost-benefit optimal design for a beowulf can
only be determined after many of the characteristics of the
software to be run on it are known quantitatively and an effective
parallel software design matched to the quantitatively known
low-level hardware capabilities.

Although this is a warning, it is not intended to be a discouraging
warning. On the contrary, the design above (augmented with a few more
choices and possibilities) is remarkably robust. That is, if one has a
``big'' computing job (the sort that takes a long time to run and hence
would benefit from a significant speedup) it is quite
likely1.15 that it can be rewritten to run (optimally)
profitably in parallel on a beowulf built according to the recipe or on
a possibly even cheaper and simpler NOW. The remainder of this book is
intended to give prospective beowulf builders and users a great deal of
the knowledge and design experience needed to permit them to realize
this possibility.

With that said, there are most definitely some limitations on this work
- there are things it isn't intended to do and won't help you with. At
least not yet. Perhaps as the book evolves chapters will be added (by
me or other volunteers) to address these topics.

In the meantime, for example, it will say very little about the details
of using e.g. PVM1.16 or MPI1.17 (or any other parallel support library set
or raw sockets themselves) to write a network-parallel program. It
presumes that if you are going to write parallel software that you
either know how to write it or are prepared to learn how from other
resources (some resources will be suggested). Similarly, it isn't
intended to be a guide to MOSIX1.18 or
Condor1.19 or any of a
number of other parallel computer or cluster management tools.

The one thing it is intended to do is to make the reader aware of
some of the fundamental issues and tradeoffs involved in beowulf design
so that they can do very practical things like write a sane grant
proposal for a beowulf or build a beowulf for their corporation (or
convince their boss to LET them build a beowulf for their corporation)
or build a tiny (but useful) beowulf-style cluster in their homes or
offices or out of their existing OLD network.

This latter case is a very important, concrete example of how
Linux-based cluster computing can provide near-instant benefits in a
corporate or educational environment. Consider the following: One very
powerful feature of the Linux operating system is that it multitasks
flawlessly as long as the system(s) in question are not constrained by
memory. Its scheduler has been deliberately tuned to favor interactive
usage1.20. As a
consequence, certain beowulf-style cluster designs will allow you to
recover the benefit of all those cycles currently being wasted on
desktop systems (in between keystrokes while people read their mail or
edit some document, or worse, running silly screen savers when the users
of the systems aren't even sitting at their desks) without
impacting the user of the console interface in any perceptible way.

This has to appeal to a small business owner with a big computing job to
do and a dozen desktop computers on a network currently twiddling their
thumbs (figuratively speaking). It can similarly benefit a university
physics or chemistry or math department, where there is a need to cover
faculty, staff and graduate student desks with SOME sort of desktop with
a web interface and editing/mail tools and there are also significant
needs for real computation. If those desktops are Windows-based systems
or Macintoshes, their load average is likely to be almost zero -
nothing they do on a regular basis requires much CPU - but the unused
cycles are wasted as the systems are utterly inaccessible from the
network side. If they are running Linux, one can easily run background
computations - the whole department can become a readily accessible
(transparent to the user) multiprocessor compute cluster managed by e.g.
MOSIX or can be running a real parallel (PVM or MPI based) calculation
- without the GUI performance of the desktops being noticeably
impacted1.21.

From this simple example it should be apparent that beowulf-style
cluster computing isn't really just for computer scientists or
physicists like myself. It can provide real and immediate benefits to
just about anyone with a need for computation (in the sense of
lots of compute cycles doing real calculations) as opposed to an interface. Nearly everybody needs to do local computations on local
data at least some of the time1.22 - beowulfery simply
provides an organization with the means to harvest the vast number of
wasted cycles that accrue when they aren't doing computations
locally.