Date: Sun, 21 Mar 1999 19:12:42 -0700 (MST) From: "Kenneth D. Merry" <ken@plutotech.com> To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: cvs commit: src/sys/cam cam_xpt.c Message-ID: <199903220212.TAA63607@panzer.plutotech.com> In-Reply-To: <19990321110510.38582@uriah.heep.sax.de> from J Wunsch at "Mar 21, 1999 11: 5:10 am"
next in thread | previous in thread | raw e-mail | index | archive | help
J Wunsch wrote...
> 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)
One question I have is this -- when you say 1 tag, did you do disable
tagged queueing like this:
camcontrol negotiate -n da -u 3 -T disable
Otherwise, you won't be able to disable tagged queueing.
Also, you'll probably want to make sure that the size of the file that
bonnie writes out is somewhat larger than your RAM, to eliminate the
effects of FreeBSD's cache...
> (*) 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)
>
What does it print out for the sync parameter? My guess is that it must be
0 or something... From looking at scsi_calc_syncsrate(), it can't handle a
sync paramter of 0.
Ken
--
Kenneth Merry
ken@plutotech.com
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?199903220212.TAA63607>