From: Eric Whiting <ewhiting@amis.com>
To: trond.myklebust@fys.uio.no
Cc: I Lee Hetherington <ilh@sls.lcs.mit.edu>, nfs@lists.sourceforge.net
Subject: Re: 2.4.18: NFS_ALL patch greatly hurting UDP speed
Date: Wed, 20 Mar 2002 11:23:43 -0700 [thread overview]
Message-ID: <3C98D3AF.8091F420@amis.com> (raw)
In-Reply-To: 15512.44969.304675.703836@charged.uio.no
Trond,
Some more data from some 2.4.18 tests I just ran...
==FIRST TEST
CLIENT: CLEAN 2.4.18 kernel with NFSV3 enabled
SERVER: Solaris 8 server (E280R)
100M switched network (1G backbone connecting these two boxes -- but
results the same when staying on local switch)
Writing with putc()... done: 5941 kB/s 59.3 %CPU
Rewriting... done: 5254 kB/s 6.7 %CPU
Writing intelligently... done: 5605 kB/s 4.1 %CPU
Reading with getc()... done: 9028 kB/s 89.3 %CPU
Reading intelligently... done: 197558 kB/s 100.3 %CPU
==SECOND TEST
CLIENT: Same setup as the first but with linux-2.4.18-NFS_ALL.dif
applied. Same .config file.
SERVER: Same
Writing with putc()... done: 5977 kB/s 63.5 %CPU
Rewriting... done: 3494 kB/s 5.7 %CPU
Writing intelligently... done: 734 kB/s 0.7 %CPU
Reading with getc()... done: 9255 kB/s 72.8 %CPU
Reading intelligently... done: 195361 kB/s 34.3 %CPU
PROBLEM: the intelligent writes look bad.
==THIRD TEST
Same setup as second test, but using dd instead of bonnie
mohawk/test> time dd if=/dev/zero of=file bs=1024k count=1
1+0 records in
1+0 records out
0.000u 0.030s 0:05.06 0.5% 0+0k 0+0io 136pf+0w
About 200k/s on a 100Mbit network -- not very good.
I grabbed a simple tcpdump of that whole dd session. I'll send a
off-list copy of the dump to Trond.
eric
Trond Myklebust wrote:
>
> >>>>> " " == Trond Myklebust <trond.myklebust@fys.uio.no> writes:
>
> > exceeded' ICMP messages littered around the place. The first
> > one comes just after the loss of fragments, and is accompanied
> > by a 2 second delay, during which all the reads that are sent
> > time out without receiving a single reply...
>
> Note: this 2 second period of silence appears to be what is really
> causing the *100 slowdown. I've no idea what the switch is engaging in
> during that time, but you might want to take a look to see if those
> messages being sent during that period are indeed being received on
> the server.
>
> Cheers,
> Trond
>
> _______________________________________________
> NFS maillist - NFS@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next prev parent reply other threads:[~2002-03-20 18:23 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <3C88F8EE.86058BD5@sls.lcs.mit.edu>
[not found] ` <shs7kollatu.fsf@charged.uio.no>
2002-03-20 15:39 ` 2.4.18: NFS_ALL patch greatly hurting UDP speed I Lee Hetherington
2002-03-20 15:45 ` Trond Myklebust
2002-03-20 15:50 ` Trond Myklebust
2002-03-20 18:23 ` Eric Whiting [this message]
2002-03-21 0:20 ` Ion Badulescu
2002-03-21 0:33 ` Eric Whiting
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=3C98D3AF.8091F420@amis.com \
--to=ewhiting@amis.com \
--cc=ilh@sls.lcs.mit.edu \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox