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. > >People who prudently turn on UDP checksums will not (I hope) see data
  14. > >corruption, but if whatever is corrupting data is present, they
  15. > >will see NFS retransmissions.
  16. >     To amplify on this:
  17. >     People who turn on UDP checksumming (if they are so unfortunate
  18. > as to have bought a deliberately broken operating system) and notice
  19. > lots of bad checksums, should note that they have some kind of network
  20. > problem, and should assume that they are suffering some kind of impact,
  21. > performance-wise.
  22. > mjr.
  23.  
  24.  
  25. Quite right.  (see, we can agree on something)
  26.  
  27. A 1.0% packet loss (i.e. 0.007% bit corruption rate in 1500KB UDP packets)
  28. with common NFS timeouts is enough to reduce the maximum theoretical
  29. NFS performance on an ethernet by 90%.  
  30.  
  31.  
  32. Vernon Schryver,  vjs@sgi.com
  33.