Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!nrl-cmf!ames!ptsfa!hoptoad!academ!uhnix1!soma!masscomp-request
From: alan@masscomp.UUCP (Alan Atlas)
Newsgroups: comp.sys.masscomp
Subject: Re: Random data about the upcoming NFS release
Message-ID: <3252@soma.bcm.tmc.edu>
Date: Mon, 2-Nov-87 10:39:06 EST
Article-I.D.: soma.3252
Posted: Mon Nov  2 10:39:06 1987
Date-Received: Tue, 10-Nov-87 04:53:29 EST
References: <3243@soma.bcm.tmc.edu>
Sender: masscomp@soma.bcm.tmc.edu
Reply-To: alan@masscomp.UUCP (Alan Atlas)
Organization: MASSCOMP - Westford, Ma
Lines: 59
Approved: masscomp@soma.bcm.tmc.edu

[This is a response from the Supervisor of OS Development at Masscomp.
In advance, I appreciate Alan taking the time to respond. -- sob]

In article <3243@soma.bcm.tmc.edu> masscomp-request@soma.bcm.tmc.edu (Stan Barber) writes:
>
>It has been brought to my attention that performance problems may make
>NFS impossible to run on systems that have do not have the 68020 CPU.

Not true. I am currently running NFS on a 5500 with a 201 controller
and it works fine.

>Basically, the combination of the EXOS 201 controller and the 68000/68010
>cpu do not have enough performance to support NFS. The 68020 product with
>the integral controllers will work fine. Those systems that have a 68020 and
>the EXOS 301 controller [Does Masscomp sell these?] will also work. The
>68020 with the EXOS201 is said to work as well, although the rumblings are
>there that indicate this is only true of the EXOS201 is run as a link-level
>controller with in-kernel protocols.

Whoever rumbled to you got a confused combination of rumors and half-truths.
The whole truth (as far as I know it) is that we were wary of NFS performance
with the 201 based on our experience with EFS (ahh, memories).  Our plan
was to investigate that and to deal with whatever we found to be
the case.  It has turned out that for everyday, light use the 201
is satisfactory.  I do not know what the final recommended/required
hardware configurations will be. We haven't had a chance yet to see how well
it will work with a heavy load on NFS.  On the 020 machines, either
link-level or coprocessor mode will provide acceptable performance.
>
>Projected release of NFS (which will be a seperate product from the
>SP-70 product [which is also required]) will be about March.

PROJECTED  (<==italics) release of NFS (and RTU 4.0) in March is correct.
>
>RTU 4.0 may be required to run NFS as well.

Packaging decisions concerning all software products are made based on
marketing and business concerns.  The decision to unbundle NFS was one
of those.  Engineering  originally wanted to keep it bundled with RTU, but
that didn't happen. Since  we had to make large changes to the filesystem
and libraries, RTU 4.0 will be required for NFS. SP-70 will also be
required since Ethernet access is of course required.

For those of you who missed our recent product announcements, I can
also say that besides NFS, RTU 4.0 will be supporting a guaranteed
realtime AST dispatch latency in the 6 to 10 msec. range 
on multiprocessor machines regardless of other activity on the system.  
There will be a required hardware environment and some other specified
conditions, but the guarantee will hold and it will be useful.

Also, RTU 4.0 will pass SVVS for the base kernel, kernel extensions, and
libraries.


Alan Atlas
Supervisor, OS Development

[As a side note, comp.sys.masscomp is most willing to place versions
of the product annoucements here. Someone needs to send them to me. -- sob]