hubcap@hubcap.clemson.edu (Mike Marshall) (06/03/89)
What would make a good front end for a YMP, and why? We really want to make a good choice, and like most organizations, this will be our first and only Cray... we don't have any first hand experience on what make a really good front end. Thanks for your help. -Mike Marshall hubcap@hubcap.clemson.edu
malcolm@Apple.COM (Malcolm Slaney) (06/03/89)
In article <5674@hubcap.clemson.edu> hubcap@hubcap.clemson.edu (Mike Marshall) writes: >What would make a good front end for a YMP, and why? We really want to >make a good choice, and like most organizations, this will be our >first and only Cray... we don't have any first hand experience on >what make a really good front end. Why do you need a front end machine? (This is comp.arch, after all.) I think it is time to put the concept of a front end machine to bed. The only thing that stands between my fingers and our Cray is the generic Macintosh on my desk (and an Ethernet tied into a Hyperchannel.) Now that Cray supports NFS and the X Window System there is no reason that a Cray can't be just another Unix box (although quite a bit faster for numerical stuff.) Of course, not all jobs are economical on a Cray. I don't really have any need to read news on the Cray when there are lots of cheaper Unix boxes lying around. On the other hand, if I find a bug on the Cray I want to use the Cray mailer to report it. Remember, the users come first. Malcolm
limonce@pilot.njin.net (Tom Limoncelli) (06/03/89)
I have been told that one can do it with an Amiga with a '020 or '030
board (like the Amiga 2500). Oh course (disclaim! disclaim!) I
haven't actually seen it, and I don't remember who told me this.
--
Tom Limoncelli -- tlimonce@drunivac.Bitnet -- limonce@pilot.njin.net
Drew University -- Box 1060, Madison, NJ -- 201-408-5389
Standard Disclaimer: I am not the mouth-piece of Drew Universityhollombe@ttidca.TTI.COM (The Polymath) (06/07/89)
In article <5674@hubcap.clemson.edu> hubcap@hubcap.clemson.edu (Mike Marshall) writes: }What would make a good front end for a YMP, and why? We really want to }make a good choice, and like most organizations, this will be our }first and only Cray... we don't have any first hand experience on }what make a really good front end. About 2 years ago I happened to meet the computing resources manager for the Cray being used by Lockheed's Black Hole project. She told me they were using an IBM 3090 for the front end. -- The Polymath (aka: Jerry Hollombe, hollombe@ttidca.tti.com) Illegitimati Nil Citicorp(+)TTI Carborundum 3100 Ocean Park Blvd. (213) 452-9191, x2483 Santa Monica, CA 90405 {csun|philabs|psivax}!ttidca!hollombe
mccalpin@loligo.cc.fsu.edu (John McCalpin) (06/09/89)
In article <> hubcap@hubcap.clemson.edu (Mike Marshall) writes: >What would make a good front end for a YMP, and why? In article <> malcolm@Apple.COM (Malcolm Slaney) replies: >Why do you need a front end machine? (This is comp.arch, after all.) >I think it is time to put the concept of a front end machine to bed. 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. (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). (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. (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. -- John D. McCalpin - Dept of Oceanography - Florida State University mccalpin@masig1.ocean.fsu.edu mccalpin@nu.cs.fsu.edu mccalpin@fsu (BITNET or MFENET) SCRI::MCCALPIN (SPAN)
lamaster@ames.arc.nasa.gov (Hugh LaMaster) (06/09/89)
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
cquenel@polyslo.CalPoly.EDU (-3 more school days) (06/11/89)
In 10111 lamaster@ames.arc.nasa.gov (Hugh LaMaster) sez: >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? This could also be an argument for putting the compiler for your supercomputer on a "front-end". -- Compiling is usually not a typical "gotta have a supercomputer, or it won't EVER finish" type job. (At least I hope not :-) ya never know with new and aggresive optimization strategies!) -- Assuming the compiler is written in "C" or some-such, just move it over and compile it. It should present anywhere real porting problems. The code generated is the same. --chris -- @---@ ----------------------------------------------------------------- @---@ \. ./ | Chris (The Lab Rat) Quenelle cquenel@polyslo.calpoly.edu | \. ./ \ / | You can keep my things, they've come to take me home -- PG | \ / ==o== ----------------------------------------------------------------- ==o==
js@hall.cray.com (Jeff Stout) (06/12/89)
In article <4557@ttidca.TTI.COM> hollombe@ttidcb.tti.com (The Polymath) writes: >In article <5674@hubcap.clemson.edu> hubcap@hubcap.clemson.edu (Mike Marshall) writes: >}What would make a good front end for a YMP, and why? We really want to >}make a good choice, and like most organizations, this will be our >}first and only Cray... we don't have any first hand experience on >}what make a really good front end. > >About 2 years ago I happened to meet the computing resources manager for >the Cray being used by Lockheed's Black Hole project. She told me they >were using an IBM 3090 for the front end. You can use about anything its just a matter of how much you want to spend.