home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / protocol / nfs / 2121 < prev    next >
Encoding:
Internet Message Format  |  1992-08-20  |  1.3 KB
  1. Path: sparky!uunet!olivea!decwrl!sgi!rhyolite!vjs
  2. From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
  3. Newsgroups: comp.protocols.nfs
  4. Subject: Re: NFS corruption discovery
  5. Message-ID: <or7g040@rhyolite.wpd.sgi.com>
  6. Date: 21 Aug 92 04:47:59 GMT
  7. References: <1992Aug19.225010.18306@den.mmc.com> <1992Aug21.020212.10792@decuac.dec.com>
  8. Organization: Silicon Graphics, Inc.  Mountain View, CA
  9. Lines: 26
  10.  
  11. In article <1992Aug21.020212.10792@decuac.dec.com>, mjr@hussar.dco.dec.com (Marcus J. Ranum) writes:
  12. > vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
  13. > 
  14. > >People who prudently turn on UDP checksums will not (I hope) see data
  15. > >corruption, but if whatever is corrupting data is present, they
  16. > >will see NFS retransmissions.
  17. > 
  18. >     To amplify on this:
  19. > 
  20. >     People who turn on UDP checksumming (if they are so unfortunate
  21. > as to have bought a deliberately broken operating system) and notice
  22. > lots of bad checksums, should note that they have some kind of network
  23. > problem, and should assume that they are suffering some kind of impact,
  24. > performance-wise.
  25. > 
  26. > mjr.
  27.  
  28.  
  29. Quite right.  (see, we can agree on something)
  30.  
  31. A 1.0% packet loss (i.e. 0.007% bit corruption rate in 1500KB UDP packets)
  32. with common NFS timeouts is enough to reduce the maximum theoretical
  33. NFS performance on an ethernet by 90%.  
  34.  
  35.  
  36. Vernon Schryver,  vjs@sgi.com
  37.