From owner-freebsd-current  Tue Oct  3 17:04:10 1995
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id RAA01406
          for current-outgoing; Tue, 3 Oct 1995 17:04:10 -0700
Received: (from dyson@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id RAA01398
          ; Tue, 3 Oct 1995 17:04:08 -0700
From: John Dyson <dyson>
Message-Id: <199510040004.RAA01398@freefall.freebsd.org>
Subject: Re: lmbench 1.1.5 vs 2.2-current
To: bde@zeta.org.au (Bruce Evans)
Date: Tue, 3 Oct 1995 17:04:08 -0700 (PDT)
Cc: current@freebsd.org
In-Reply-To: <199510032057.GAA30471@godzilla.zeta.org.au> from "Bruce Evans" at Oct 4, 95 06:57:52 am
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Content-Length: 1603      
Sender: owner-current@freebsd.org
Precedence: bulk


>2.2-current seems to be significantly slower than 1.1.5 in many areas.
>
>These benchmarks were run on the same machine except for a faster disk
>and a possibly different L2 cache setting for 2.2-current.
>
>The faster disk and clustering speed up the file reread benchmark by a
>factor of 8.

Yep, it is mostly the clustering, and the larger, on-demand, buffer cache.

>The local tcp bandwidth is anomalously slow in
>2.2-current.

No it isn't, the flag that is set before the TCP test in the benchmark
really screwing up the results.  Either we don't support it correctly,
or something strange is happening.

>mmap has been tuned for faster access at a cost of
>increased setup overhead in 2.2-current.

Yep, the amount of time to map a 100-200K (or larger segment) is
only a few page fault times.  I think that is a very advantageous
tradeoff, considering it could take 25-50 page fault times otherwise.

>Otherwise, these benchmarks
>show unexplained lossages (probably mostly due to vfs bloat) of 10-40%
>for 2.2-current.

Interesting, the VFS code adds THAT much overhead to the TCP/UDP results???
(Maybe, but I don't think so)

I think that a properly ported lmbench, whose results are properly analyzed
would show that the new system is much faster in several areas and roughly
the same or sometimes a bit slower otherwise.  The lmbench summary scripts don't
even appear to produce the correct results given the raw data files produced
(at least for me.)  I always quote the raw data file output -- don't have
time or inclination to fix the perl/awk/whatever scripts.

John
dyson@freebsd.org