From owner-freebsd-scsi Sat Feb 21 08:31:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA11319 for freebsd-scsi-outgoing; Sat, 21 Feb 1998 08:31:18 -0800 (PST) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from ha1.rdc1.az.home.com (siteadm@ha1.rdc1.az.home.com [24.1.240.66]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA11301 for ; Sat, 21 Feb 1998 08:31:16 -0800 (PST) (envelope-from straka@home.com) Received: from straka.motorvation.com ([24.1.209.47]) by ha1.rdc1.az.home.com (Netscape Mail Server v2.02) with SMTP id AAA279; Sat, 21 Feb 1998 08:31:13 -0800 Message-ID: <34EF018E.41C67EA6@home.com> Date: Sat, 21 Feb 1998 09:32:14 -0700 From: "Richard S. Straka" X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 3.0-971208-SNAP i386) MIME-Version: 1.0 To: "Justin T. Gibbs" CC: scsi@FreeBSD.ORG Subject: Re: very slow scsi performance References: <199802210525.WAA27892@narnia.plutotech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Justin T. Gibbs wrote: > > > This is a big SCSI-I clunker but I've since installed 3 other Atlas > > II's alongside old faithful without any hiccups. Granted, the newer > > 10,000 RPM IBMs spin faster but 7200 rpm is none too shabby. > > The Atlas I did pretty well. The Atlas II has a nasty problem with > the queue full condition that can render tagged queuing useless > unless your queuing algorithm is smart. I'm hopeful that they will > fix it for the Atlas III, but even if they don't, CAM knows how to > deal with this particular type of problem. > > -- > Justin > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message With my Symbios 875 card, I was getting scsi errors indicating the tag queue was full on my Atlas 2 drive. After reading the Atlas 2 manual, I found that the WCE (Writeback Cache Enable) bit was set by default. With this bit set, the drive returns a GOOD status and a TASK COMPLETE after fetching the data and storing it in cache memory. If this bit is not set, GOOD status and TASK COMPLETE is returned only after the data is committed to the media. With the WCE bit set, it looks like the NCR driver kept sending more TAGS until the cache memory filled up. When I set the WCE bit to 0, the scsi errors went away and as long as the number of tags is set high enough (>16) performance did not seem to be adversely effected according to bonnie benchmark runs. regards, Richard Straka To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message