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
forthcoming.
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
SOAF.
  _____  
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Stephen
FINCH
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
back-to-back
EOAF-SOAF (which should be allowed). After sending one IDENTIFY, must be
immediately ready
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.
Regards,
Steve Finch
STMicroelectronics



More information about the T10 mailing list