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>