bernhold@qtp.ufl.edu (David E. Bernholdt) (03/12/90)
We just took delivery of an FPS-500. Right now its running diagnostics, but within a couple of days, we'd like to have it talking to the rest of our network -- Sun workstations and servers, and, in so far as possible, providing the same software tools. So I'm seeking warnings, advice, or war stories about FPX's YP and NFS implementations, and about porting the following software: GNU emacs tcsh top MDQS (no, we didn't buy NQS -- we're setting up our Suns with MDQS too) Please note that I haven't yet begun trying to build any of these on the FPS, so I would just like to hear from anyone who may already have some of these running to see how hard it is likely to be. It would be nice to hear that everything builds like a charm on this machine... Thanks in advance... -- David Bernholdt bernhold@qtp.ufl.edu Quantum Theory Project bernhold@ufpine.bitnet University of Florida Gainesville, FL 32611 904/392 6365
scp@acl.lanl.gov (Stephen C. Pope) (03/13/90)
There are others out there with 500s. We've got one here at the
Advanced Computing Lab at LANL. For context, it sits in a room with a
64Knode CM2, a Stellar and an Ardent Titan graphics boxes, a MIPS
M2000, lotsa suns and a vax, and soon to be several other non-cray
``supercomputer-class'' multiprocessor machines. Our 500 is really a
511, with one scalar and one vector processor and several gigs of
disk.
We have running on the system X11R4 (client and libs only, no
server!), Gnu emacs, berkeley's bind 4.8.1 (the supplied named is
*really* old and uninteresting), lots of other gnu utilities (no
gcc/gdb yet!), and such. I'd be happy to provide config files for
these sorts of things if you ask.
War stories: Look out for NFS. It's based only the older version 3
stuff from sun, and doesn't implement a lot if important parts of the
protocol. For example, there is no truncate up call. This is a big lose
if you've got suns around, which frequently use the cliche:
int fd = create(somefile...);
char* array = mmap(fd...);
ftruncate(fd, ARRAYSIZE);
array[i] = something;
For this reason, it is not possible to use the 500 as a root/tmp
partition server for a sun client.
Also, the NFS implementation is unduly slow. Considering that on has
a 40 MIPS processor with fast local disk, the 500 ought to do several
times better han a sun 4/260. However, (our own informal) tests show
that the 500 is 3 times slower than a sun 4/260 for NFS service.
We have also discovered other strange problems in serving sparc binaries
from the 500. We don't really know what's going on, but almost always
we can move the same code over to a sun-served partition, and all the
weird problems go away.
Also look out if you've got suns: you don't want to stripe your disks,
and you must use 4k blocksized partitions! Some of this is due to weird
unexplained problems, and some is due to the fact that ld, among other
things, makes some (incorrect) assumptions about physical block sizes.
We were originally excited about using 64k blocksized striped partions
for all sorts of things, but we've since had to eliminate all of them and
just use 4k blocksized unstriped partitions. This is of course more
sun's fault than FPS's, but be aware!
We tried to use the FPS as the main YP server with a couple of slave
servers (suns running os4.0.3 and the stellar), but that was a disaster.
However, it seems to work ok as the master server now with only suns running
os4.1 as slave servers. We did have to do some hackery to get the FPS
to produce hosts maps that will work with suns way of tying DNS into yp,
and also for producing the netid, bootparams, etc. databases. The YP
isn't great, but it seems to work ok.
On the brighter side, we've had very good luck with people moving
fortran code to the 500 from sun and cray environments. Normally,
you just ftp the code over, compile, and go. With a little work with
the compiler people at FPS, we're starting to get fairly well optimized
code.
The C compiler is another story. Of course, it is a disappointment
that the C compiler doesn't vectorize. Also, the compiler in the os 4.1
distribution is too small - it uses static tables for everything, and it's
not hard to blow it up with big codes, like X11R4. The compiler to
be distributed with os4.2 (due any day now) has much larger static tables,
and work will be underway soon to do all the tables dynamically. By the
way, watch out 'cause the enum and void support is marginal.
Generally, the folks at FPS are *very* responsive, and quite willing
to help you figure out the problem and get it fixed. Except for NFS,
which they seem to be lukewarm about bringing into this decade. This
is somewhat understandable, as sun is notorious for making major
changes to the protocol each release, and it's hard to keep up with.
But for now, it makes the machine much less useful than it could, and
ought, to be.
By the way, I speak for myself and my coworkers would probably disagree
with everything...
stephen pope
advanced computing lab, lanl
scp@acl.lanl.gov