Re: NFS/UDP slow read, lost fragments

From: "Robert L. Millner" <rmillner@transmeta.com>
To: nfs@lists.sourceforge.net
Subject: Re: NFS/UDP slow read, lost fragments
Date: Fri, 26 Sep 2003 22:02:05 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.44.0309261804400.28586-100000@localhost.localdomain> (raw)
In-Reply-To: <20030926170759.H787@muppet.kendall.corp.akamai.com>

> The following patch sets up a scheme of the form described by Brian,
> in combination with another fix to lengthen the window of time during
> which we accept updates to the RTO estimate (Karn's algorithm states
> that the window closes once you retransmit, whereas our current
> algorithm closes the window once a request times out).

Still seeing an inordinate number of retransmits (25% of the reads are
duplicates) with 2.4.23-pre5 and the patch on my test case (copy a 70MB
file from the server).

Its interesting to note that a dual P4 Xeon with an e1000 attached to the
same Foundry switch as the Netapp also has a similar retransmit rate
(20%).

If the same test is run against a different Netapp (running 6.3.1R1),
there's still a large number of retransmits but down to 17%.

Examining this problem further; if the server is Linux (stock Red Hat 7.3,
2.4.20-18.7smp, dual Xeon 2.4GhZ) then there are no retransmits and the
70MB copy takes its appropriate 6.4 sec with the client running either the
stock Red Hat kernel or a patched 2.4.23-pre5.

If the server is a Sun 880, running Solaris 8, then there are no
retransmits and the 70MB copy takes around 6.5 sec.

If the Netapp is placed under a heavy load (CPU at between 65% and 100% -
which traditionally kills Netapp performance), the 2.4.23-pre5+patch
client has roughly the same percentage of retransmits as it does against
an otherwise quiescent Netapp; however, the test takes 470 seconds instead
of 550 seconds.

As a sanity check against transient network problems, the problem still
consistently goes away if the client boots 2.2.19 and consistently repeats
if the client boots 2.4.23-pre5+patch.

I guess the next step is to go over packet dumps from both the client and
another host on a mirrored network port to see what's interesting about
the fragments being dropped.  That may point to why a heavily loaded
Netapp performs this test faster than a quiescent one.

	Rob

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs