home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / protocol / nfs / 2289 < prev    next >
Encoding:
Internet Message Format  |  1992-09-10  |  3.1 KB
  1. Xref: sparky comp.protocols.nfs:2289 comp.protocols.tcp-ip.ibmpc:5164 comp.dcom.lans.ethernet:1874
  2. Path: sparky!uunet!olivea!sgigate!odin!sgi!rhyolite!vjs
  3. From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
  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: <pm73jsg@rhyolite.wpd.sgi.com>
  7. Date: 10 Sep 92 16:05:59 GMT
  8. References: <1992Sep4.173931.24033@pixel.kodak.com> <karl.23.716089551@empirical.com>
  9. Organization: Silicon Graphics, Inc.  Mountain View, CA
  10. Lines: 58
  11.  
  12. In article <karl.23.716089551@empirical.com>, karl@empirical.com (Karl Auerbach) writes:
  13. > ...
  14. > And if you use TCP with the new window extension mechanisms you can get
  15. > much better throughput.  However, I don't know any PC code that uses those 
  16. > yet.
  17.  
  18. Really?  To a PC which probably can't handle more than a few
  19. back-to-back ethernet packets?  (A 250KByte window means the sender is
  20. going to want to send hundreds of back-to-back 1500 byte packets in a
  21. row.)  And on ethernet where the bandwidth*delay product is so low?  I
  22. would really like to know.
  23.  
  24.  
  25. >  Two
  26. > >SPARCstation 2's are apparently capable of data rates of 800 to 1000
  27. > >kilobytes per second memory-to-memory transfer on a dedicated Ethernet.
  28. > 
  29. > Sun's can do *much* better than that.
  30.  
  31. Yes, it's hard to get much more than 1MByte/sec over a 10MHz ethernet.
  32.  
  33. TCP-Large-Windows might help, by making it possible to reduce the
  34. number of ACK's and so the time spent in collision back-off.  I'll have
  35. to try that.
  36.  
  37.  
  38. > > The CPU is probably not critical,
  39. > 
  40. > CPU *is* critical.  One of the big bottlenecks is checksum calculation.
  41. > (I do hope that whoever measured the Sun NFS speed did it with checksums 
  42. > turned on -- Sun workstations run with UDP checksums OFF by default.)
  43.  
  44. This is partly true in the NFS, TCP, and UPD implementations I know
  45. about.  The CPU is the critical resource if you are using something
  46. faster than ethernet, but the checksum is only one of the top 3 or 4
  47. contenders in the program counter profiles.  The cost of the UDP
  48. checksum for modern systems, including Suns, at the low data rates of
  49. NFS over ethernet is insignificant.
  50.  
  51. Consider that you have only about 1MByte/sec of ethernet bandwidth, and
  52. so need to execute between 0.5 and 1.0 million Instructions/sec to
  53. checksum the data (depending on whether you have a carry bit).  Setting
  54. aside any data cache misses, which will generally have to be paid for
  55. the bcopy()'s, that is on the order of 1.0 to 2.0 M cycles/sec.  On a
  56. machine with 33MHz clock rate, you will spend less than 10% of you CPU
  57. computing the UDP checksum.
  58.  
  59. Of course, you can write code to compute the UDP checksum as slowly as
  60. you wish.  The AT&T 80386 System V reference source I saw a few years
  61. ago was very clearly correct, since it computed the checksum in C one
  62. byte at a time.  It was also very clearly amazingly slow.  I assume
  63. vendors were expected to replace the code with assembly language.
  64.  
  65. Sun continues to promise that real soon they will turn on UDP checksums
  66. by default.  That may have already happened.
  67.  
  68.  
  69. Vernon Schryver,  vjs@sgi.com
  70.