home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / protocol / nfs / 1957 < prev    next >
Encoding:
Internet Message Format  |  1992-07-27  |  2.6 KB
  1. Path: sparky!uunet!olivea!hal.com!decwrl!sgi!rhyolite!vjs
  2. From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
  3. Newsgroups: comp.protocols.nfs
  4. Subject: Re: NFS I/O Ops/seconds
  5. Message-ID: <nqr74rg@rhyolite.wpd.sgi.com>
  6. Date: 27 Jul 92 15:16:24 GMT
  7. References: <1992Jul22.061146.15641@u.washington.edu> <numb.711969731@root.co.uk> <JIM.92Jul27122141@hunter.cs.strath.ac.uk>
  8. Organization: Silicon Graphics, Inc.  Mountain View, CA
  9. Lines: 48
  10.  
  11. In article <JIM.92Jul27122141@hunter.cs.strath.ac.uk>, jim@cs.strath.ac.uk (Jim Reid) writes:
  12. > In article <noe56po@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
  13. > 
  14. >    An NFS server or client on FDDI is intrinsically faster than a similar
  15. >    machine over ethernet.  This is because it takes significantly fewer
  16. >    host cycles to generate 1 or 2 UDP/IP datagrams for a 4K or 8K read or
  17. >    write than to generate 3 or 6.  
  18. > 
  19. > Yes, but..... 
  20. > 
  21. > 4K or 8K reads and writes tend not to be the most commonly used NFS
  22. > operations. Typically, 70-80% of the NFS requests will be lookups and
  23. > getattrs. These generate itty-bitty packets - 2-300 bytes or so -
  24. > which will fit quite comfortably in the maximum packet "frame" for
  25. > just about any network. Therefore, fragmentation of NFS requests is No
  26. > Big Deal.
  27. > 
  28. > While what you say is true, the benefits of lower protocol processing
  29. > are negligible. This maybe saves 1000 instructions or so (a whole 30
  30. > microseconds of CPU on the average workstation these days) for perhaps
  31. > 20% of the server's NFS operations. I suspect that this will be lost
  32. > in the noise when compared with the CPU overhead of actually servicing
  33. > the NFS request and/or waiting for the disk.
  34. > 
  35. >         Jim
  36.  
  37.  
  38. Well, you're right about the effects of the mix.  However, you're wrong
  39. about the potential of saving only 1000 instructions.
  40.  
  41. If 
  42.      -your system uses 4KByte pages, 
  43.      -if your NFS implementation happens to use 4K blocks,
  44.      -if your file system happens to like to use 4K buffers,
  45. and  -if your FDDI hardware handles UDP checksums,
  46. then you can avoid around 1024 cache-missing loads and stores by using
  47. "page flipping".  That is the equivalent of 10,000 to 100,000
  48. instructions per packet.  (The cache miss penalty for an R4K at
  49. 50/100MHz is awesome.)
  50.  
  51. I also don't think saving 1000 instructions is anything to sneeze at.
  52. Saving 1000 instructions would produce a large speed up in SGI NFS
  53. server.  (We don't yet page-flip.)  Also, remember that 1000
  54. instructions is not necessarly even close to 30 usec even at 33 MHz,
  55. unless your primary instruction cache is very large.
  56.  
  57.  
  58. Vernon Schryver,  vjs@sgi.com
  59.