stanonik@nprdc.arpa (Ron Stanonik) (12/02/87)
Sometime ago we obtained NFS from XINU for our VAX 780 running 4.3bsd, but we didn't immediately install it because the need wasn't pressing, and we'd heard that NFS's lack of namei caching (or something analogous to it . . . namev caching?) was a big (~20%) performance loss. Well, the need is more pressing now, but so is the desire to maintain VAX performance (ie, more users now). What performance change have others noticed after installing NFS? Name caching sounds very hard to do in a distributed system; ie, hard to keep the cache consistent with the remote filesystems. Thanks, Ron Stanonik stanonik@nprdc.arpa
m5@lynx.uucp (Mike McNally) (07/19/90)
A brief question for those experienced with NFS environments: do you expect
the operation of copying a file with "cat" from a remotely mounted file
system to /dev/null to be (A) about the same as using rcp, (B) about the
same as for a file from a local disk, or (C) something else (?). I'm not
really interested in special situations, just this straightforward (and
admittedly overly simple) test.
--
Mike McNally Lynx Real-Time Systems
uucp: {voder,daver}!lynx!m5 phone: 408 370 2233
Where equal mind and contest equal, go.hitz@auspex.auspex.com (Dave Hitz) (07/20/90)
In article <7887@lynx.UUCP> m5@lynx.uucp (Mike McNally) writes: > A brief question for those experienced with NFS environments: do you expect > the operation of copying a file with "cat" from a remotely mounted file > system to /dev/null to be (A) about the same as using rcp, (B) about the > same as for a file from a local disk, or (C) something else (?). I'm not > really interested in special situations, just this straightforward (and > admittedly overly simple) test. In general: For small files, the cat should win because there is a fair amount of overhead involved in starting up the rcp connection. For very large files, the two should be similar, although rcp might have a small edge because TCP has better buffering and window size adjustment algorithms than NFS. In specific, there are some cases where the above isn't true: (1) In SunOS 4.0 (and higher), cat doesn't actually do reads in the case where the output goes to /dev/null. So on a SunOS client, the cat will be instant while the rcp will be slow. Using 'dd bs=8k' instead of 'cat' forces the I/O to occur. cat dd rcp 4 meg file 0:00 0:07 0:10 16K file 0:00 0:00 0:02 (2) With Auspex NS 5000 servers, NFS requests go through dedicated NFS hardware, whereas rcp requests go to a general purpose UNIX processor. As a result the dd will be much faster than the rcp. cat dd rcp 4 meg file 0:00 0:07 0:38 16K file 0:00 0:00 0:05 Both rcp results are slower than the ones above because the Auspex UNIX processor is a 68K, whereas the ones above come from a SPARC server. There are probably more exceptions for other combinations of hardware/software, but these are the two that come to mind immediately. I would say, if you have NFS use it. Dave Hitz home: 408-739-7116 UUCP: {uunet,mips,sun,bridge2}!auspex!hitz work: 408-492-0900 -- Dave Hitz home: 408-739-7116 UUCP: {uunet,mips,sun,bridge2}!auspex!hitz work: 408-492-0900
guy@auspex.auspex.com (Guy Harris) (07/21/90)
> (1) In SunOS 4.0 (and higher), cat doesn't actually do reads in > the case where the output goes to /dev/null. Just in case anybody was about to interpret this as meaning that "cat" special-cases "/dev/null": For those not aware of how this happens, "cat" in 4.0 "mmap()"s the file(s) being concatenated, if it can, and just writes from the mapped-in areas (mapped 1MB at a time, as I remember). This means that the handler for the object being written to, in effect, does all the reading, by faulting in the data from the file; since the handler for "/dev/null" never looks at the data being written, it's never faulted in.