Date: Sat, 16 Oct 1999 01:55:36 +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.991016013306.1516B-100000@localhost> In-Reply-To: <199910152214.QAA52284@panzer.kdm.org>
index | next in thread | previous in thread | raw e-mail
On Fri, 15 Oct 1999, Kenneth D. Merry wrote: > Gerard Roudier wrote... > > On Fri, 15 Oct 1999, Kenneth D. Merry wrote: > > > Gerard Roudier wrote... > > > > For the DCAS, the decrease of performances has been observed for > > > > sequential write IOs that is a great stress for a disk when write behing > > > > caching is enabled with tags enabled, but still nothing has been reported > > > > for read and especially multithreaded read IOs. Castrating a disk model > > > > regarding tags due to such unreaslistic results has been unserious in my > > > > opinion. > > > > > > 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 seeks > > > > 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. > > Well, if you've got ideas for a better benchmark, why not write one, or > point people to a better benchmark? The problem is indeed the 'one' benchmark approach for deciding about the average of the infinity of possible situations. I will never write any benchmark program for the reason I may need a different one based on what I want to check or test at any time. There is enough tools under UNIX to build some simple scenarion on need and to perform several runs with different configurations of the parameters you want to test actual effects on your scenario and then compare results. For tagged queueing depth effects, usual benchmarks have proven to be inappropriate. For example, simply running N concurrent file readings (different files) from the same disk gives more relevant results than Bonnie and it takes minutes to set it up. Indeed, this is not enough for the results to have full relevance, this was just the simplest example that comes to mind. > Bonnie may not be a "great" benchmark, but it's better than a simple > sequential I/O benchmark. And it's more precise than just telling people > to run a bunch of random UNIX commands. The ramdom approach looks to me as irrelevant that the single-threaded IO approach regarding effects of tagged commands. > Greg Lehey's rawio program (ftp://ftp.lemis.com/pub/rawio.tar.gz) seems > like it might do a reasonable job (I haven't used it, however), but the > only problem with it is that it works on raw devices. (There's not much > you can do to get around that if you want to avoid possible buffer cache > interactions that come with going through the filesystem.) Thanks for the URL. Will have a look to this program. Gérard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the messagehome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.95.991016013306.1516B-100000>