🚀 go-pugleaf

In article <758@loligo.cc.fsu.edu> mccalpin@loligo.cc.fsu.edu (John McCalpin) writes:
>Some reasons for a front-end machine:

>(1) Cray MIPS are definitely not cheap, and it is difficult to
>    convince users not to run inefficient or inappropriate codes
>    on the back end.

This is debatable.  It is not clear that the applications you may be
worried about (editors are a typical worry) use any significant amount
of CPU time, anyway.  And, although Crays aren't the cheapest MIPS around
in the absolute sense, they still may be in the real world, where
interactive program development takes place during the day, and long batch
jobs the other 128 hours of the week.  Many things are cheaper to do on the
supercomputer than anywhere else in practice.  Can you prove it is cheaper
to copy a file to a remote machine to fix a typo than it is to fix it on
the supercomputer?

>(2) Cray disks are definitely not cheap.  A front-end with very
>    good I/O performance and lots of slots for cheap 1 GB SMD disks
>    can be very useful (provided it supports the Cray 100 MB/s 
>    high-speed channel).

With this I agree, and, it is a genuine "front end" function.  Like all
front-end solutions, however, most of the mass storage systems in use
at various supercomputer centers have major compromises one way or the
other.

At the moment, I suspect that a closely coupled NFS server may be the best
way to go.  Put your user disks holding source code, etc., on the NFS
server, and access it from both the Cray and user workstations and other
network servers.  But, since such a machine will be saturated by the higher
speed Cray, you won't be able to use it for running user processes - an
NFS server driven by a much faster client has to be segregated and dedicated,
in my experience and according to other anecdotal evidence I have heard.

>(3) Cray memory is neither cheap nor abundant.  Any jobs which do
>    not need to be on the Cray should not be on the Cray taking up 
>    memory from applications that need it.

I also agree with this.  Even if the MIPS are cheap (enough), the lack of
virtual memory on Cray systems makes this into an issue, as well as the
relative lack of physical memory (e.g. a mere 64 MBytes on a 4 processor
X-MP is the usual...)  However, some studies I have seen, where people
expected to find a problem here, showed that "little" things like
editing, other small jobs, etc., had a negligible effect on overall
memory utilization, so, in practice, it might not matter much.

>(4) A centralized front-end provides an appropriate spot for things
>    like mailers, mailing lists, news, etc.  This is slightly more
>    difficult to do in a "workstation & supercomputer only" environment.

You are arguing for a centralized data server which really is not a
supercomputer front-end issue at all, but rather a network design issue.
All intimately networked configurations have to solve this, whether there is
a supercomputer or not.

******************************************************************************

As I see it, the one major "front-end" issue defined above is: how do you
handle storage?  It easy for users to run processes wherever it is cheapest,
as long as the data is there.  Every supercomputer center that I know of has
a problem with respect to sharing data between the supercomputer and other
machines, with the solutions working to various degrees of success and always
seeming to cost more than it seems it should...
  Hugh LaMaster, m/s 233-9,  UUCP ames!lamaster
  NASA Ames Research Center  ARPA lamaster@ames.arc.nasa.gov
  Moffett Field, CA 94035     
  Phone:  (415)694-6117