Date: Sat, 16 Oct 1999 00:09:29 +0200 (MET DST) From: Gerard Roudier <groudier@club-internet.fr> To: "Kenneth D. Merry" <ken@kdm.org> Cc: "Chris D. Faulhaber" <cdf.lists@fxp.org>, Andrew Gallatin <gallatin@cs.duke.edu>, scsi@FreeBSD.ORG Subject: Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 Message-ID: <Pine.LNX.3.95.991015234921.543A-100000@localhost> In-Reply-To: <199910151940.NAA51114@panzer.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 15 Oct 1999, Kenneth D. Merry wrote: > Gerard Roudier wrote... > > On Fri, 15 Oct 1999, Chris D. Faulhaber wrote: > >=20 > > > da0: <WDIGTL WDE9100 1.50> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.95.991015234921.543A-100000>