From: Steve Dickson <SteveD@RedHat.com>
To: Brian Mancuso <bmancuso@akamai.com>
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>, nfs@lists.sourceforge.net
Subject: Re: NFS/UDP slow read, lost fragments
Date: Mon, 13 Oct 2003 21:20:59 -0400 [thread overview]
Message-ID: <3F8B4F7B.4010907@RedHat.com> (raw)
In-Reply-To: <20030926170759.H787@muppet.kendall.corp.akamai.com>
Brian Mancuso wrote:
>On Thu, Sep 25, 2003 at 04:31:05PM -0700, Trond Myklebust wrote:
>:
>:Could people give it a try?
>:
> Here is a patch (against linux-2.4.23-pre5 with your patch) that implements this (you might
>know of a cleaner way of doing this..):
>
>
I've done some testing with both of these patches and here is
what I've found.... The test consisted of 10 client threads reading 10
different 100mg files on the same filesystem simultaneously. The
machines were duel x86 using private 100bt network.
I used the linux-2.4.23-pre7 kernel with both Trond's and Brian's
patches. The test was done with hard and soft mounts using v3 over
UDP. Here are the results:
linux-2.4.23-pre7
Soft mount:
EIO calls retrans rate
0 128042 2105 6.20Mbps to 6.08Mbps
0 128040 1916 6.28Mbps to 6.09Mbps
0 128044 1936 6.37Mbps to 6.12Mbps
Hard mount:
128048 1995 6.29Mbp to 6.09Mbps
128033 2075 6.21Mbps to 6.07Mbps
128037 2015 6.23Mbps to 6.10Mbps
with Trond's patch
Soft mount:
EIO calls retrans rate
0 128038 1954 6.25Mbps to 6.12Mbps
0 128039 1789 6.32Mbp to 6.14Mbps
0 128042 1853 6.25Mbps to 6.13Mbps
Hard mount:
128039 1880 6.28Mbps to 6.11Mbps
128042 2019 6.29Mbps to 6.12Mbps
128042 1883 6.32Mbps to 6.14Mbps
with Trond's and Brian's patch
Soft mount:
EIO calls retrans rate
0 128036 1943 6.31Mbps to 6.14Mbps
0 128042 1802 6.35Mbps to 6.19Mbps
0 128047 1782 6.35Mbps to 6.14Mbps
Hard mount:
128042 1953 6.28Mbps to 6.10Mbps
128038 1752 6.48Mbps to 6.17Mbps
128034 1978 6.26Mbps to 6.11Mbps
As you can see the patches does help a little bit but
but not as much as I would expect.... Maybe it was the
type of testes ran or maybe I didn't run the tests long enough
(each test ran for about ~2mins) or maybe my expectations
are too high... But it just doesn't seem that these patches really
help that much in bringing down the retransmissions...
SteveD.
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next prev parent reply other threads:[~2003-10-14 1:21 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-25 17:59 NFS/UDP slow read, lost fragments Robert L. Millner
2003-09-25 20:22 ` Brian Mancuso
2003-09-25 20:33 ` brianm
2003-09-25 21:44 ` Brian Mancuso
2003-09-25 23:31 ` Trond Myklebust
2003-09-26 21:07 ` Brian Mancuso
2003-09-27 5:02 ` Robert L. Millner
2003-10-14 1:20 ` Steve Dickson [this message]
2003-10-14 14:52 ` Trond Myklebust
2003-10-15 3:17 ` Steve Dickson
2003-10-15 3:27 ` Trond Myklebust
2003-09-25 20:11 Lever, Charles
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3F8B4F7B.4010907@RedHat.com \
--to=steved@redhat.com \
--cc=bmancuso@akamai.com \
--cc=nfs@lists.sourceforge.net \
--cc=trond.myklebust@fys.uio.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.