I haven’t seen an update on this
proposal, but I did want to see some discussion prior to the T10 week, so here
goes.
In SAS-2 today a phy sends only
one Identify frame and makes one attempt to receive an Identify. If the
phy receives an SOAF and that address frame is of the wrong length or has
incorrect CRC, the reception attempt fails and the exchange of the Identify
frame fails. The phy does not go into normal operation and a phy reset
sequence is the only option for recovery.
RE: Although that's how the standard is worded, I
suspect some receivers do not give up after the first SOAF, since it differs
from how they parse OPEN address frames.
The goal, as I understand it, is
to allow (not require) a phy to send its Identify frame three times and to
allow it to discard invalid frames and not treat the detection of an invalid
frame as a fatal error. The reception process would time out if no
Identify frame was received before the Receive Identify Timeout timer times
out.
RE: Correct.
The issues, as I see them
are:
1. There is no timing
specified as to the repetition of Identify frames.
The
Identify frames could be sent back-to-back, with no intervening idle dwords,
or they could be spaced far apart, up to something just short of the Receive
Identify Timeout period.
RE: That is the
intent.
It
appears there are implementations that are not capable of receiving
back-to-back frames with no intervening idle dwords. If a phy with such
a receiver were connected to a phy that transmitted the Identify three times
in a row without intervening idle dwords, then the goal of this proposal would
not be obtained.
RE: Any design like that is not compliant with
current SAS rules. In SAS we avoided including any arbitrary
delays in the protocol - we allow SSP frames to be sent
back-to-back (... EOF SOF ...), ACKs and RRDYs to be back-to-back,
etc.
Since there are only two address frames so far
(IDENTIFY and OPEN), back-to-back address frames are rare so
far.
This is legal today:
(SOAF ...IDENTIFY address frame ... EOAF) (SOAF ...
OPEN address frame ... EOAF)
An expander can almost send back-to-back OPEN address
frames in an unusual case:
1. End device sends an OPEN address frame to an
expander.
2. Expander sends an OPEN address frame to the end
device This is slightly later than #1, but
"crossing-on-the-wire".
3. Expander and end device determine that the
expander's OPEN loses the crossing-on-the-wire comparison, so the expander
responds with AIP.
4. The expander decides that it has a higher priority
OPEN to send out instead, so sends out a new OPEN address
frame.
The AIP always occurs, so the expander would not send
out the second OPEN address frame directly back-to-back. In SAS-1, only
one AIP was required; in SAS-1.1, three AIPs were recommended; in SAS-2, three
AIPs are required. If a bit error occurs and only one AIP is sent, the
receiver will see the second OPEN address frame back-to-back (with only an
invalid dword in between). Depending on the design, the link layer logic
might see the frames as being back-to-back.
I see no advantage to sending the
multiple Identifies with “significant” time delay between
them.
I would
propose that, if a phy transmits three Identifies that a minimum of six idle
dwords be transmitted between the Identify frames and no more that 16 idle
dwords be transmitted between Identify frames. (If these numbers aren’t
agreeable, let’s find numbers that are.)
RE: The minimum number should be zero. See below
concerning maximum.
2.
If one side transmits the Identify three times and the other side only once,
then the side that send only one will enable its higher layer protocol state
machines after sending only one. It is possible (and I can argue
probable if the phy reset sequence occurred as a link recovery event) that the
phy sending only one Identify could send an Open Address frame before the phy
sending three Identify frames has entered normal operation. This would
result in a timeout of an Open request.
RE: Once the IDENTIFYs are started, there is an implied
requirement of 1 ms to complete them (because the receiver is known to
timeout). Since OPEN waits 1 ms for a response and the IDENTIFYs
will be done within 1 ms, there is some some time left for the OPEN
response. The recipient with the shorted response time is the one that was
slow in sending out IDENTIFYs, so it should know to penalize itself and respond
faster.
On 3/7/2005, discussing 05-086, the WG voted 9-3 to not define
transmitter time limits to make implicit rules like that explicit
(generally: a transmitter must complete its action within 0.5 ms if the receiver
is enforcing a 1 ms timeout) (see minutes in 05-094). I would still like
to see that change, but have no reason to believe a revived proposal would be
better received. If we don't define maximum transmitter times in all other
parts of SAS, then the identification sequence shouldn't have them
either.
Not an unrecoverable event, but still
not a desirable event either. So, should we require all phys to not send
an Open Address frame until some time frame after the successful exchange of
an Identify? Like 1 ms?
RE: I'd prefer not to add an arbitrary
delay.
SI_IR_IRC could declare to the link layer that it's ready to go
after transmitting one of three IDENTIFY address frames (rather than waiting for
all three) and receiving one IDENTIFY address frame; the other two IDENTIFYs
would still be sent, but SI_IR_IRC wouldn't wait
for them.
One last question, should all
SAS-2 compliant devices be required to send three Identify
frames?
RE: No, I think it is too late and not important enough
to mandate. I propose it be optional in SAS-2 and mandatory in the next
version.
Additional note: The text
and state changes to the IR state machines (3 of them), as they appear in the
latest proposal, are not sufficient. If we can agree to the above
issues, then we can work on these issues.
RE: We could modify SI_IR_IRC as suggested. What
else do you think is "not sufficient"?
Regards,
Steve
Finch
STMicroelectronics
--
Rob Elliott, elliott@hp.com
Hewlett-Packard Industry Standard
Server Storage Advanced Technology
https://ecardfile.com/id/RobElliott