home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / protocol / nfs / 2216 < prev    next >
Encoding:
Text File  |  1992-09-03  |  4.2 KB  |  103 lines
  1. Newsgroups: comp.protocols.nfs
  2. Path: sparky!uunet!gatech!asuvax!ennews!ennews.eas.asu.edu!mc
  3. From: mc@emma.la.asu.edu (Mike Caplinger)
  4. Subject: benchmarks for Sun NFS accelerators
  5. Message-ID: <MC.92Sep3105607@emma.la.asu.edu>
  6. Sender: news@ennews.eas.asu.edu (USENET News System)
  7. Organization: Mars Observer TES Project, ASU, Tempe AZ
  8. Date: Thu, 3 Sep 1992 17:56:07 GMT
  9. Lines: 92
  10.  
  11. This message describes my recent benchmarks of NFS accelerator
  12. products for Sun SPARC computers.  It is not an endorsement of any
  13. specific product, and like all benchmarks, is obviously dependent on
  14. the application.  Most of our applications are image processing
  15. programs that read one or more files (some sequentially, some
  16. randomly) and write a result file, usually sequentially.  These files
  17. are often tens or even hundreds of megabytes in size.  We usually use
  18. mmap to map the files in their entirety into memory, both for input
  19. and output, and we always map shared so as to not use swap file space.
  20.  
  21. Originally, we had intended to require local disk space on each
  22. workstation to store output files temporarily, because we knew NFS
  23. writing performance was poor.  However, this approach is a pain to
  24. administrate (no one's local disk is ever big enough), so we wanted to
  25. see what various NFS accelerators would do for our applications.
  26.  
  27. We wrote two simple benchmark programs to simulate the output phase of
  28. our applications.  The first, called `write', does a single write
  29. system call of a specified amount of memory.  The second, `map',
  30. creates, extends, and then mmaps a file of a given size, then
  31. sequentially touches the first byte of each page.
  32.  
  33. Two products were tried: eNFS from Interstream and Sun's SBus
  34. Prestoserve (with 1 MB of NVRAM).  We ran eNFS in both normal and
  35. asynchronous modes.  We compare the performance results against local
  36. disk access; our goal was to find a solution that gave us performance
  37. within a factor of two of local access.
  38.  
  39. The following results are for SBus Prestoserve versus local disk
  40. access.  These numbers were obtained at the San Diego Sun office.
  41. Remote operations were from an IPX with 32 MB and a 669MB disk to a
  42. 630MP with 64MB(?), an attached 1.2GB Seagate disk, and two
  43. processors.  Local operations were to the IPX's 669MB disk.
  44.  
  45. file    presto    local    presto    local
  46. size(MB)write    write    map    map
  47. 4    0:08    0:02    0:16    0:02
  48. 8    0:16    0:06    0:30    0:02
  49. 16    0:30    0:12    1:02    0:07
  50. 32    1:01    0:31    1:50    0:19
  51.  
  52. The following results are for eNFS in normal mode.  These numbers were
  53. obtained at MSSS.  Remote operations were from an SS2 with 64 MB and
  54. an HP 1GB to a 670MP with 64MB, an attached 2GB Micropolis, and four
  55. processors.  Local operations were to the SS2's HP disk.
  56.  
  57. file    eNFS    local    eNFS    local
  58. size(MB)write    write    map    map
  59. 4    0:15    0:03    0:49    0:01
  60. 8    0:30    0:05    1:39    0:01
  61. 16    1:06    0:10    3:22    0:03
  62. 32    2:33    0:29    6:35*    0:10
  63.  
  64. * We sometimes saw faster times by a factor of two for this number,
  65. reason unknown, but it was never faster than about 3 minutes.
  66.  
  67. These numbers, also obtained with the MSSS configuration, are for eNFS
  68. in asynchronous mode.
  69.  
  70. file    eNFS    local    eNFS    local
  71. size(MB)write    write    map    map
  72. 4    0:06    0:03    0:11    0:01
  73. 8    0:12    0:05    0:23    0:02
  74. 16    0:23    0:11    0:47    0:03
  75. 32    0:56    0:29    1:19    0:13
  76.  
  77. This is a summary of the results for 32 MB output files, normalized to
  78. local performance:
  79.  
  80.     local    presto    eNFS    eNFS async
  81. write    1    2.0    5.3    1.9
  82. map    1    5.8    39.5    6.1
  83.  
  84. Disappointingly, neither eNFS nor Prestoserve comes close to meeting
  85. our requirements for the map benchmark.  This is probably inevitable,
  86. given that the mapped pages are not written out to disk until the
  87. system runs out of memory if the mapped object is local, but they
  88. appear to be flushed when the process exits if the mapped object is
  89. remote.  Once again, I wish that there was some way to specify the
  90. reliability semantics of NFS operations on a per-partition or even a
  91. per-file basis.  mmap is superior for local access, but seems to
  92. overwhelm the available NFS accelerator products when pages are
  93. flushed to remote objects (perhaps an artifact of the way SunOS
  94. flushes pages?)
  95.  
  96. Any comments or questions are welcome.
  97.  
  98.     Mike Caplinger, MSSS/Caltech Mars Observer Camera Project
  99.     mc@msss.com
  100.  
  101. disclaimer: this message contains the opinions of the author only, and
  102. is not the official position of MSSS or any of its funding agencies.
  103.