From owner-freebsd-scsi Thu Jun 5 11:54:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA00181 for freebsd-scsi-outgoing; Thu, 5 Jun 1997 11:54:07 -0700 (PDT) Received: from pluto.plutotech.com (root@pluto100.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA00175; Thu, 5 Jun 1997 11:54:05 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id MAA01925; Thu, 5 Jun 1997 12:53:08 -0600 (MDT) Message-Id: <199706051853.MAA01925@pluto.plutotech.com> X-Mailer: exmh version 2.0beta 12/23/96 To: Terry Lambert cc: gibbs@plutotech.com (Justin T. Gibbs), ken@housing1.stucen.gatech.edu, freebsd-smp@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: 2xPP200 vs 2xPP150 In-reply-to: Your message of "Thu, 05 Jun 1997 10:00:17 PDT." <199706051700.KAA20396@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 05 Jun 1997 13:51:43 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >From your description, it seems that it would be worthwhile to >seperate hysteresis for read vs. write, if the write problem is >localized solely to the write path. The problem is that you don't know if a QUEUE FULL is being returned because of a hard or temporary resource limitation. This could occur for different reasons on different devices, because of read activity or write activity. There is also no easy way for you to determine, even in the case of the Quantum, that the QUEUE FULL happened because of write activity. All queued transactions at the time of the QUEUE FULL could be reads, which the writes that actually caused the problem already completed successfully to the caller. Regardless, this is a general problem with the semantics of the QUEUE FULL status on SCSI devices and I'd rather solve it with a generic solution instead of one taylored to a specific device. Hysteresis and some amount of delay before opening the queue up again, may allow us to keep the tag count up even when confronted with the occasional QUEUE FULL due to a temporary resource shortage regardless of the cause of that shortage. > Regards, > Terry Lambert > terry@lambert.org >--- >Any opinions in this posting are my own and not those of my present >or previous employers. > -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations ===========================================