From owner-freebsd-scsi Fri Oct 15 14:47:51 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from front6m.grolier.fr (front6m.grolier.fr [195.36.216.56]) by hub.freebsd.org (Postfix) with ESMTP id 3E4EC14A26 for ; Fri, 15 Oct 1999 14:47:40 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-116-229.villette.club-internet.fr [194.158.116.229]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id XAA18856; Fri, 15 Oct 1999 23:47:26 +0200 (MET DST) Date: Sat, 16 Oct 1999 00:09:29 +0200 (MET DST) From: Gerard Roudier X-Sender: groudier@localhost To: "Kenneth D. Merry" Cc: "Chris D. Faulhaber" , Andrew Gallatin , scsi@FreeBSD.ORG Subject: Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 In-Reply-To: <199910151940.NAA51114@panzer.kdm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 15 Oct 1999, Kenneth D. Merry wrote: > Gerard Roudier wrote... > > On Fri, 15 Oct 1999, Chris D. Faulhaber wrote: > >=20 > > > da0: Fixed Direct Access SCSI-2 device > > > da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) > > > da0: 8683MB (17783204 512 byte sectors: 255H 63S/T 1106C) > > >=20 > > > After enabling tagged queuing on this drive (by removing the quirk en= try) > > > and found performance about 10% slower. > >=20 > > What kind of performance are you measuring ? Tagged command queuing is > > intended to improve _multithreaded IOs that is a lot more realistic IO > > pattern than single-threaded sequential IO. I also read some decrease o= f > > performance for DCAS for single-threaded sequential IO when increasing > > number of tags. Unless, guys, you just want to eat the cake and to have > > it, I donnot see any serious problem for these drives. May-be there is > > some room for improvement in their firmware. They should _not_ have bee= n > > quirked to 0 tags, in my opinion, if the decrease of performance observ= ed > > is for sequential IOs. At most, user should be advised to use a > > reasonnable number of tags or the quirk should have been more soft.=20 > >=20 > > For the DCAS, the decrease of performances has been observed for > > sequential write IOs that is a great stress for a disk when write behin= g > > caching is enabled with tags enabled, but still nothing has been report= ed > > for read and especially multithreaded read IOs. Castrating a disk model= =20 > > regarding tags due to such unreaslistic results has been unserious in m= y > > opinion.=20 >=20 > In the case of the DCAS drives, the PR author (see kern/10398) did > extensive tests with bonnie, and found that both the number of random see= ks Random IO decrease is surprising given the small number of transactions per second and the small IO bandwidth needed for the test. Anyway, such a testing just makes the drive prefetch data and then makes it have to throw prefetched data away. Using simultaneous sequential IO streams may take advantage of the prefetching (such a testing is more realistic than Bonnie seeks). Some simple combination of usual UNIX commands is sometimes a far better testing than inappropriate benchmarks. > per second and sequential write throughput decreased as the number of > concurrent transactions allowed increased. Sequential read performance > did not vary significantly when the number of tags was changed. > As for the WD drives, if you'd like to find someone with a drive who is > willing to run through a full set of tests at various numbers of transact= ions, > feel free. If you can show that the number of tags should be set to > something other than 0, we can change it. I donnot know of WD drives and will probably never know about :-), but just based on the postings, I just thought that these drives were not proven to deserve a so severe punishment. G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message