Xref: utzoo comp.arch:10193 comp.misc:6298 Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!ames!ames.arc.nasa.gov!lamaster From: lamaster@ames.arc.nasa.gov (Hugh LaMaster) Newsgroups: comp.arch,comp.misc Subject: Re: front ends to crays... Message-ID: <26694@ames.arc.nasa.gov> Date: 9 Jun 89 15:05:15 GMT References: <5674@hubcap.clemson.edu> <32216@apple.Apple.COM> <758@loligo.cc.fsu.edu> Sender: usenet@ames.arc.nasa.gov Followup-To: comp.arch Organization: NASA - Ames Research Center Lines: 68 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