Date: Wed, 20 Mar 1996 22:28:34 -0800 From: "Justin T. Gibbs" <gibbs@freefall.freebsd.org> To: FreeBSD-scsi Cc: Ulrich.Windl@rz.uni-regensburg.de Subject: Simple Tagged Commands and Starvation Message-ID: <199603210628.WAA27403@freefall.freebsd.org> In-Reply-To: Your message of "Wed, 20 Mar 1996 08:35:23 PST." <199603201635.IAA21314@dandelion.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I would like to hear other's opinions on this subject and possible ways to avoid the problem without arbitrarily penalizing commands entered into the queue. The problem may be agravated in Linux by using a large number of tags and a short timeout (Ulrich, FreeBSD uses a 10sec timeout and the two drivers that use tagged queueing default to 4 tags max per target which seems to offer the best performance under various benchmarks -- I have no idea what Linux uses). Since we are planning to push the dictation of queue message types up into the generic SCSI layer, it may turn out that we can solve this problem solely by enforcing ordered tags for syncronous writes. I'm also wading through the SCSI spec again in the hopes of an alternate way out, but it doesn't look good. On a totally different note... is there any chance you might release your Buslogic driver under a BSD copyright, Ulrich? I've placed the BSD Buslogic driver on my TODO list (it doesn't support tagged queueing yet), but it sounds like you've already forged a great relationship with Buslogic and I'd hate to re-invent the wheel. If your uncomfortable with re-licensing the code, perhaps you can share some contact info for Buslogic? It sounds like there much easier to deal with than Adaptec, and it would be a nice change of pace for me to work on a higher level driver compared to writing the firmware for the FreeBSD/Linux aic7xxx driver. 8-) > Date: Tue, 19 Mar 1996 23:33:28 -0800 > From: "Justin T. Gibbs" <gibbs@freefall.freebsd.org> > > All devices that support tagged queuing provide some method internally to > ensure that simple queued transactions aren't starved. > >Much as it would be nice, I'm afraid this statement is not correct. Back in >late december I was beta testing the BusLogic BT-948 UltraSCSI Host Adapter >and thought I'd found a firmware bug because timeouts were occurring in this >fashion. When I reproduced the problem at BusLogic with their firmware >engineer, we determined using a SCSI Bus Analyzer that there was nothing wrong >with the firmware, but the disk drive itself was leaving commands disconnected >indefinitely. Nothing I can find in the SCSI-2 specification indicates that >disks are responsible for avoiding starvation, though it would certainly make >sense. The only solutions for this problem were to either use an occasional >ordered queue tag to force commands to be executed, or to pause SCSI activity >to the drive long enough for the queue to drain. > >Furthermore, I have seen this same form of starvation occur on several >different brands of disk drives, and the fix I installed corrected timeout >problems for a number of other people as well. More recently, adding similar >code to the ncrBsd2Linux driver corrected timeout problems with bonnie. > >I agree that ideally the high level parts of the system should indicate >whatever ordering constraints they have on the queued data transfers. > > Leonard -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations ===========================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603210628.WAA27403>