sas2r08 Editor's Note 35 (Clause 7.9)
Elliott, Robert (Server Storage)
Elliott at hp.com
Mon Feb 19 10:52:08 PST 2007
Formatted message: <A HREF="r0702190_f.htm">HTML-formatted message</A>
Attachment #1: <A HREF="r0702190_smime-1.p7s">smime-1.p7s</A>
The editor's note describes a potential future change that has been
discussed (most recently at the last SAS editor's meeting, which almost
nobody bothered to attend). If such a proposal does come to fruition, it
would include the necessary state machine changes.
I don't know why you would prefer people to be totally surprised by such a
proposal and not warn them with an editor's note that such a change might be
If you really meant you are not in favor of the concept described by the
note (rather than just want the editor's note removed), then that's a fair
discussion. The reason it's suggested is that SAS tolerates single-bit
errors with minimal disruption in most cases (via redundant primitives,
transport layer retries, 1 ms timeouts, etc.). A single-bit error in the
IDENTIFY frame, however, requires redoing the entire link reset sequence -
which takes much longer than 1 ms, increments error counters, and triggers
Broadcast (Change). Sending IDENTIFY 3 times would improve SAS-2 phys'
tolerance for such problems.
Unless the bit error occurs during the SOAF primitive, it probably won't
help a SAS-1.1 receiver, which per SL_IR ignores everything after the first
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Stephen
Sent: Friday, February 16, 2007 3:51 PM
To: T10 Reflector
Subject: sas2r08 Editor's Note 35 (Clause 7.9)
Here is the text of the referenced editor's note.
Editor's Note 35: To better tolerate single-bit errors, it might be prudent
to require SAS-2 phys
transmit IDENTIFY address frame 3 times rather than just once. Although the
frame includes a
CRC, there is no NAK to cause retransmission if it fails - the entire link
reset sequence must be
restarted if a bit error corrupts the IDENTIFY address frame. If it were
transmitted 3 times, that
would not be necessary. 3 times would cover DFE error propagation between
EOAF-SOAF (which should be allowed). After sending one IDENTIFY, must be
to handle an incoming OPEN. Can stop sending additional IDENTIFYs if that
happens (or keep
sending them - it shouldn't matter to the recipient).
I would like this editor's not removed from the draft standard.
This note is in conflict with the SL_IR statemachine.
I have seen no proposal to change the link layer functionality as suggested
by this note and,
until such a proposal is made I believe this does nothing but add confusion.
More information about the T10