Persistent Connection Timeout Timer

Penokie, George George.Penokie at lsi.com
Mon Jan 21 14:14:21 PST 2013


Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1301211_f.htm">HTML-formatted message</a>

Craig,
The Transmit Extend Connection timer is stopped when a frame is transmitting
and is reinitialized and stated after a frame is transmitted. The time is not
suspended, so you do not have to keep track of the value in the timer while
frame are being transmitted.
Adding the same behavior to the Persistent Connection Timeout timer should
not add much complexity.  Too many times I have heard the 'it will never
happen' or 'it will not be a problem' for SAS and too many times it becomes a
problem late in the game causing the need for a much more complex solution to
keep existing products from breaking.
Bye for now,
George Penokie
LSI Corporation
3033 41 St NW
Rochester , MN 55901
507-328-9017
george.penokie at lsi.com
From: Craig Stoops [mailto:Craig.Stoops at synopsys.com]
Sent: Monday, January 21, 2013 3:58 PM
To: Penokie, George; Pooja Gupta; t10 at t10.org
Subject: RE: Persistent Connection Timeout Timer
Hi George,
As matter of practicality, the EXTEND_CONNECTION primitive should be receive
apprx 10 times faster than the PCTT, so does it really matter if the PCTT
suspends or not during frame reception? I think that might be an extra
complexity that is not really needed. Also did you mean suspend, or
reinitialize? If you are re-initializing the Transmit side, then I think you
want o reinitialize the receive side too?
Also, on the transmit side, does the Transmit Extend Conenction timer need to
be suspended during frames transmission? Can't we just re-initialize it on
frame transmitted? The EXTEND_CONNECTION has a lower priority to transmit
than a frame, so the transmitter won't send it during a frame even if one is
queued, it will go after the frame.
On the other hand - In order for the scenario cites to happen, there would
have to be 1ms of back to back traffic with not a single gap, which is highly
unlikely. But assuming that this scenario could happen, it is a good reason
why the transmit extend timer maybe shouldn't be stopped or reinitialized on
a frame. Just have it send EXTEND_CONNECTION periodically at 10x the PCTT.
Seems like a fairly simple approach would do, there is no exact timing needed
for the persistent connection to persist.
Trying to reduce the complexity of verification of this.
Craig
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Penokie,
George
Sent: Monday, January 21, 2013 2:42 PM
To: Pooja Gupta; t10 at t10.org
Subject: RE: Persistent Connection Timeout Timer
Pooja,
Yes, you are correct, the Persistent Connection Timeout timer should suspend
during frame receiving traffic. I will write a proposal to fix that.
Bye for now,
George Penokie
LSI Corporation
3033 41 St NW
Rochester , MN 55901
507-328-9017
george.penokie at lsi.com
From: owner-t10 at t10.org<mailto:owner-t10 at t10.org> [mailto:owner-t10 at t10.org]
On Behalf Of Pooja Gupta
Sent: Friday, January 18, 2013 11:13 PM
To: t10 at t10.org<mailto:t10 at t10.org>
Subject: FW: Persistent Connection Timeout Timer
Hi,
I have a concern about Persistent Connection Timeout Timer.
Below is the snippet from Draft  T10/12-251 revision 8:
--------------------- Page# 
37---------------------------------------------------------------------------
--------------------------------------------
6.18.9.3.4 SSP_EM2:Manage
This state:
a) requests the SSP transmitter send EXTEND_CONNECTION; and
b) monitors the receipt of EXTEND_CONNECTION.
Upon entry into this state, this state shall initialize and start the
Transmit Extend Connection timer.
If this state receives:
a) a Frame Transmitted message, then this state shall initialize and start
the Transmit Extend
Connection timer; or
b) a Transmitting Frame message, then this state shall stop the Transmit
Extend Connection timer.
If the Transmit Extend Connection timer expires, then this state shall:
a) send a Transmit EXTEND_CONNECTION message to the SSP transmitter; and
b) after receiving an EXTEND_CONNECTION transmitted message, initialize and
start the Transmit
Extend Connection timer.
--------------------- Page#
37---------------------------------------------------------------------------
--------------------------------------------
So, For the transmission of the EXTEND CONNECTION Primitive, it takes care of
the following:
1.	 Upon entry into SSP_EM2: Manage state, SSP Phy shall initialize and
start the Transmit Extend  Connection timer
2.	 Transmit Extend Connection timer runs when there is nothing to do,
And when timer expires, EXTEND_CONNECTION primitive is transmitted
3.	 If there is a request to transmit a Frame, it stops the timer until
the frame is completely transmitted. It initializes and resumes the timer
upon receipt of Frame Transmitted message.
But it does not take care of the Receiver side of  EXTEND CONNECTION
Primitive. Please see the snippet below:
--------------------- Page# 
37,38------------------------------------------------------------------------
-----------------------------------------------
If this state receives an EXTEND_CONNECTION Received message, then this state
shall initialize and start
the Persistent Connection Timeout timer.
If the Persistent Connection Timeout timer expires, then this state shall
send a Persistent Connection
Established (Disabled) confirmation to the port layer.
--------------------- Page#  37,
38---------------------------------------------------------------------------
--------------------------------------------
Here SSP_EM2:Manage state nowhere accommodates the change in the Persistent
Connection Timeout timer state when receiving the frame.
Consider a situation where the Transmitter has long traffic of Back to Back
Frames to transmit. In that case it will not send the EXTEND_CONNECTION
Primitive(refer to #3 above).
Eventually, the Persistent Connection Timeout Timer will expire and will
force the Receiver to send a Persistent Connection Established (Disabled)
confirmation to the port layer.
So, is it correct, that the Persistent Connection Timeout time keeps on
running, waiting for EXTEND_CONNECTION primitive, even when it is receiving a
Frame?
Please share your opinion on this.
Regards
Pooja



More information about the T10 mailing list