home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / protocol / nfs / 2957 < prev    next >
Encoding:
Text File  |  1992-12-15  |  6.1 KB  |  157 lines
  1. Newsgroups: comp.protocols.nfs
  2. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!spool.mu.edu!think.com!ames!biersch!aga
  3. From: aga@Comtech.com (Alan G. Arndt)
  4. Subject: Re: Sun PC-NFS performance (again)
  5. Message-ID: <1992Dec15.015951.20329@Comtech.com>
  6. Organization: Comtech Labs Inc, Palo Alto
  7. References: <1fooqcINN52p@seven-up.East.Sun.COM> <1992Dec7.173718.12792@Comtech.com> <1g3673INNa64@seven-up.East.Sun.COM>
  8. Date: Tue, 15 Dec 1992 01:59:51 GMT
  9. Lines: 146
  10.  
  11. I did some more testing with PC-NFS (4.0a) this weekend.  As everyone
  12. seems to be harrasing me about how my SS1+ really wasn't a server and
  13. I should get a REAL machine I went to a friend site with my pc.  I
  14. don't see how you can't call a SS1+ a capable machine when it is 4+
  15. times the machine of a 386 server running Novell.  Yet it only
  16. performs at 1/4 the speed!  Anyhow I connected up to a 4/670-140-64.
  17. Something of a REASONABLE server class machine wouldn't you say?
  18. Well suprise suprise I got EXACTLY the same performance, a paultry
  19. 277.7 KB/sec!  And in fact on HIS SS1+ I got 294.2 KB/sec.  The only
  20. reason I can figure his SS1+ was faster is it was on the SAME tap on
  21. the E-NET v.s. the 4/670 being 50+ Meters away through two repeaters.
  22.  
  23. The fully gorry details of the performance numbers are as follows and
  24. all these performance numbers are on an IDLE, or nearly so Server AND
  25. LAN:
  26.  
  27. Read/Write Performance                   Servers
  28. In KBytes/sec      Ours                Friends Machines
  29.         SS1+ w/40MB           4/670               SS1+ w/24Meg
  30. Clients        1.3 GB, 5MB/sec    1.3 GB, 5MB/sec    440 Mb, 5MB/sec 
  31.         SunOS 4.1.1       SunOS 4.1.3 (STOCK)  SunOS 4.1.1
  32.  
  33. 486-DX50
  34.     SMC8013    277.7 / 166.7       277.7 / 18.4        294.1 / 14.2       
  35.     3C509    277.7 / 166.7       277.7 / 18.4        294.1 / 14.2
  36.  
  37. 486-DX33
  38.     SMC8013    277.7 / 166.7
  39.  
  40. 486-DX25
  41.     SMC8013    277.7 / 166.7
  42.  
  43. 386-DX33
  44.     SMC8013    277.7 / 166.7
  45.     3C501    160   /  90
  46.     3C503    160   /  90
  47.  
  48. SS1+
  49. File Copies 'cat big || cat > /dev/nul' where big is 10MB
  50.                     14.9 Seconds    15.8 Seconds
  51.                     671 KB/Sec        632 KB/Sec
  52.  
  53. All PC benchmarks are done with Norton Utilities 6.0 SI Network disk
  54. test.  The same results are also obtained with a simple PC copy to
  55. nul: (within a few percent, i.e. 268 KB/sec by hand on my stopwatch).
  56.  
  57. The WD8013 Cards obtain the same performance with a PC-NFS specific
  58. driver AND the NDIS drivers.  The PC-NFS specific drivers are smaller
  59. then the NDIS drivers for memory usage.  The 3C509 only works with a
  60. NDIS driver.
  61.  
  62. Do we notice a PATTERN here?  It CAN'T go faster then 277.7 KB/sec
  63. except in one circumstance which is belived to be because of the
  64. closeness of the machine.
  65.  
  66. So the PC isn't the limiting factor, the PC's card isn't the limiting
  67. factor, the network isn't the limiting factor and the SERVER ISN'T
  68. the limiting factor, the protocol isn't the limiting factor, in fact
  69. the LOW Level drivers aren't even the limiting factor.  So that only
  70. leaves ONE item, PC-NFS itself.
  71.  
  72. Now that I have shown all the data I have I will go into what we
  73. found out.  We then used etherfind to watch the packets going across. 
  74. Years ago (5+) with PC-NFS V2.x I watched this transaction and I
  75. could swear it the Sun was sending 8KB blocks in 5 packet bursts and
  76. the pc would receive them and request another block.  HOWEVER,
  77. yesterday we noticed that the PC was only requesting 1K blocks (1166)
  78. bytes.  The request was a healthy 218 bytes as well.  When one
  79. starts to add up the requests and individual 1K bytes I can belive
  80. that the performance is ONLY 277 KB/sec and that the machines are
  81. doing their BEST the get that.  That is why there is a noticeable
  82. difference between 50 Meters away and a machine RIGHT next to it's
  83. client.
  84.  
  85. We also noticed that the PC was only creating WRITES of apparently
  86. 512 bytes (734).
  87.  
  88. As can be seen bye the last entry the other Suns certainly use the
  89. block size of 8K to the fullest advantage and of course get very
  90. acceptable performance.
  91.  
  92.  
  93. raritan = 486-50 PC-NFS
  94. durable = 4/670
  95. certes  = 4/65
  96. picasso = 4/65
  97.  
  98.        lnth proto source      destination   src port   dst port
  99. Reads
  100. 12.66   218  udp raritan     durable        127       2049
  101. 12.66  1166  udp durable     raritan       2049        127
  102. 12.66   218  udp raritan     durable        127       2049
  103. 12.67  1166  udp durable     raritan       2049        127
  104. 12.67   218  udp raritan     durable        127       2049
  105. 12.67  1166  udp durable     raritan       2049        127
  106. 12.67   218  udp raritan     durable        127       2049
  107. 12.67  1166  udp durable     raritan       2049        127
  108.  
  109.  
  110. Writes
  111.  9.62   734  udp raritan    certes           127       2049
  112.  9.65   138  udp certes        raritan          2049        127
  113.  9.65   734  udp raritan    certes           127       2049
  114.  9.68   138  udp certes        raritan          2049        127
  115.  9.68   734  udp raritan    certes           127       2049
  116.  9.72   138  udp certes        raritan          2049        127
  117.  9.72   734  udp raritan    certes           127       2049
  118.  9.75   138  udp certes        raritan       2049        127
  119.  9.75   734  udp raritan    certes           127       2049
  120.  9.78   138  udp certes        raritan          2049        127
  121.  
  122.  
  123. Reads
  124.  1.16   194  udp picasso    durable       1021       2049
  125.  1.17  1514  udp durable    picasso       2049       1021
  126.  1.17 *1514  udp 
  127.  1.17 *1514  udp 
  128.  1.17 *1514  udp 
  129.  1.17 *1514  udp 
  130.  1.17 * 934  udp 
  131.  1.17   194  udp picasso    durable       1022       2049
  132.  1.18  1514  udp durable    picasso       2049       1022
  133.  1.18 *1514  udp 
  134.  1.18 *1514  udp 
  135.  1.18 *1514  udp 
  136.  1.18 *1514  udp 
  137.  1.18 * 934  udp 
  138.  
  139.  
  140. Now we looked at the manuals and the only option I found was TSIZE
  141. which WAS set at 8Kbytes.  The TSIZE is supposed to be only for
  142. writes but as there is only one option I assumed it might also be
  143. used for the read request size.  It is however obvious that PC-NFS
  144. pay's NO ATTENTION to this parameter and it wasting a tremendous
  145. amount of time dealing with small block sizes.
  146.  
  147. So what can be done to PC-NFS to get it to use the LARGE block sizes? 
  148. Is there some parameter I have missed?  The SMC8013 cards have
  149. buffers of 16K on the board and certainly could handle 4K blocks if
  150. not full 8K blocks.  The 3C509 cards will stream the data off the
  151. card as it comes in so the block size is irrelavent.  Obviously the
  152. 3C501 and 3C503 cards have small buffers and need to continue to
  153. operate in their current configuration.
  154.  
  155. -Alan Arndt
  156. aga@Comtech.com
  157.