From owner-freebsd-scsi Sun Mar 21 2:20:56 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id A377D14F9B for ; Sun, 21 Mar 1999 02:20:54 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id LAA23639; Sun, 21 Mar 1999 11:20:34 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.3/8.9.1) id LAA49523; Sun, 21 Mar 1999 11:05:10 +0100 (MET) (envelope-from j) Message-ID: <19990321110510.38582@uriah.heep.sax.de> Date: Sun, 21 Mar 1999 11:05:10 +0100 From: J Wunsch To: freebsd-scsi@FreeBSD.ORG Cc: ken@plutotech.com Subject: Re: cvs commit: src/sys/cam cam_xpt.c Reply-To: Joerg Wunsch References: <199903141441.PAA71438@qix> <199903142053.NAA13995@panzer.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199903142053.NAA13995@panzer.plutotech.com>; from Kenneth D. Merry on Sun, Mar 14, 1999 at 01:53:10PM -0700 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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