Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!hellgate.utah.edu!cs.utexas.edu!uunet!mcsun!ukc!mucs!els!dente
From: dente@els.uucp (Colin Dente)
Newsgroups: comp.sys.apollo
Subject: Re: Apollo NFS V2.0
Message-ID: <292@m1.cs.man.ac.uk>
Date: 23 Oct 89 17:40:42 GMT
References: <7847@charlie.OZ> <238@ticipa.ti.com> <758@idacom.UUCP>
Sender: news@cs.man.ac.uk
Reply-To: dente@els.ee.man.ac.uk (Colin Dente)
Organization: University of Manchester, UK
Lines: 63

In article <758@idacom.UUCP> danny@idacom.UUCP (Danny Wilson) writes:
>
>[Description of NFS set up at IDACOM]
>
>            node A      /O\  nfsd, mountd        Node A and B are
>                       /   \                     DN3000's with 4Mb RAM
>                       |    |   Token Ring
>                       \    /         
>            node B      \O/         
>                         |          Ethernet
>            -------------+-----------------------------             
>                                      
>To realize this, we run the NFS servers on a node one the ring _different_
>from the gateway node to the Ethernet (which connects to some Suns and a
>Vax)
>
>However, it we always get timeouts when trying to access DOMAIN files
>from one of the Suns.  I could guess that the nfsd gets paged out when
>there is no activity (after you _do_ get into the directory, the response
>time seems normal). We have changed the mount command so that
>there are lots retries etc.
>
>Has anyone configured like this and did it work?

Sorry for the big quote - but it all seems relevant.

We have a similar configuration - except we are running the NFS stuff
on the gateway node (DN3010, 4Mb, 10.1) (+ we have a few more nodes on
the token ring), and response is *AWFUL*.  Accessing domain files from
a Sun on the same piece of ethernet as the Apollo will often result in
many timeouts - (that is, the Sun says 'NFS server <apollo's name> not
responding' followed a few seconds later by 'NFS server <apollo> OK'.
Typically, you might expect 20 timeouts when shifting 5Mbytes of data
across via NFS.

In another building, I have a very similar setup, but with a DN590-T
(12Mb, ETH802.3_VME interface, 10.1) as the gateway - this behaves
similarly, except the NFS server on that often goes away for ever
(well, until I get bored - i.e. >1 hour).

In both cases the ethernet is very lightly used - peak load is about
10%, average 2-3%.

I'm told that you have to patch the ethernet8_microcode on pre SR10.2
releases of the OS, but surely this only applies to the AT bus
machines? or am I wrong there? - anyway - I'm waiting for the relevant
patch.

As a matter of interest, I had exactly the same situation with NFS
V1.0 running on a DSP80A (3Mb, SR9.7.1, COM-ECMB) - I just put it down
to crap hardware - seems I was unfairly demeaning the poor little
bugger.

Has anyone found these problems?
- or a cure?
- will patching the ethernet8_microcode solve my troubles?
- will we all live happily ever after?
- help????!!!!

 Colin Dente                      | JANET: dente@uk.ac.man.ee.els
 Dept. of Electrical Engineering  | ARPA:  dente@els.ee.man.ac.uk 
 University of Manchester         | UUCP:  ...!mcvax!ukc!man.ee.els!dente 
 England                          | These might work now, but then again...