home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!olivea!decwrl!sgi!rhyolite!vjs
- From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
- Newsgroups: comp.protocols.nfs
- Subject: Re: NFS corruption discovery
- Message-ID: <or7g040@rhyolite.wpd.sgi.com>
- Date: 21 Aug 92 04:47:59 GMT
- References: <1992Aug19.225010.18306@den.mmc.com> <1992Aug21.020212.10792@decuac.dec.com>
- Organization: Silicon Graphics, Inc. Mountain View, CA
- Lines: 26
-
- In article <1992Aug21.020212.10792@decuac.dec.com>, mjr@hussar.dco.dec.com (Marcus J. Ranum) writes:
- > vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
- >
- > >People who prudently turn on UDP checksums will not (I hope) see data
- > >corruption, but if whatever is corrupting data is present, they
- > >will see NFS retransmissions.
- >
- > To amplify on this:
- >
- > People who turn on UDP checksumming (if they are so unfortunate
- > as to have bought a deliberately broken operating system) and notice
- > lots of bad checksums, should note that they have some kind of network
- > problem, and should assume that they are suffering some kind of impact,
- > performance-wise.
- >
- > mjr.
-
-
- Quite right. (see, we can agree on something)
-
- A 1.0% packet loss (i.e. 0.007% bit corruption rate in 1500KB UDP packets)
- with common NFS timeouts is enough to reduce the maximum theoretical
- NFS performance on an ethernet by 90%.
-
-
- Vernon Schryver, vjs@sgi.com
-