From owner-freebsd-current Tue Jul 29 15:24:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA16932 for current-outgoing; Tue, 29 Jul 1997 15:24:36 -0700 (PDT) Received: from sos.freebsd.dk (sos.freebsd.dk [195.8.129.33]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA16922; Tue, 29 Jul 1997 15:24:24 -0700 (PDT) Received: (from sos@localhost) by sos.freebsd.dk (8.8.6/8.7.3) id AAA00624; Wed, 30 Jul 1997 00:24:36 +0200 (MEST) From: Søren Schmidt Message-Id: <199707292224.AAA00624@sos.freebsd.dk> Subject: Re: code talks: announcing EIDE bus master patches In-Reply-To: <19970729221036.52544@mi.uni-koeln.de> from Stefan Esser at "Jul 29, 97 10:10:36 pm" To: se@FreeBSD.ORG (Stefan Esser) Date: Wed, 30 Jul 1997 00:24:36 +0200 (MEST) Cc: freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In reply to Stefan Esser who wrote: > On Jul 29, Søren Schmidt wrote: > > > > Sure, on my dev machine (P6@233Mhz-Natoma/64MB/2*Maxtor 84000A6) > > This seems to be an OEM version of the 83840a6, if I > interpret the data sheets on their web page correctly. > AFAIK the fastest EIDE drive series on the market today! Well, I think they are mainline drives, you can buy them on every corner here in DK land for about US$250. > And the result is apparently *higher* CPU load, at least > if you (did) trust the numbers reported by Bonnie ... Well its most visible in the "per char" mesurements, I guess time is spent processing the inividual chars through the I/O system, the increase in used time is almost linear. > But the "per char" read performance improvement indicates > what's really going on: CPU cycles spent in the interrupt > handler probably account for the 4.5MB/s mark in the PIO > case, while raw data rate of the disk is approached with > the DMA driver. Exactly! > But writes are still significantly slower than reads, which > makes me think, that one revolution of the media is lost per > 64KB written ... I think it might be some kind of interaction with the drives cache, but our driver might be guilty too.. > > Not bad, for a "simple" software upgrade :) > > True! But there is still room for improvement ... ;) Well, I don't think we are going to get much more performance out of it, at least not in an order like this, but there sure is room for cleaning up the driver, which I'll eventually get to if/when I get the time... > > It has improved my worldstone by ~10% if that counts for real world use.. > > Yes, one thing that is often underestimated is the fact, > that while PIO mode transfers consume only a small fraction > of the cycles of a fast CPU, but they tend to consume them > exactly at the time, when the CPU is highly loaded anyway. Yep. Now we only need ATA drives that can overlap commands. It seems they are getting there, but its a mess still. When that settles (and we get new drives :) ), we can get even a wee bit more performance... > Thanks for sending those very interesting Bonnie results! You're welcome :) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end ..