masscomp-request@soma.bcm.tmc.edu (Stan Barber) (10/26/87)
Some of this information is not confirmed. Masscomp is encouraged to respond with authoratative information. 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. 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. Projected release of NFS (which will be a seperate product from the SP-70 product [which is also required]) will be about March. RTU 4.0 may be required to run NFS as well.
stevo@jane.Jpl.Nasa.Gov (Steve Groom) (11/02/87)
In article <3243@soma.bcm.tmc.edu> masscomp-request@soma.bcm.tmc.edu (Stan Barber) writes: >... >Projected release of NFS (which will be a seperate product from the >SP-70 product [which is also required]) will be about March. > >RTU 4.0 may be required to run NFS as well. I have before me the "Software Product Bulletin" for MASSCOMP NFS V1.0, dated October 1987. I quote: "Minimum Hardware Required: A valid MC5nnn system configuration with - 4.0 MB memory - 71 MB mass storage - Ethernet controller. The Ethernet controller is integral with 53/54/5520/5550 systems. All other systems require one of the following: - Co-processor Ethernet implementation - MN807 - In-kernel implementation using the Ethernet option as a link-level controller - MN806 or later. "Prerequisite Software: - MASSCOMP's RTU (Real-Time Enhanced UNIX) 5000 operating system, version 4.0 or later ^^^^^^^^^^^^^^^^^^^^ - SP70 Ethernet software V2.2 or later (included with RTU for 53/54/5520/5550 systems). In the "Product Specifications" for RTU V4.0 (also dated October 1987), the Optional Software list includes "RTU-NFS Network File System." I know for a fact (well, our salesman told me, I guess that's a fact) that NFS will not be included in either SP70 or RTU 4.0, but will be an optional package available for about $1000, which as I understand is mostly to cover the fees that MASSCOMP pays to to license NFS from Sun (Microsystems, Inc.). As for the time frame for the actual availability of NFS and RTU 4.0, I know only that both are just now beginning beta testing. /* Steve Groom, Jet Propulsion Laboratory, Pasadena, CA 91109 * ARPA: stevo@elroy.jpl.nasa.gov UUCP: ..!cit-vax!elroy!stevo * Disclaimer: (thick German accent) "I know noothingg! Noothingg!" */ [Thanks for the informaiton! -- sob]
david@elroy.jpl.nasa.gov (David Robinson) (11/02/87)
As someone who has done a lot of work with NFS on a wide variety of machines I am somewhat confused on Masscomp's statements. I too heard what Stan indicated from Masscomp when they talked to JPL about being a beta site for 4.0. The claim was that for NFS to work you needed to have the EXOS 301 board, which just 2 months ago they said they were still evaluating it. 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 you could not run it with a 201 or with a 68000/10. My understanding is that the 301 is identical with the 201 except faster, a Masscomp techie even told me when they first got one for testing the plugged it in and it worked. This may mean that NFS will be slow on the 201/68010 systems but that should not make it unusable. I have ran NFS on systems that during debugging phases would take *seconds* to respond to some requests and with a properly configured client it worked perfectly. The two major trouble points tend to be a machine not responding fast enough for a client which usually is configurable via "timeo" to a higher value, and a server not accepting 8K of UDP packets back to back which can be tuned via shrinking the read and write sizes. 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. -David P.S. The 201 boards are horribly slow, a 68010 with in kernel TCP/IP is considerably faster than a 201 board. -- David Robinson elroy!david@csvax.caltech.edu ARPA david@elroy.jpl.nasa.gov ames!elroy!david UUCP Disclaimer: No one listens to me anyway!
alan@masscomp.UUCP (Alan Atlas) (11/02/87)
[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]
alan@masscomp.UUCP (Alan Atlas) (11/11/87)
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
mike@devvax.jpl.nasa.gov (Mike Tankenson) (11/13/87)
david@elroy (David Robinson) writes... > >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 > What about a 5500 (68010 cpu) with 4 MB memory, running TCP/IP in kernel mode? I believe that the 301 has 1/2 MB of memory, so for my system, the 68010 should suffice, no? *If* there is a problem with running RT-NFS in kernel mode, then I'm sure that the beta testers will find this out. Generally, people should be given a wide variety of choices (price/performance), and although I don't think MC will be selling many more 68010 machines, those customers with the older boxes would *still* like NFS (at a reasonable price). --mike Mike Tankenson Telos/Jet Propulsion Laboratory - NASA 4800 Oak Grove Drive, Pasadena, CA. 91109 (818) 354-1447 Uucp: seismo!cit-vax!jplpro!mike Arpa: jplpro!mike@cit-vax.ARPA -or- mike@jplpro.JPL.NASA.GOV