From owner-freebsd-lite2  Wed Oct  9 11:12:20 1996
Return-Path: owner-lite2
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id LAA17082
          for lite2-outgoing; Wed, 9 Oct 1996 11:12:20 -0700 (PDT)
Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA17073
          for <lite2@freebsd.org>; Wed, 9 Oct 1996 11:12:17 -0700 (PDT)
Received: (from henrich@localhost) by crh.cl.msu.edu (8.7.6/8.7.3) id OAA07612; Wed, 9 Oct 1996 14:11:22 -0400 (EDT)
From: Charles Henrich <henrich@crh.cl.msu.edu>
Message-Id: <199610091811.OAA07612@crh.cl.msu.edu>
Subject: Re: Delayed write patch
To: dfr@render.com (Doug Rabson)
Date: Wed, 9 Oct 1996 14:11:22 -0400 (EDT)
Cc: simokawa@sat.t.u-tokyo.ac.jp, lite2@freebsd.org
In-Reply-To: <Pine.BSF.3.95.961009170321.10204h-100000@minnow.render.com> from Doug Rabson at "Oct 9, 96 05:05:40 pm"
X-Mailer: ELM [version 2.4ME+ PL22 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-lite2@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>
> 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