home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!mcsun!uknet!strath-cs!baird!jim
- From: jim@cs.strath.ac.uk (Jim Reid)
- Newsgroups: comp.protocols.nfs
- Subject: Re: NFS I/O Ops/seconds
- Message-ID: <JIM.92Jul27122141@hunter.cs.strath.ac.uk>
- Date: 27 Jul 92 11:21:41 GMT
- References: <1992Jul22.061146.15641@u.washington.edu> <numb.711969731@root.co.uk>
- <noe56po@rhyolite.wpd.sgi.com>
- Sender: news@cs.strath.ac.uk
- Organization: Computer Science Dept., Strathclyde Univ., Glasgow, Scotland.
- Lines: 24
- Nntp-Posting-Host: hunter
- 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
-