SAS rate matching

Sachidanandam, Kannan Kannan_Sachidanandam at maxtor.com
Tue Apr 8 10:30:48 PDT 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* "Sachidanandam, Kannan" <Kannan_Sachidanandam at maxtor.com>
*

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2FDF4.9825B210
Content-Type: text/plain

Actually ratematching should also end if the sent OPEN loses to an
incoming OPEN frame that does not require rate matching.
This is one of the consequences of making ratematching dependent on sent
connection establishing primitives rather than established connections.
 
Kannan
Maxtor

-----Original Message-----
From: Elliott, Robert (Server Storage) [mailto:Elliott at hp.com]
Sent: Tuesday, April 08, 2003 10:51 AM
To: t10 at t10.org
Subject: SAS rate matching



I've received a few comments on rate matching in sas-r03f: 

1.  In section 7.13 Rate matching: 
"A phy shall stop inserting ALIGNs and NOTIFYs for rate matching after
transmitting the first dword in a 
CLOSE." 

needs to says "in a CLOSE or a BREAK" since rate matching must end after
breaking a connection too. 

2.  Is it clear to everyone/anyone that the ALIGNs inserted for clock
skew management are independent of any ALIGNs inserted for rate
matching?  If you're rate matching, you're not exempt from inserting an
extra ALIGN every 2048 dwords.  Should I add text in 7.3 Clock skew
management and 7.13 Rate matching that explicitly mentions this?

-- 
Rob Elliott, elliott at hp.com 
Hewlett-Packard Industry Standard Server Storage Advanced Technology 
 <https://ecardfile.com/id/RobElliott>
https://ecardfile.com/id/RobElliott 




------_=_NextPart_001_01C2FDF4.9825B210
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

SAS rate matching Actually ratematching should also end if the sent OPEN loses to an incoming OPEN frame that does not require rate matching.
 This is one of the consequences of making ratematching dependent on sent connection establishing primitives rather than established connections.
  
 Kannan
 Maxtor
 -----Original Message-----
From: Elliott, Robert (Server Storage) [mailto:Elliott at hp.com]
Sent: Tuesday, April 08, 2003 10:51 AM
To: t10 at t10.org
Subject: SAS rate matching


 I've received a few comments on rate matching in sas-r03f: 1.  In section 7.13 Rate matching: 
"A phy shall stop inserting ALIGNs and NOTIFYs for rate matching after transmitting the first dword in a 
CLOSE." needs to says "in a CLOSE or a BREAK" since rate matching must end after breaking a connection too. 2.  Is it clear to everyone/anyone that the ALIGNs inserted for clock skew management are independent of any ALIGNs inserted for rate matching?  If you're rate matching, you're not exempt from inserting an extra ALIGN every 2048 dwords.  Should I add text in 7.3 Clock skew management and 7.13 Rate matching that explicitly mentions this? -- 
Rob Elliott, elliott at hp.com 
Hewlett-Packard Industry Standard Server Storage Advanced Technology 
https://ecardfile.com/id/RobElliott 



------_=_NextPart_001_01C2FDF4.9825B210--




More information about the T10 mailing list