From owner-freebsd-arch Fri Nov 12 3:58:43 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 6818614C96 for ; Fri, 12 Nov 1999 03:58:38 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id MAA15334 for ; Fri, 12 Nov 1999 12:58:37 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id MAA26182 for freebsd-arch@freebsd.org; Fri, 12 Nov 1999 12:58:36 +0100 (MET) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id AE35614C96 for ; Fri, 12 Nov 1999 03:58:21 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from p61-ts5.syd2.zeta.org.au (beefcake.zeta.org.au [203.26.10.12]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id XAA19176; Fri, 12 Nov 1999 23:04:27 +1100 Date: Fri, 12 Nov 1999 22:58:09 +1100 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: Simon Shapiro Cc: freebsd-arch@freebsd.org Subject: Re: I/O Evaluation Questions (Long but interesting!) In-Reply-To: <38290C04.8FC73862@simon-shapiro.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 10 Nov 1999, Simon Shapiro wrote: > Bruce Evans wrote: > > > We run circles around NT in the Random I/O department, > > > but take a beating in the sequential I/O arena; > > > For about the same hardware, they do 98 MB/Sec, > > > I cannot get more than 45. > > > > I've always though FreeBSD has the opposite problem. > > Nope. I am getting 167MB/Sec for random block device. I didn't believe this, but later mail explains that it must be due to buffering. > We are almost nine times faster on random WRITE (and I > am comparing RAW I/O here to buffered there), twice as > fast on random READ (again our RAW vs. their buffered. > > If you compare our block perfromance to theirs, we are > almost fourty times faster. This is almost certainly due to our buffer cache actually working for the i/o mix in your test. Having the buffer cache unified with vm helps here by removing arbitrary limits on the effective size of the buffer cache. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message