Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!convex!mic!letni!rwsys!merch!cpe!adaptex!adaptx1!neese
From: neese@adaptx1.UUCP
Newsgroups: comp.periphs.scsi
Subject: Re: SCSI 2 Command Queing
Message-ID: <283400144@adaptx1>
Date: 16 Jun 91 13:07:19 GMT
References: <31293@hydra.gatech.EDU>
Lines: 35
Nf-ID: #R:hydra.gatech.EDU:31293:adaptx1:283400144:000:2006
Nf-From: adaptx1.UUCP!neese    Jun 15 11:20:00 1991


>/* ---------- "SCSI 2 Command Queing" ---------- */
>Excuse me if i posted a similar question but I wasn't sure if I phrased it
>correctly so I will try again.
>SCSI 2 supports tagged command queing which I think means that the host may
>send multiple command requests to the same device. Do most multitasking OSs
>allow this?
>Say for example in an UNIX environment that task 1 made a request
>to disk 1 and before this request is completed task 2 makes a seperate request
>of the same disk 1. Will the OS wait until task 1's request is completed or
>with scsi 2 will the OS go ahead and immdeiately send the second request so
>the two requests are being serviced simultaneously. I think scsi 2 allows this
>however many OSs and device drivers may not yet support this. Does anyone
>know if this is true? Will device drivers need to rewritten for scsi 2 or
>can a controller take care of this? A controller can only forward requests it
>receives and if the OS won't send more than one at a time you're sunk.

An OS, such as UNIX, allows it (I beleive Novelle 386 also).  But the driver
must be structured to do it also.  Many of the drivers written for the 1542
have been single-threaded to each device.  That is, the driver would only allow
one command at a time on a per target basis, but would allow another command
to be started on another device without waiting for the other target to
complete a command.  I haven't seen a driver that didn't allow overlapped
I/O operations for UNIX.  And this is not specific to SCSI-2.  SCSI, from the
original ANSI spec has allowed this type of operation.

Tag queuing requires the driver/adapter to know how to do it, and who it can be
done with.  There are specific messages the driver/adapter must know about and
make provisions for.  It is not something that could be made transparent (at
least very easily) to the driver.

			Roy Neese
			Adaptec Senior SCSI Applications Engineer
			UUCP @  neese@adaptex
				uunet!cs.utexas.edu!utacfd!merch!adaptex!neese