From owner-freebsd-scsi Fri Feb 12 19:49:08 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA21235 for freebsd-scsi-outgoing; Fri, 12 Feb 1999 19:49:08 -0800 (PST) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA21230 for ; Fri, 12 Feb 1999 19:49:06 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.2/8.8.5) id UAA38439; Fri, 12 Feb 1999 20:47:01 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199902130347.UAA38439@panzer.plutotech.com> Subject: Re: Is CAM slower than the old SCSI layer for JAZ drives? In-Reply-To: <19990212191723.A644@internal> from Andre Albsmeier at "Feb 12, 1999 7:17:23 pm" To: andre.albsmeier@mchp.siemens.de (Andre Albsmeier) Date: Fri, 12 Feb 1999 20:47:01 -0700 (MST) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Andre Albsmeier wrote... > I have made an odd observation. Copying a large file from > my 100MBit net to a 2GB jaz, I noticed that 3.1-BETA took > a lot more time than it used to under 2.2.8-STABLE. > Exact (well, as exact as dd can be) measurements told me: > > 3.1-BETA: > 135447409 bytes transferred in 178.638903 secs (758219 bytes/sec) > > 2.2.8-STABLE: > 135447409 bytes transferred in 87.649259 secs (1545334 bytes/sec) > > This is nearly exact twice the time for 3.1 than for 2.2.8. > The network is okay, a dd to /dev/null gives me: > 135447409 bytes transferred in 13.553990 secs (9993176 bytes/sec) > > Copying the same file to a "normal harddrive" results in: > 135447409 bytes transferred in 19.716693 secs (6869682 bytes/sec) > This I would assume as OK. > > Is there something special in the CAM layer that has to do > with IOMEGA drives (apart from the quirk entry for tagged > queuing in cam_xpt.c)? > > Should I do some debugging? Hmm, it certainly seems odd that CAM would be slower than the old SCSI layer. I would expect the performance to be about the same for something like that. Perhaps you could try a few experiments: - try disabling the quirk entry in the transport layer (i.e., enable tagged queueing) - try enabling tagged queueing, but set the maximum number of I/O requests to 4. I will send you some patches to camcontrol in a separate piece of mail that will enable you to set the number of tagged openings for the device on the fly, without having to recompile your kernel. You will only be able to set them to values within the range set by the maximum and minimum values in the transport layer quirk table. [ The reason I'm not sending the patches to the list is that they aren't quite ready for public consumption. ] Anyway, if you set the minimum and maximum for your Jaz drive to 0 and 255 respectively in the quirk table, you can use camcontrol to experiment with different settings for the number of available tagged openings. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message