Re 2: 97-199r9

[Richard Moore]

* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* "Richard Moore" <richard_moore at corp.adaptec.com>
*
Gene_Milligan at notes.seagate.com wrote:

>      It does not define the term but it states "The maximum propagation
> delay of any signal on SCSI cables shall be 5,4 ns/m or a maximum
> propagation delay of 135 ns for the entire bus." Propagation delay for the
> entire bus sounds too much like bus propagation delay to me.

A new term could avoid some confusion, but "QAS propagation delay" might not be
best since the samedelay is inherent in legacy arbitration timing. More on this
below.

>      This explains why it is larger, but it does not explain why it is not
> a skosch larger that 270 ns. In addition the requirement in 97-199r9 is <<
> At least two deskew delays, but within a bus propagation delay,>>. I have
> assumed that "deskew delay" is intended to be and will be changed by the
> editor to "system deskew delay" and that the value is 45 ns or 90 ns for
> two of them. Consequently my implementation can comply by choosing 100 ns
> which is 35 ns less than the maximum propagation time on a standard bus and
> >170 ns less than two maximum buses connected through an expander to become
> a single SCSI domain.
>
>      So I reach the conclusion that 200 ns is just a convenient number to
> put a lower bound on performance with QAS since I am not required to wait
> that long - just less than. I mulled over the idea that bus propagation
> delay was of interest to avoid a reflection coming back but that could only
> be dealt with by using a maximum time of the propagation between the
> shortest allowed distances between stubs - an inferred minimum bus length.
> Initially I presumed Bus Propagation delay would be used to ensure driving
> a signal until it reached the far end of the bus but that would require a
> minimum of a bus propagation delay not a maximum.

It *is* "just a convenient number", but it's a significant one. If devices use
larger delays, QASwill break. That's because the arbitration decision point
will occur before IDs of each
participating device can be guaranteed to be seen by all other participating
devices. It could
of course be fixed by extending the QAS arbitration delay but then performance
would suffer,
so you are right about a lower bound being established by these numbers.

I'm open to getting the most gain out of QAS possible, and it might be possible
to tighten
the numbers (the delay we've been discussing, and the QAS arbitration delay) to
squeeze out
a little more speed. I'd like to pose the question, "Is this a good thing to do
or would we be
opening a can of worms?" I think the worst consequence would be that we have to
define one
more term, such as "QAS response delay" or "QAS response time", to use in place
of the "bus
propagation delay". Even so, that would completely supplant "bus propagation
delay" in the
QAS protocol so we would not be any worse off -- we'd be better off in fact
since it also
corrects the terminology problem Gene has brought up.

>      All of this is not to argue against 200 ns but merely to point out
> that I have lost the reason for it and have concluded that the name
> generates confusion.
>
> Gene

I hope this answer alleviates some of the confusion.

--
  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 symbios.com