NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/protocol/nfs/1958

Internet Message Format | 1992-07-27 | 3.4 KB

Path: sparky!uunet!mcsun!uknet!warwick!str-ccsun!strath-cs!baird!jim
From: [e-mail] (Jim Reid)
Newsgroups: comp.protocols.nfs
Subject: Re: NFS I/O Ops/seconds
Message-ID: <[e-mail]>
Date: 27 Jul 92 17:00:10 GMT
References: <[e-mail]> <[e-mail]>
    <[e-mail]>
    <[e-mail]>
Sender: [e-mail]
Organization: Computer Science Dept., Strathclyde Univ., Glasgow, Scotland.
Lines: 57
Nntp-Posting-Host: hunter
In-reply-to: [e-mail]'s message of 27 Jul 92 15:16:24 GMT

In article <[e-mail]> [e-mail] (Vernon Schryver) writes:

   In article <[e-mail]>, [e-mail] (Jim Reid) writes:
   > In article <[e-mail]> [e-mail] (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.....
   >
   > 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.

   Well, you're right about the effects of the mix.  However, you're wrong
   about the potential of saving only 1000 instructions.

Well, considering that I plucked the number out of thin air, this is
probably not surprising. Maybe your implementation takes more (or
less) instructions. However, it should take around 1000 instructions
or so for the typical RISC chip to take an NFS request off the network
interface hand it off to the NFS code (or push a reply back out). Even
if the number was twice that amount, it would still be dwarfed by the
CPU cycles needed to actually *do* the NFS request. And if there was a
disk I/O (~10ms), a factor of 100 on the number of instructions, could
be included without much trouble.

   If
    -your system uses 4KByte pages,
    -if your NFS implementation happens to use 4K blocks,
    -if your file system happens to like to use 4K buffers,
   and  -if your FDDI hardware handles UDP checksums,
   then you can avoid around 1024 cache-missing loads and stores by using
   "page flipping".  That is the equivalent of 10,000 to 100,000
   instructions per packet.  (The cache miss penalty for an R4K at
   50/100MHz is awesome.)

True. Can the SGI kernel really be so dumb as to take loads of cache
misses when computing UDP checksums? If so, we all know what machines
don't make good NFS servers...

   I also don't think saving 1000 instructions is anything to sneeze at.
   Saving 1000 instructions would produce a large speed up in SGI NFS
   server.  (We don't yet page-flip.)  Also, remember that 1000
   instructions is not necessarly even close to 30 usec even at 33 MHz,
   unless your primary instruction cache is very large.

Hmmm. How big are your instructions? Let's say they are 64 bits long
(or wide). 1000 of them will fit in 8K. This is not large for a cache
these days.

        Jim