Date: Sun, 21 Mar 1999 11:05:10 +0100 From: J Wunsch <j@uriah.heep.sax.de> To: freebsd-scsi@FreeBSD.ORG Cc: ken@plutotech.com Subject: Re: cvs commit: src/sys/cam cam_xpt.c Message-ID: <19990321110510.38582@uriah.heep.sax.de> In-Reply-To: <199903142053.NAA13995@panzer.plutotech.com>; from Kenneth D. Merry on Sun, Mar 14, 1999 at 01:53:10PM -0700 References: <199903141441.PAA71438@qix> <199903142053.NAA13995@panzer.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
As Kenneth D. Merry wrote:
> The issue isn't really whether it's "poor performance" or "poor for a wide
> drive", but whether the performance you're getting out of the drive is what
> the drive is capable of.
Just FWIW, i've finally applied Ken's patches to camcontrol (*), and
tested my DCAS 34330 with various tagged queuing parameters. The
results seem to basically confirm the results in the audit-trail of PR
10398, except i think the best balanced results are for 2 tags on my
drive.
Note that the following is running on my /tmp partition which is at
about 80 % offset from the beginning of the drive. This probably
explains why the figures are slower than those in PR 10398 although
the raw data rate on the outer tracks (dd if=/dev/rda1 of=/dev/null)
is about the same.
So 1 or 2 tags, i don't care that much after seeing this.
NCR 53C810 10 MHz 8 bit
IBM DCAS-34330 S65A
-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
t=32,qm=0 100 3969 96.7 4435 39.1 1891 21.0 4079 94.5 5754 47.5 84.2 6.6
t=32,qm=1 100 3806 93.4 3167 27.4 1899 21.3 3911 91.1 5102 42.0 84.9 6.7
t=2,qam=0 100 3889 97.1 5500 45.4 2184 23.2 4125 95.8 5748 47.5 84.1 6.7
t=2,qam=1 100 3968 96.6 5408 46.8 2224 24.5 4209 97.6 5403 44.5 74.5 6.1
t=1,qam=0 100 3975 96.7 5446 43.8 1875 19.7 4175 97.2 5663 45.3 78.5 6.2
`t' - number of tags
`qm', `qam' - queue algorithm modifier (0 - restricted reordering,
1 - unrestricted reordering allowed; mode page 10)
WCE = 1 for all tests (PR 10398 already confirms violently enough that
disabling the write cache is not a good idea)
(*) In order to prevent camcontrol from coredumping on my SONY SMO, i
had to apply this patch:
--- camcontrol.c.orig Sun Mar 21 10:22:53 1999
+++ camcontrol.c Sun Mar 21 10:58:14 1999
@@ -1926,9 +1926,11 @@
fprintf(stdout, "%ssync parameter: %d\n", pathstr,
cts->sync_period);
- freq = scsi_calc_syncsrate(cts->sync_period);
- fprintf(stdout, "%sfrequencey: %d.%03dMHz\n", pathstr,
- freq / 1000, freq % 1000);
+ if (cts->sync_period != 0) {
+ freq = scsi_calc_syncsrate(cts->sync_period);
+ fprintf(stdout, "%sfrequencey: %d.%03dMHz\n", pathstr,
+ freq / 1000, freq % 1000);
+ }
}
if (cts->valid & CCB_TRANS_SYNC_OFFSET_VALID)
--
cheers, J"org
joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
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?19990321110510.38582>