From owner-freebsd-scsi Sat Feb 13 07:15:23 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA13691 for freebsd-scsi-outgoing; Sat, 13 Feb 1999 07:15:23 -0800 (PST) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA13679 for ; Sat, 13 Feb 1999 07:15:17 -0800 (PST) (envelope-from andre.albsmeier@mchp.siemens.de) X-Envelope-Sender-Is: andre.albsmeier@mchp.siemens.de (at relayer david.siemens.de) Received: from salomon.siemens.de (salomon.siemens.de [139.23.33.13]) by david.siemens.de (8.9.3/8.9.3) with ESMTP id QAA06064 for ; Sat, 13 Feb 1999 16:15:12 +0100 (MET) Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [146.180.31.23]) by salomon.siemens.de (8.9.3/8.9.3) with ESMTP id QAA21626 for ; Sat, 13 Feb 1999 16:15:14 +0100 (MET) Received: (from daemon@localhost) by curry.mchp.siemens.de (8.8.8/8.8.8) id QAA02705 for ; Sat, 13 Feb 1999 16:15:14 +0100 (CET) Date: Sat, 13 Feb 1999 16:15:13 +0100 From: Andre Albsmeier To: Julian Elischer Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Is CAM slower than the old SCSI layer for JAZ drives? Message-ID: <19990213161513.B719@internal> References: <199902130347.UAA38439@panzer.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: ; from Julian Elischer on Sat, Feb 13, 1999 at 12:16:08AM -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 13-Feb-1999 at 00:16:08 -0800, Julian Elischer wrote: > > On Fri, 12 Feb 1999, Kenneth D. Merry wrote: > > > 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) > > I've heard from several sources (notibly Simon Shapiro) > that something in the CAM code is slowing things down. > However I don't think it's likely to be a theoretical thing, > but possibly an implimentation gothca.. in THEORY CAM should > equal or surpass the old system, with many organisational advantages. I just mailed Kenneth the results of some experiments he asked me to do. Apart from that, I observed the following: ----------------------- snip --------------------------------- Than I made the experiments by writing a 50.000.000 bytes files to the JAZ. It came from an Ultra-Wide drive which hangs on ahc0. The JAZ is attached to ahc1. Here I made a curiuos observation: Directly after booting (with min/max tags set to 0/255 in the kernel and without ever having used camcontrol) I copied the file from the Ultra-Wide disk on ahc0 onto the JAZ on ahc1: 50000000 bytes transferred in 52.256570 secs (956817 bytes/sec) Being astonished about these 950k I tried it once again: 50000000 bytes transferred in 69.072540 secs (723877 bytes/sec) It was exactly the same command but now, I assume, the file came from the kernel buffers. So there was no activty on the source disk. Than I unmounted the source disk and remounted it. I assume that the kernel now invalidated its buffers for that drive which means that the source file will have to be read again: 50000000 bytes transferred in 53.233707 secs (939255 bytes/sec) Is it possible that the JAZ gets somekind of saturated or something like this ?!? When the kernel has to read the file from the source disk I assume that there are small interruptions in the data flow to the JAZ. The second time all data comes directly from the memory and the bytes are being pumped like hell to the JAZ... Maybe I am talking bullsh*t as well :-) ------------------------ snap ---------------------------- -Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message