QAS issues raised in the 3/16/98 SPI-3 Working Group

Richard Moore richard_moore at
Tue Mar 17 13:47:56 PST 1998

* From the T10 (formerly SCSI) Reflector (t10 at, posted by:
* "Richard Moore" <richard_moore at>
Rev 7 of the QAS proposal, which I presented yesterday, stirred up a
number of issues. Here I'll only try to list those issues and, over the
next few weeks, I'll try to nail down some answers. I'm putting this
list out to make sure it's complete; if anyone catches any omissions
please post them.

1. Should we require the 0x55 QAS message to be at the beginning of the
Message In phase?
PRO: Doing so makes snooping easier, since if the 0x55 is seen as the
first byte it is unambigous.
CON: (1) The 0x55 is already unambiguous since it will either be the
only byte in the phase or will always follow a DISCONNECT or COMMAND
COMPLETE message. (2) Some implementors might want a hardware QAS
disconnect mechanism. After firmware sends DISCONNECT or COMMAND
COMPLETE, it activates the hardware mechanism which then automatically
sends the QAS message, waits for ACK, and proceeds to the QAS
arbitration phase without further firmware intervention. Moving the 0x55
to the front means that the message has to be sent by firmware.

2. Is the 8 ns minimum REQ and ACK assertion for the QAS message
sufficient? If not, what number is?

3. Will the proposed timings work with two 25-m segments connected by an
expander? (For that matter, will "legacy" arbitration work in such an
3a. Before answering 3, consider whether the signal propagation can be
considered incident-wave or reflected-wave.

4. What rules should be enforced for fairness in QAS devices? (Note in
all cases, fairness is optional for non-QAS devices).
    Option 1: Fairness required for QAS-enabled devices, regardless of
whether the current arbitration is QAS or normal.
    Option 2: Fairness required for QAS-enabled devices during QAS
cycles, but optional during normal cycles.
    Option 3: Fairness is completely optional for QAS-enabled devices.

5. Lockout or deadlock issues. These might arise from the mixing of QAS
devices with non-QAS devices, and from the interaction between QAS and

6. Initiator preemption has been taken out. Some people wanted it kept
PRO: (1) Less latency in command delivery if initiators have an
advantage in getting on the bus. (2) Might be used as a
deadlock-breaking mechanism?
CON: (1) Takes away from the timing budget (i.e., either we have to make
QAS slower, or we don't support total bus lengths exceeding 25 m). (2)
Seems to fly in the face of fairness (i.e., we have a fairness algorithm
to make all devices equal, but with initiator preemption, some devices
will be more equal than others). (3) More latency in completion of
commands by targets. (4) We need to explore whether deadlocks can really
occur, and if so, are there other ways to break out of them?

7. Negotiation issues. Which of the following three interpretations of
the ENABLQAS bit in the IUTR message (see the Packetized SCSI proposal)
are required. Rev 7 requires the first and second interpretations to be
applied. I didn't hear any support for the third interpretation but the
second was called into question.
    (1) In order for target A to disconnect from initiator B, A and B
must have negotiated with each other to enable QAS. PRO: This must be a
requirement, to keep targets from sending the QAS message to initiators
that don't support it. CON: I don't know of any "con" argument.
    (2) In order for device C to select or reselect device D, C and D
must have negotiated with each other to enable QAS. PRO: This may have
some value; at least, it's conservative in that it doesn't assume that
every legacy device will be able to respond to QAS selection. CON: It
doesn't seem likely that there are devices that won't respond as long as
they see a valid selection.
    (3) In this interpretation, in order for device C to participate in
QAS following A's sending of the QAS message to B, it must have
negotiated to enable QAS with either A or B. PRO: I don't know; I've
never seen any advantage to this interpretation. CON: (1) Difficult to
implement, since devices have to keep track of who's currently connected
to know whether QAS snooping is allowed or not. (2) Unnecessarily limits
participation in QAS.

  Richard Moore
  Adaptec Irvine Technology Center

* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list