Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!uwvax!oddjob!gargoyle!ihnp4!homxb!mtuxo!mtune!codas!killer!academ!soma!masscomp-request
From: alan@masscomp.UUCP (Alan Atlas)
Newsgroups: comp.sys.masscomp
Subject: Re: Random data about the upcoming NFS release
Message-ID: <3257@soma.bcm.tmc.edu>
Date: Tue, 10-Nov-87 16:36:54 EST
Article-I.D.: soma.3257
Posted: Tue Nov 10 16:36:54 1987
Date-Received: Tue, 17-Nov-87 06:47:41 EST
References: <3243@soma.bcm.tmc.edu> <3251@soma.bcm.tmc.edu>
Sender: masscomp@soma.bcm.tmc.edu
Reply-To: alan@masscomp.UUCP (Alan Atlas)
Followup-To: RTU 4.0 and NFS
Organization: MASSCOMP - Westford, Ma
Lines: 27
Approved: masscomp@soma.bcm.tmc.edu


In article <3251@soma.bcm.tmc.edu> david@elroy.jpl.nasa.gov (David Robinson) writes:
>
>Given the nature of NFS and the fact that almost all of the client
>NFS code has tunable parameters I can see no logical reason why
>My >understanding is that the 301 is identical with the 201 except
>faster [...]
>
Actually and more importantly, the 301 has a lot more memory on it
than the 201.
>
>My personal theory is that Masscomp thinks people will only
>except fast NFS systems or they want to sell a bunch of
>301 boards.  If you can live with slower performence then you
>might not need to buy a 301.
>
We, like Sun, believe that most people will not like NFS if it is slow.
However, the real problem is that we are able to deadlock a 201 board with NFS.
The limited memory space makes it easy to exhaust the mbuf supply.  
Unfortunately, it is not easy to define some number of clients or any 
other simple criterion customers could use to avoid the deadlock
in all cases.  Yes, the 301 is faster, but more
importantly it has enough memory to handle NFS traffic loads.
>

Alan Atlas
Supervisor, OS Development