alan@mn-at1.UUCP (Alan Klietz) (09/17/87)
<>
--------
From: umn-cs!rutgers!topaz.rutgers.edu!root (Charles Hedrick)
Date: Sun, 6 Sep 87 20:44:46 EDT
Sun has a joint project with NAS to port all of their operating system
to the NAS IBM-compatible equipment. This must certainly include NFS.
--------
From: umn-cs!rutgers!gatech!emory!arnold (Arnold D. Robbins {EUCC})
Date: Mon, 7 Sep 87 17:31:06 EDT
Organization: Emory University Computing Center
Amdahl will have NFS in their next version of UTS, about a year from now.
That version of the system will be based on SVR3 and will support AT&T's
RFS as well, and tcp/ip.
Right now, tcp/ip software for UTS is available from The Wollongong group,
but it ain't cheap (altho neither is UTS). A System V version of a user mode
NFS server is available from Lachman Associates. Lachman are the people doing
the NFS stuff for Amdahl.
In sum, all the pieces can be gotten to make UTS into an NFS server, but it's
gonna cost, and you have to put it all together yourself.
We have a 3090/180E with a DACU and WISCNET, and would be very interested
in anything that would let us use that machine as an NFS server, as we're
very involved with NFS. (What is your XFS?)
Thanks,
--
Arnold Robbins
ARPA, CSNET: arnold@emory.ARPA BITNET: arnold@emory
UUCP: { decvax, gatech, sun!sunatl }!emory!arnold
ONE-OF-THESE-DAYS: arnold@emory.mathcs.emory.edu
---------
From: ihnp4!ihlpa!rjh
Organization: AT&T Bell Laboratories - Naperville, Illinois
Hi Alan!
Please, see also: Amdahl's UTS(tm) operating system which is Unix(reg.tm
AT&T) compatable. It runs on Amdahl processors and on other Amdahl-compatable
processors under IBM's VM operating system, e.g. IBM 3090. IBM 3380 DASD
could be used; we feel that what we sell (6380's) is better and cheaper.
Randolph J. Herber, Amdahl Sr Sys Eng, ..!ihnp4!ihlpa!rjh,
(312) 979-6553, IH 6X213, AT&T Bell Labs, Naperville, IL 60566
--------
From: hender@ames-prandtl.ARPA (Bob Henderson)
Subject: Re: NFS on Big Blue (How about Amdahl red)
Amdahl's UTS will be supporting NFS in a forth comming major release.
Should be available by 2Q88.
UTS is a Unix System V release 3 port; it is supported as the native OS on
Amdahl h/w and will run under VM on IBM stuff. UTS also supports TCP/IP
over ethernet (via Wollongong s/w (currently)), we at the NAS program at
NASA-Ames have added TCP/IP via NSC-Hyperchannel.
In addition, the NAS (Numerical Aerodynamic Simulation) Program, is starting
a new major effort to turn UTS into a major, high performance network file
server. This includes overcomming some of the standard Unix shortcommings:
files limited to a file system limited to a single volume,
poor performance due to small block size (4k for UTS still isn't enough)
poor perfornamce due to scattering of blocks (random ordered free list).
We also plan to provide file migration from the other nodes on our networks to
the MSS (mass storage subsystem), and from disk on the MSS to cheaper levels of
storage (3480 tape cartridge).
-Bob Henderson
GE
NAS Program
NASA Ames Research Center
arpa/milnet: hender@prandtl.nas.nasa.gov
uucp: {ucbvax, ihnp4, hplabs}!ames!prandtl!hender
--------
From: alan Fri Sep 11 03:20:52 1987
To: hender@ames-prandtl.ARPA
Subject: Re: NFS on Big Blue (How about Amdahl red)
Thanks for the note [above].
I benchmarked an Amdahl 580 machine about 8 months ago (at Cray Mendota)
that was running UTS V in order to get DASD I/O throughput timings. The
numbers were a bit lethargic:
dd if=bigfile of=/dev/null bs=256k
copied data at 4 mbit/second. This number is low compared to MVS (20 mbit/sec)
but similar to VM's throughput (also low).
Originally, I thought this was due to channel program translation overhead.
As a test, I wrote a small virtual program that just wrote data out
in track sized chunks. It got 11 mbit/sec. A version with cylinder sized
chunks got 20 mbit/sec.
(A plausible explanation of the results is that UTS is doing sector I/O
and missing a revolution each time. Of course, the tests were done
8 months ago, and UTS 580 is now available, so the figures might be obsolete.)
Also, historically, the performance of various TCP/IP offerings for IBM systems
have not been up to channel speeds. (kilobits/sec compared to megabits/sec)
It may be necessary to eschew the IP protocols on the direct Cray->IBM line,
and use a higher bandwidth (read: larger packet size, less overhead)
method.
>... the NAS (Numerical Aerodynamic Simulation) Program, is starting
>a new major effort to turn UTS into a major, high performance network file
>server.
>
>This includes overcomming some of the standard Unix shortcommings:
>
> files limited to a file system limited to a single volume,
> poor performance due to small block size (4k for UTS still isn't enough)
> poor perfornamce due to scattering of blocks (random ordered free list).
All of your points about file system performance are well taken, thanks.
--
Alan Klietz
Minnesota Supercomputer Center (*)
1200 Washington Avenue South
Minneapolis, MN 55415
Ph: +1 612 626 1836 ARPA: alan@uc.msc.umn.edu (was umn-rei-uc.arpa)
UUCP: ..rutgers!meccts!mn-at1!alan
(*) An affiliate of the University of Minnesota
--------
From: hender@ames-prandtl.ARPA (Bob Henderson)
Date: Fri, 11 Sep 87 09:25:03 pdt
Subject: Re: NFS on Big Blue (How about Amdahl red)
As for the UTS disk I/O timings, Amdahl did some studies which I also did
on the effect of the "gapping" factor [ ordering of the free list so the
next available block is the next block or 1 is skipped, or 2, ...].
The two studies showed different results; which might have been caused by
being under VM here and not at Amdahl, or the size of the processor, or
load on the system or some whim of nature.
Amdahl use to recomment a gap of 3, now they recomment a gap of 1. My test
showed that the system could in fact write with a gap of 1 and keep up,
giving much improved single file timings over a gap of 3. However, unlike
the Amdahl study, my test showed the read couldn't keep up with a gap of 1.
ADDITIONAL, its all meaningless in the real world, because my study showed
without doubt, that when the free list is in a random order, as after a period
of usage, the gap factor doesn't apply any longer.
The best timings were for disk i/o at about 1 mByte/sec. Thats why we are
going to rewrite the file system. Amdahl is comming out with "file system
switch" capablity, so it will be some easier than it might be. Also, Amdahl
has reconized the problem, wanting to penatrate the supercomputer sites, and
has agreed, at least in principle, to work with us on the problem.
As far as TCP/IP, we see about 1Mb/s on the ethernet, 5 mb/s (little b is bits)
on the hyperchannel. We have a "big file copy" protocol that makes use of
multiple adaptors and trunks on the hyperchannel and is currently able to
achieve 8-12 mb/s, we hope to get it upto 25 mb/s.
----------------------------------------------------------------------------
-bob henderson (415) 694-4361
M/S 258-6 arpa: hender@prandtl.nas.nasa.gov
NASA Ames Research Center hender@ames-nas.apra
Moffett Field, CA 94035 uucp: {ihnp4,hplabs,ucbvax}!ames!prandtl!hender
"This place isn't big enought for all of us, we got to find a way off this
planet."
======================================
End of summaries.
An anonymous submitter suggested I contact Lachman Associates about
an NFS Server implementation (no client capability) in source form.
SUN is working on a new protocol (Version 3) which may impact the current
development of NFS implementations. Also, SUN is coming out with a VME
board that plugs their workstations into an IBM data channel (FIPS-60).
--
Alan Klietz
Minnesota Supercomputer Center (*)
1200 Washington Avenue South
Minneapolis, MN 55415 UUCP: ..rutgers!meccts!mn-at1!alan
Ph: +1 612 626 1836 ..ihnp4!dicome!mn-at1!alan (beware ihnp4)
ARPA: alan@uc.msc.umn.edu (was umn-rei-uc.arpa)
(*) An affiliate of the University of Minnesotamre@laidbak.UUCP (Mike Eisler) (09/19/87)
In article <392@mn-at1.UUCP> alan@mn-at1.UUCP (Alan Klietz) writes:
%From: umn-cs!rutgers!gatech!emory!arnold (Arnold D. Robbins {EUCC})
%
%A System V version of a user mode
%NFS server is available from Lachman Associates.
%
....
%An anonymous submitter suggested I contact Lachman Associates about
%an NFS Server implementation (no client capability) in source form.
The implication is that LAI does not have a kernel implementation
of a NFS client and server available. This is not true. A full NFS reference
port for System V.[23] has been available for over a year.
-Mike Eisler
{sun, ihnp4}!laidbak!mre