home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / protocol / nfs / 2290 < prev    next >
Encoding:
Internet Message Format  |  1992-09-10  |  3.8 KB
  1. Xref: sparky comp.protocols.nfs:2290 comp.protocols.tcp-ip.ibmpc:5165 comp.dcom.lans.ethernet:1875
  2. Path: sparky!uunet!dtix!darwin.sura.net!zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!torn!watserv2.uwaterloo.ca!watserv1!sail.uwaterloo.ca!eengelke
  3. From: eengelke@sail.uwaterloo.ca (Erick Engelke)
  4. Newsgroups: comp.protocols.nfs,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans.ethernet
  5. Subject: Re: Sun <=> PC Transfer Rate (Summary)
  6. Message-ID: <BuDFv1.3n6@watserv1.uwaterloo.ca>
  7. Date: 10 Sep 92 16:45:00 GMT
  8. References: <1992Sep4.173931.24033@pixel.kodak.com> <karl.23.716089551@empirical.com>
  9. Sender: news@watserv1.uwaterloo.ca
  10. Organization: University of Waterloo
  11. Lines: 75
  12.  
  13. karl@empirical.com (Karl Auerbach) writes:
  14. > tgl@ssd.kodak.com (Tom Lathrop) writes:
  15. >>I was asked to summarize the responses to my query about optimizing
  16. >>Sun to PC file transfer.
  17. >
  18. >And if you use TCP with the new window extension mechanisms you can get
  19. >much better throughput.  However, I don't know any PC code that uses those 
  20. >yet.
  21.  
  22. The closest I know of is my own FTP which uses up to 32K transmit window.
  23. I kept the receive window small so that people wouldn't be conjesting 
  24. long haul networks.  I know that seems counter productive, but my own
  25. site is sufferring badly from saturated connections...  
  26.  
  27. >
  28. >There is also a substantial difference depending on the latency and error 
  29. >rate of the network.  If you are going through routers and over the internet 
  30. >you can see a major difference between NFS and TCP file transfer rates.
  31. >
  32. >But the #1 absolute most important factor is the speed of the disk.
  33. >
  34.  
  35. My PC FTP runs the disk and network concurrently (on large files) so it 
  36. will typically be very much limited to the slower of the source or sink,
  37. namely the disk.  Many of the commercial PC TCP implementations also 
  38. provide this sort of design with varied results.
  39.  
  40. >I routinely get 2megabit FTP transfers from a Sun Sparc 2 to a wimpy
  41. >16mhz 386sx box with an 8 bit WD board and packet driver.... as long as the 
  42. >destination is NUL:  (Software is PC/TCP v2.1)
  43. >
  44. >I've gotten as high as 5megabits/second using a 50Mhz 486DX box with a 16 
  45. >bit WD board using the same software and packet driver.
  46.  
  47. That is about the limit of the current ISA ethernet hardware and packet
  48. drivers.  3Com's new (unreleased) cards should up that by 25% to 50%.
  49. On a different ISA network card we get 850 KB/s, but you really start
  50. hitting the hardware bus limitations.
  51.  
  52. >
  53. >> The CPU is probably not critical,
  54. >
  55. >CPU *is* critical.  One of the big bottlenecks is checksum calculation.
  56. >(I do hope that whoever measured the Sun NFS speed did it with checksums 
  57. >turned on -- Sun workstations run with UDP checksums OFF by default.)
  58. >
  59.  
  60. Not on a modern system.  Times vary greatly, but my desktop 386-33 can
  61. checksum 24 MB/s, so it's an overhead of about 2%.  Variance due to
  62. network conjestion and clock accuracy far outweigh the effects of 
  63. checksumming when done optimally.  
  64.  
  65. But you raise the point of whether or not it is implemented efficiently,
  66. that 24 MB/s figure is using 32 bit code.  Optimal 16 bit code is much
  67. slower, and typical (less optimized) 16 bit code is slower still.
  68.  
  69. >
  70. >>software side, a couple of people said that if a packet driver is used,
  71. >>which one it is makes a big difference.
  72. >
  73. >I've sent over 2500 packets per second through packet drivers.  And that 
  74. >was on a 12mhz 286.  Of course, that was a special test designed to
  75. >load the network.
  76.  
  77. For SMC cards, the SMC packet driver is much faster than the CRYNWR packet
  78. driver, but not as reliable on fast hardware.  If you want to see how
  79. many packets/s your packet driver can do, ftp to sunee.uwaterloo.ca
  80. and get pub/wattcp/speed.zip.  Please don't use it on a production network,
  81. use a test segment instead.
  82.  
  83. Erick
  84. -- 
  85. Erick Engelke                      Engineering Computing
  86.                          University of Waterloo
  87. Waterloo TCP Architect         erick@development.watstar.uwaterloo.ca
  88.