Date: Wed, 9 Oct 1996 14:11:22 -0400 (EDT) From: Charles Henrich <henrich@crh.cl.msu.edu> To: dfr@render.com (Doug Rabson) Cc: simokawa@sat.t.u-tokyo.ac.jp, lite2@freebsd.org Subject: Re: Delayed write patch Message-ID: <199610091811.OAA07612@crh.cl.msu.edu> In-Reply-To: <Pine.BSF.3.95.961009170321.10204h-100000@minnow.render.com> from Doug Rabson at "Oct 9, 96 05:05:40 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
>
> If you change nfs_maxdelwri to zero using gdb or ddb, what write
> performance do you see? That ought to be the same as the nfs_dwrite==0
> case. I can't figure out why the other iods should get locked out. Are
> you sure that all the reqs are made by the same iod?
>
If we get back to the root of the problem (which isnt the buffering really, its
that the data is going across sooo slowly). The packets look like so:
FreeBSD -> Sun RPC Proc 8 (v2)
data
data
data
data
Sun -> FreeBSD ACK
FreeBSD -> Sun RPC Proc 8 (v2)
data
data
data
data
Sun -> FreeBSD ACK
The problem is that the Sun ACK's are taking 90ms instead of <= 1ms.
Under V3 We get:
FreeBSD -> Sun RPC Proc 7
data
data
data
data
Sun -> FreeBSD ACK
The ACK's now come in at about half the time (~45ms), still dismal, still
lousy transfer rates (sub 200ish).
Now, a SGI talking to the Sun looks like (v3 I beleive):
SGI -> Sun RPC Proc 6
SGI -> Sun RPC Proc 7
data
data
data
data
Sun -> SGI ACK
Sun -> SGI ACK
The SUN ACK's now come in at the <= 1ms they should, and we get transfer rates
into the 900K/sec.
The question is what is Proc 6, and why is the SGI doing it, and why is it sooo
much faster?
-Crh
Charles Henrich Michigan State University henrich@msu.edu
http://pilot.msu.edu/~henrich
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610091811.OAA07612>