HDTenEightyP/NetNews huggingface dataset:
From: uqecd08@ucl.ac.uk (John Thomas)
Newsgroups: comp.protocols.nfs
Subject: NIS server is not main nameserver - problem with PC-NFS
Date: 30 Jul 92 15:51:29 GMT
Organization: Bloomsbury Computing Consortium

I have a setup where our NIS server is a local AIX server, but the main
nameserver is a different machine. On our server, /etc/resolv.conf
points to ts (the nameserver) and most Internet names are resolved in
this way. 

However PC-NFS is told that the NIS server is our local
machine, and NIS or PC-NFS do not seem able to make the jump necessary to get
the names for PCs from ts.

Is there a way round this?
--
|   v___v    | John Thomas, Programmer         e-mail: J.Thomas@ucl.ac.uk     |
|  / o-o \   | LEPRA Evaluation Project        Tel: 011 44 71 927 2217        |
|  \__Y__/   | London School of Hygiene & Trop. Med.                          |
| ( ~ ~ ~ )  | Keppel St, London WC1E 7HT, England                            |
Xref: sparky comp.protocols.nfs:1920 comp.sys.sun.hardware:3475
From: gt1111a@prism.gatech.EDU (Vincent Fox)
Newsgroups: comp.protocols.nfs,comp.sys.sun.hardware
Subject: Re: NFS I/O Ops/seconds
Date: 22 Jul 92 14:45:26 GMT
Followup-To: comp.protocols.nfs
Distribution: usa
Organization: Georgia Institute of Technology

In <1992Jul22.061146.15641@u.washington.edu> kint@rio.engr.washington.edu (Rick Kint) writes:
>	We're buying a Sun to serve as an NFS server in one of our departments.
>The Sun rep commented that a typical Ethernet allows 300 NFS ops per second,
>so if you're on a single wire any server bandwidth beyond that is wasted. 

>	I have no feel whatsoever for the numbers that go into this figure,
>can anyone in netland (a) explain this in words of two syllables or less, and
>(b) does anyone know the figures for current systems?

Hmmm. I'm a bit skeptical. All NFS operations are not created equal.
A write obviously takes a lot longer to complete than a getattr. I've seen
claims up to 1,000 or better. Auspex claims this I feel certain.

>	I'm sure that this includes assumptions about what represents a 
>typical mix of operations; since a getattr is presumably quicker than a write
>(for example), how useful are these numbers anyway?

Not much. Sun reps usually know less than you do.

>	ObCurmudgeonlyRemark:  I was reading about the SS10/41, with 1 MB of
>cache.  Good Lord, a meg of cache on a workstation, why when I was your age
>we thought a meg of *main memory* on a *mainframe* was a lot...

I remember when we had teletypes with 300 baud acoustic modems, and
we *liked it that way*! 

There's not much you can do to accelerate Sun's NFS on the read-side,
but you can speed up writes quite a bit. We use the PrestoServe
board, which buffers up NFS writes and reduces the response-time
between concsecutive write operations. InterStream's eNFS software
also replaces the nfsd's with enfsd's and does better scheduling.
If you are doing more than 7-10% writes (do an nfsstat -s), you can
really speed things up. You also will want to increase your clients
to more than just the default 4 biod's to take advantage of the
faster server. InterStream was sending out evaluation copies for
free last I head. The try-out license number lasts about a month
I think if you want to evaluate it on-site before purchase. Comes
with benchmarking software to determine optimum configuration.

Prior to adding these two things, I might get 100-200K/sec write
performance on moderate-size (512K-1meg) files, now it's more like
400-500K/sec. This with a Sparc II and the built-in SCSI controller.
I'm sure with a better boxen and maybe an NC4000 ethernet board, you
could push things a bit faster.

-- 
The War on Drugs is just a part of the War on the US Constitution. 
Newsgroups: comp.protocols.nfs
From: leeh7@fel.tno.nl (E.w.a. van Leeuwen)
Subject: PC-NFS login on startup
Organization: TNO Physics and Electronics Laboratory
Date: Tue, 21 Jul 92 06:31:15 GMT

Dear reader,

We are using PC-NFS 4.0 on our systems just
recently. It gives the possibility to
login and logout while running Windows.
However, we have not figured out how
to get the login window just after
Windows has started.

We have tried using the Recorder, but
with little success.
As the login screen is part of the
Control Panel, I think it is not
possible to load the login screen
as a program with the "run" command.

Any ideas?

Thanks in advance.



						Regards,
						
						Ed.

						
===============================================================================
Ed van Leeuwen                        |  Ed W.A. van Leeuwen
FEL-TNO                               |  TNO Physics and Electronics Laboratory
's-Gravenhage                         |  The Hague, the Netherlands
-------------------------------------------------------------------------------
Ed.van.Leeuwen@tnofel.fel.tno.nl      |  WARNING: Do not feed the lions
===============================================================================

Newsgroups: comp.protocols.nfs
From: uresh@ovrbid.lkg.dec.com (Uresh Vahalia)
Subject: Re: NFS Internal sources 
Organization: Digital Equipment Corp.
Date: Tue, 21 Jul 1992 16:49:37 GMT

The following two documents provide a very thorough discussion of nfs
implementation.


1.  NFS Protocol Specification (RFC 1094)
2.  Russel Sandberg, et al., "Design and Implementation of the Sun
Network Filesystem",
    Proceedings of the Summer 1985 USENIX Conference, pages 119-130.

They provide as much detail about "internals" as any other source I have seen.


Uresh Vahalia
Newsgroups: comp.protocols.nfs
From: cwm@beta.lanl.gov (Christina W Mercier)
Subject: Re: NFS I/O Ops/seconds
Organization: Los Alamos National Laboratory
Date: Thu, 23 Jul 1992 19:22:03 GMT

In article <nkok0p0@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>In article <l6r4uvINNf0p@exodus.Eng.Sun.COM>, beepy@tabitha.Eng.Sun.COM (Brian Pawlowski) writes:
>> ...
>>
>> The number "300 NFS ops/s per ether" is a rule-of-thumb
>> ...
>
>
>Vernon Schryver,   vjs@sgi.com
> writes:
>Yes, everyone keeps saying, for ethernet.
>One can hope to do significantly better on FDDI.
>

So does anyone have a start at a rule-of-thumb for FDDI????
Any results of default-mix NHFSSTONE benchmarks on FDDI would be 
  appreciated.

Christina Mercier
cwm@lanl.gov

Newsgroups: comp.protocols.nfs
From: cohen@lindsay.psychiatry.uiowa.edu
Subject: PCNFS to A/UX
Date: Fri, 31 Jul 1992 15:02:16 GMT
Organization: University of Iowa

Sorry if this is a repost.

I was wondering if anyone had ported PC-NFS to A/UX (gasp!)

We would be much happier if we could use a mac for these services instead
of one of our other workstations, for 'perceived' security reasons.

Thanks
gc
 
Newsgroups: comp.protocols.nfs
From: rod@philips.oz.au (Rod Roberts)
Date: Thu, 30 Jul 92 02:16:33 GMT
Organization: Philips Public Telecommunications Systems, Melbourne, Australia
Subject: what locking techniques work over NFS?
Summary: what locking techniques work over NFS?
Keywords: file locking

Firstly my apologies if this is a repeated posting. I'm not sure if
the first one got out. There were some bad typos in it anyway!

Yes, I know, this has probably been asked before. If this question is
covered by an FAQ could some kind soul send it to me, as I am _not_ a
regular subscriber to this news group.

My question is basically this. which of the following file locking
techniques work with multiple hosts accessing the same filesystem over
NFS.

1. lockf()  (System V)
2. flock()  (BSD)
3. link()   (generic) fails if new link already exists
4. create() (generic) fails if file exists and caller does no have write
             permission
5. open()   (POSIX) fails if O_CREAT and O_EXCL flags are present an the file
             exists.

My own suspicion is that methods 3 and 4 will work but not the others
with the exception of 5 (maybe). Thanx in advance to anybody who can
help me on this.

														Rod
-- 
Rod Roberts
e-mail: rod@philips.oz.au | Phone: +61 (3) 881 3574 | Fax: +61 (3) 881 3577
Philips Public Telecommunications Systems
23 Lakeside Drive, Burwood East 3151, Melbourne, Victoria, AUSTRALIA
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.protocols.nfs
Subject: Re: NFS I/O Ops/seconds
Date: 22 Jul 92 18:02:14 GMT
Distribution: usa
Organization: Auspex Systems, Santa Clara

>I've seen
>claims up to 1,000 or better. Auspex claims this I feel certain.

I think we do, but I sure don't think we claim that on *one* net....
From: boyera@anne.inria.fr (Stephane Boyera)
Newsgroups: comp.protocols.nfs
Subject: nfs-client
Date: 31 Jul 92 13:20:03 GMT
Reply-To: Stephane.Boyera@crazy.inria.fr
Organization: INRIA/CERMICS Sophia-Antipolis

Hello,

I'm writing a nfs-client driver for macintosh. When i want to access a
private file (read/write denied fo other) i need to fill the fields auth_unix
and cred_unix in the rpc packet. Which protocol will do that ? (e.g enter the
user name and password and get these fields)

thanks

Steph.

E-mail : boyera@sophia.inria.fr
Newsgroups: comp.protocols.nfs
From: beame@maccs.dcss.mcmaster.ca (Carl Beame)
Subject: Re: PC-NFS Speed Limitations
Organization: McMaster University, Hamilton, Ontario, Canada.
Date: Wed, 29 Jul 1992 01:29:15 GMT

In article <13618@gazette.bcm.tmc.edu> tso@cephalo.neusc.bcm.tmc.edu (Dan T'so) writes:
>In article <1992Jul20.215338.6050@sal.wisc.edu> rej@larry.sal.wisc.edu (Randy Jones) writes:
>>I am using the PC-NFS implementation of TCP to transfer data to Vaxen.
>>And I'm unable to answer this question: why is it so slow?
>
>	I also have timed PC-NFS on 486/33's and it is 3-10 times slower than
>the identical operation (reading a 1Mb file thru NFS) running on a MVAX, a
>CPU that is 10 times slower than the 486. So what gives ? The Ethernet card on
>the PC is a 3Com 503. It is an 8-bit card. I talked to SUN when I first bought
>the card and they said that they saw very little difference in performanace
>under PC-NFS when using either the 8-bit or 16-bit cards.
>	So what is the highest performance configuration one can setup for a
>PC accessing NFS hosts ? Are there better Ethernet cards that will *definitely*
>under PC-NFS yield 2X or better improvement ? Are there better PC-NFS
>implementations that will yield 2X or better improvements ? Not looking for
>10-20% improvements. Why is PC-NFS 3-10 times worse than a much slower CPU
>running UNIX ? If I run OS/2 or UNIX/Xenix on the PC, will its NFS performance
>improve significantly ?
>	Thanks.
>				Cheers,
>				Dan Ts'o		212-327-7671
>				Dept. Neurobiology	dan@rna.rockefeller.edu
>				Rockefeller Univ.	...s5!rna!dan
>				1230 York Ave.		tso@rockvax.bitnet
>				NY, NY 10021

	Basically the performance of a read by PC-NFS versus any other NFS, is
based on the fact that PC-NFS only makes a single ~1K read request at a time,
while other NFSes can read up to 8K in a single request. Other PC based NFSes 
(BW-NFS and ???) can do a read request of upto 8K. You should note that the 
3C503 card can only be set to read ~4K since it has limited buffer ( 8K - 2K
transmit 6K receive). Runing OS/2 or UNIX/Xenix may improve the performance 
over PC-NFS, but it still has the problem that the ethernet cards have very 
limited buffer space. When connecting to our SCO box with a WD8003 card, we
have to set the write size to 2048, since multiple people are trying to write
at a time and sending 4K from two stations cause the SCO box to drop too many
packets.

Carl Beame
Beame & Whiteside Software Ltd.

P.S: I don't know which other PC based NFS clients uses > 1 ethernet packet read
     sizes. I known Interdrive can read up to the maximum segment size of the 
     network.
From: mreilly@envrgis.sps (mike reilly)
Newsgroups: comp.protocols.nfs
Subject: PCNFS Lifeline Backup -w- EXABYTE
Date: 24 Jul 92 21:01:12 GMT
Distribution: comp.protocols.nfs
Organization: New Mexico State University, Department of Computer Science


I am able to use rput to backup my pc over the network onto 0.25" tape
but, when I use to use the EXABYTE, no workin. Perhaps someone who has
more extensive documentation on pcnfs rput could lend a hand here.
I believe perhaps it has a built-in timeout and the setuptime with
the exabyte (sun 811) mayb too long??

michael
mreilly@psl.nmsu.edu
From: fitzgb@mml0.meche.rpi.edu (Brian Fitzgerald)
Newsgroups: comp.protocols.nfs
Subject: can't reach many internet hosts because pcnfs ip time-to-live too small
Date: 31 Jul 92 14:20:10 GMT
Organization: Rensselaer Polytechnic Institute, Troy, NY

pcnfs 3.0

I used to be able to connect with ftp directly from my pc to
wuarchive.wustl.edu.  Also. I used to be able to mount the archive as a
virtual drive with pcnfs (a win).  Now it seems this will no longer be
possible, due a change in the internet arrangement.

All my pcnfs software generates ip packets with a time to live of 15,
but now wuarchive is 17 hops away, so I get ICMP "time exceeded"
packets back from the 15th gateway, and I never reach wuarchive.

Is the time to live set higher in a later release of pcnfs?

Is it true that there is no way I can adjust the ttl?

Maybe do a binary patch of some driver (pcnfs.sys?).

Brian

traceroute to wuarchive.wustl.edu (128.252.135.4), 30 hops max, 38 byte packets
 1  jec.gw.its.rpi.edu (128.113.14.254)  0 ms  0 ms  0 ms
 2  vccfr1.its.rpi.edu (128.113.100.250)  20 ms  0 ms  0 ms
 3  nyser1-gw.rpi.edu (128.113.1.1)  20 ms  0 ms  0 ms
 4  rpi.albany.pop.psi.net (38.145.34.1)  20 ms  0 ms  0 ms
 5  38.145.20.1 (38.145.20.1)  0 ms  0 ms  20 ms
 6  syr.cornell.site.psi.net (38.145.10.2)  20 ms  20 ms  20 ms
 7  ENSS.TN.CORNELL.EDU (192.35.82.101)  20 ms  0 ms  20 ms
 8  t3-1.cnss49.t3.nsf.net (140.222.49.2)  20 ms  20 ms  20 ms
 9  t3-3.cnss48.t3.nsf.net (140.222.48.4)  20 ms  20 ms  20 ms
10  t3-1.cnss72.t3.nsf.net (140.222.72.2)  40 ms  40 ms  60 ms
11  t3-2.cnss64.t3.nsf.net (140.222.64.3)  80 ms  80 ms  80 ms
12  t3-0.cnss80.t3.nsf.net (140.222.80.1)  80 ms  80 ms  80 ms
13  t3-0.cnss81.t3.nsf.net (140.222.81.1)  100 ms  100 ms  100 ms
14  t3-0.enss140.t3.nsf.net (140.222.140.1)  120 ms  100 ms  100 ms
15  mid-3.hub.mid.net (192.35.171.4)  100 ms  100 ms  100 ms
16  Washington-Univ.gw.mid.net (128.242.60.1)  220 ms  120 ms  120 ms
17  wuarchive.wustl.edu (128.252.135.4)  100 ms  140 ms  120 ms


 0.17 UDP from mml1.meche.rpi.edu.1501 to wuarchive.wustl.edu.sunrpc  64 bytes
 RPC Call portmapper  PMAPPROC_GETPORT  V2 [2b787594]
 00 00 0c 01 44 78 02 60 8c 99 62 55 08 00 45 00
 00 54 00 00 00 00 0f 11 15 13 80 71 0e 15 80 fc
                   ^^ --------------------------------- ttl = 15
 87 04 05 dd 00 6f 00 40 00 00 2b 78 75 94 00 00
 00 00 00 00 00 02 00 01 86 a0 00 00 00 02 00 00
 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 01 86 a5 00 00 00 01 00 00 00 11 00 00
 00 00 e6 d7 00 00 05 f2 00 00

 0.27 ICMP from mid-3.hub.mid.net to mml1.meche.rpi.edu time exceeded
  bad packet: UDP from mml1.meche.rpi.edu.1501 to wuarchive.wustl.edu.sunrpc  64 bytes
 02 60 8c 99 62 55 00 00 0c 01 44 78 08 00 45 00
 00 38 00 00 00 00 f1 01 d0 16 c0 23 ab 04 80 71
 0e 15 0b 00 ef 73 00 00 00 00 45 00 00 54 00 00
 00 00 00 11 23 13 80 71 0e 15 80 fc 87 04 05 dd
 00 6f 00 40 00 00 ad 61 00 00 00 b2 00 00
From: tso@cephalo.neusc.bcm.tmc.edu (Dan T'so)
Newsgroups: comp.protocols.nfs
Subject: Re: PC-NFS Speed Limitations
Date: 28 Jul 1992 02:17:18 GMT
Organization: Baylor College of Medicine, Houston,Tx

In article <1992Jul20.215338.6050@sal.wisc.edu> rej@larry.sal.wisc.edu (Randy Jones) writes:
>I am using the PC-NFS implementation of TCP to transfer data to Vaxen.
>And I'm unable to answer this question: why is it so slow?

	I also have timed PC-NFS on 486/33's and it is 3-10 times slower than
the identical operation (reading a 1Mb file thru NFS) running on a MVAX, a
CPU that is 10 times slower than the 486. So what gives ? The Ethernet card on
the PC is a 3Com 503. It is an 8-bit card. I talked to SUN when I first bought
the card and they said that they saw very little difference in performanace
under PC-NFS when using either the 8-bit or 16-bit cards.
	So what is the highest performance configuration one can setup for a
PC accessing NFS hosts ? Are there better Ethernet cards that will *definitely*
under PC-NFS yield 2X or better improvement ? Are there better PC-NFS
implementations that will yield 2X or better improvements ? Not looking for
10-20% improvements. Why is PC-NFS 3-10 times worse than a much slower CPU
running UNIX ? If I run OS/2 or UNIX/Xenix on the PC, will its NFS performance
improve significantly ?
	Thanks.
				Cheers,
				Dan Ts'o		212-327-7671
				Dept. Neurobiology	dan@rna.rockefeller.edu
				Rockefeller Univ.	...s5!rna!dan
				1230 York Ave.		tso@rockvax.bitnet
				NY, NY 10021
From: geoff@tyger.Eng.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top)
Newsgroups: comp.protocols.nfs
Subject: Re: lockd
Date: 21 Jul 1992 19:46:10 GMT
Organization: SunSelect
NNTP-Posting-Host: tyger.east.sun.com

Quoth uresh@ovrbid.lkg.dec.com (Uresh Vahalia) (in <1992Jul21.174721.26888@nntpd.lkg.dec.com>):
#
#I have a few questions about the lockd protocol, which I am trying to
#implement:
#
#1.  There seem to be 3 flavors of each request - eg. for the lock
#request, there is 
#    nlm_lock, nlm_lock_msg and nlm_lock_res.  Why?  What are the differences?

nlm_lock is synchronous: the client requests the lock, and the
server replies with a definitive "granted" or "failed" response.

nlm_lock_msg and nlm_lock_res implement a call-back model. The client
requests the lock with nlm_lock_msg. This RPC is ack'ed at once. The
server then makes an nlm_lock_res call-back to the client indicating
either that the lock has been granted or that the request is being
processed. In the latter case, the server will eventually respond by
making an nlm_granted RPC to the client.

Why? Because back in 1986 it wasn't practical to create a multithreaded
lock manager.

#2.  What are the version 3 requests for (share, unshare, nm_lock and free_all?)

share, unshare:    DOS-compatible file sharing by PC clients.
nm_lock, free_all: locking support for PCs which couldn't run status monitors.
(Disclaimer: I'm the author of these.)

#3.  What is the function of the cookie argument in all the calls?

It allows the lock manager to match up corresponding asynchronous
requests and callbacks.

#4.  What does the svid argument mean?

In the X/Open spec it was renamed "uppid - unique per-process ID". Think
"pid".

#Can anyone point me to any document which gives me a high level description of
#the protocol (besides just the uncommented spec?).

There's only one good description:

X/Open CAE Specifications: Protocols for X/O Interworking - XNFS.
                         (ISBN 1 872630 10 3. Doc No. XO/CAE/91/030.)

This document is available directly from the X/Open Company. As the time of
writing, the phone numbers were:
   USA:    +1(415)323 7992 or +1(703)876 0044
   Europe: +44 734 508311
   Japan:  +81 3 3251 8321

--
---------------------------------------+--------------------------------------
     Geoff Arnold, PC-NFS architect    | Thought for the day: If Unix had been
      (geoff.arnold@East.Sun.COM)      | developed in England, we'd all be using
SunSelect, a Sun Microsystems Business | BCPL (and migrating to BCPL++)...
From: jim@cs.strath.ac.uk (Jim Reid)
Newsgroups: comp.protocols.nfs
Subject: Re: NFS I/O Ops/seconds
Date: 27 Jul 92 11:21:41 GMT
	<noe56po@rhyolite.wpd.sgi.com>
Organization: Computer Science Dept., Strathclyde Univ., Glasgow, Scotland.
In-reply-to: vjs@rhyolite.wpd.sgi.com's message of 25 Jul 92 19:26:05 GMT

In article <noe56po@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:

   An NFS server or client on FDDI is intrinsically faster than a similar
   machine over ethernet.  This is because it takes significantly fewer
   host cycles to generate 1 or 2 UDP/IP datagrams for a 4K or 8K read or
   write than to generate 3 or 6.  

Yes, but..... 

4K or 8K reads and writes tend not to be the most commonly used NFS
operations. Typically, 70-80% of the NFS requests will be lookups and
getattrs. These generate itty-bitty packets - 2-300 bytes or so -
which will fit quite comfortably in the maximum packet "frame" for
just about any network. Therefore, fragmentation of NFS requests is No
Big Deal.

While what you say is true, the benefits of lower protocol processing
are negligible. This maybe saves 1000 instructions or so (a whole 30
microseconds of CPU on the average workstation these days) for perhaps
20% of the server's NFS operations. I suspect that this will be lost
in the noise when compared with the CPU overhead of actually servicing
the NFS request and/or waiting for the disk.

		Jim
From: raj@cup.hp.com (Rick Jones)
Subject: Re: NFS I/O Ops/seconds
Date: Mon, 27 Jul 1992 20:35:52 GMT
Organization: The Place Where Packets Go To Die
X-Newsreader: Tin 1.1 PL4

On the topic of saving 1000 instructions here or there, I would say that the
number of instructions for an individual request on the surface doesn't
look like much, but if you are talking about a big NFS server, it could
gain you several score IOP/s.

Saving trips up and down the protocl stack is a "good thing." If you can get
there in a way that assists in data movement in the host is an "even better
thing."

8KB in the cache that doesn't need to be there is a bad thing. Even if you
have caches that are bigger than the core memories of most machines from
10 years ago.

Waste is still waste, even in the face of plenty.

rick jones

Xref: sparky comp.protocols.nfs:1927 comp.sys.sun.hardware:3489
From: rmilner@zia.aoc.nrao.edu (Ruth Milner)
Newsgroups: comp.protocols.nfs,comp.sys.sun.hardware
Subject: Re: NFS I/O Ops/seconds
Date: 22 Jul 92 18:45:47 GMT
Article-I.D.: zia.1992Jul22.184547.759
Reply-To: rmilner@zia.aoc.nrao.edu (Ruth Milner)
Organization: National Radio Astronomy Observatory, Socorro NM

In article <1992Jul22.122659.22219@afterlife.ncsc.mil> dpkemp@afterlife.ncsc.mil (David P. Kemp) writes:
>In article <1992Jul22.061146.15641@u.washington.edu> kint@rio.engr.washington.edu (Rick Kint) writes:
>>
>>	We're buying a Sun to serve as an NFS server in one of our departments.
>>The Sun rep commented that a typical Ethernet allows 300 NFS ops per second,
>>so if you're on a single wire any server bandwidth beyond that is wasted. 

>  Ethernet = 10 Mbit/sec
>       /8  = 1.25 Mbyte/sec
>    /8192  = 152 Read or Write ops/sec.
>
>I guess the Sun guy must have been using a mix that wasn't too heavily
>into reads or writes! :-).

Like most people.  If you check your server with "nfsstat -s", you'll find 
that the majority of NFS requests are things like getattr and lookup, which 
do not need 8KB (only traffic containing actual disk data is that size). On 
our Auspex, these two operations alone account for 50% of all NFS requests. 
Reads are 17% and writes 19% of the mix.

Using etherfind, I see the following sorts of things:

client2% etherfind -i le0 -src server
                                            icmp type
 lnth proto         source     destination   src port   dst port

  138  udp          server       client1       2049       1019
  138  udp          server       client1       2049       1019
  138  udp          server       client2       2049       1021
  138  udp          server       client2       2049       1021
  138  udp          server       client2       2049       1021
  138  udp          server       client2       2049       1021
  138  udp          server       client3       2049       1020
  138  udp          server       client4       2049       1019
   86  udp          server       client4       2049       1019
  138  udp          server       client4       2049       1019
  170  udp          server       client4       2049       1019
  138  udp          server       client5       2049       1021
  138  udp          server       client3       2049       1020
  138  udp          server       client3       2049       1020
  138  udp          server       client3       2049       1020

The source port number of 2049 indicates NFS responses.
-- 
Ruth Milner                          NRAO/VLA                  Socorro NM
Computing Division Head      rmilner@zia.aoc.nrao.edu
Newsgroups: comp.protocols.nfs