home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.protocols.nfs
- Path: sparky!uunet!panther!mothost!merlin.dev.cdx.mot.com!pjd.dev.cdx.mot.com!peterd
- From: peterd@pjd.dev.cdx.mot.com (Peter Desnoyers)
- Subject: Re: NFS packet size
- Message-ID: <peterd.726437927@pjd.dev.cdx.mot.com>
- Sender: news@merlin.dev.cdx.mot.com (Merlin News System)
- Nntp-Posting-Host: pjd.dev.cdx.mot.com
- Organization: Motorola Codex, Canton, Massachusetts
- References: <u97b4fc@rhyolite.wpd.sgi.com> <C04t4o.K10@news.iastate.edu> <peterd.726170584@pjd.dev.cdx.mot.com> <ugkusv0@rhyolite.wpd.sgi.com>
- Date: Thu, 7 Jan 1993 20:18:47 GMT
- Lines: 28
-
- [in reply to Vernon Schryver and Gary Anderson]
-
- Well, I said TCP seemed better than NFS with 100mS timeouts "on
- paper"...
-
- As Vernon has pointed out, the stock BSD adaptive retransmission timer
- isn't going to track well at 200 mS or below, as it is implemented by
- a 5Hz periodic tick. (this would give a minimum mean timer of 300mS,
- actually.)
-
- If (initial) timers were equal in both cases, you would see the
- following effects:
-
- - the exponential backoff in NFS has the same effect as doubling the
- error rate with a fixed timer.
- - when a packet is lost, TCP starts retransmitting at that packet,
- while NFS starts on average 3 frames back (6 frames/request).
-
- Both of these would tend to result in decreased performance for NFS.
- However, if the initial NFS timer were 2 or 3 times lower than the TCP
- timer, I would expect NFS to perform better.
-
- [again on paper, NFS starting at 100mS falls to 50% throughput at
- 0.68% error rate, while TCP with 300mS timeout hits 50% a bit sooner,
- at 0.42% error rate.]
-
- Peter Desnoyers
- --
-