Should PS_REQ, PS_ACK be extended type?

Day, Brian Brian.Day at
Wed Feb 18 09:46:17 PST 2009

* From the T10 Reflector (t10 at, posted by:
* "Day, Brian" <Brian.Day at>
Using a single primitive sequence type is definately not preferred, so that
we can tolerate bit errors on these primitives.  The particular case
discussed previous in a working group was a corrupted PS_ACK results in one
device going down into thee power management state, and the other seeing a
loss-of-sync and restarting the whole link reset sequence.  
SAS-2 had quite a few changes to make it more tolerant of bit errors and
prevent link reset sequences, so we don't want to take a backward step on
that philosophy.
Now, relative to the issue at hand about extended sequence type.  I agree
that since the receiver of the extended primitive sequence decodes each dword
as a primitive (refer to section of the rev 15 draft SAS-2 spec), it
does mean that there are then three PS_ACK / PS_NAK Received messages
generated.  This can cause some theoretical race conditions in the spec state
machines I think.
So I suggest a different alternative would be to change these to redundant
primitives.  This eliminates the multiple PS_ACK / PS_NAK Received messages,
and still provides bit error tolerance.  This also lines up with our only
other request / response model (kinda) for primitives... the
I'd encourage additional relflector discussion prior to the meeting, if there
are other concerns from other folks.
Other points relative to your original email though:
Re (a) below - There are rules on how often PS_REQ can be sent.  It's sent
one time on entry into the PS_Request state.  It's not sent again until
either getting a PS_ACK / PS_NAK, or the 1ms timer expires.
Re (b) below - Based on previous answer... there is not a condition where
there are multiple outstanding PS_REQs.
Brian Day
LSI Corporation
-----Original Message-----
From: owner-t10 at [mailto:owner-t10 at] On Behalf Of
Gerry.Houlder at
Sent: Monday, February 09, 2009 9:18 AM
To: t10 at
Subject: Should PS_REQ, PS_ACK be extended type?
* From the T10 Reflector (t10 at, posted by:
* Gerry.Houlder at
I have received inquiries from folks looking at implementing the new PS_REQ
(x), PS_ACK, and PS_NAK primitives. They have pointed out that all other
cases in SAS where primitives use a request/ response model, the primitives
are the single type.
Use of the extended type primitive for request/ response cases causes a
number of implementation issues.
(a) How does the receiving end differentiate between a single PS_REQ (x) that
has idle dwords between them and possible multiple PS_REQ (x) primitives
where some of the duplicates are lost? There are no rules about how often
PS_REQ (x) can be sent.
(b) Similar race condition issues can arise when multiple PS_REQ (x) have
been sent and the sending end has to match up PS_NAK and PS_ACK responses
with the appropriate SP_REQ (x).
It has been suggested that it is simpler to use single type PS_REQ (x),
PS_NAK, and PS_ACK. If we are concerned about missing a request or response,
the function can be retried after the 1 msec timeout expires for a couple of
times before giving up. This would allow these primitives to use similar
generation/ detection logic as other request/ response primitives used in SAS
(this logic is often in hardware).
Please discuss this subject with appropraite hardware designers ar your
company. I ask that this subject be covered in the Protocol WG as part of
discussion of the intergration of proposals 08-015, 08-206, et. al.
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at
* 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