From: Bill.Martin@emulex.com
To: <Elliott@hp.com>, <t10@t10.org>
Date: Wed, 22 Oct 2008 22:30:49 -0700
Subject: Elasticity buffer and training
X-Message-Number: 9228
Formatted message: HTML-formatted message

In looking at a combination of figure 35 and figure 180 in SAS2r14f, there is
a potential that the first valid address frame is lost after initialization.
During training, there are no ALIGNS inserted for physical link rate
tolerance matching.  This means that there can be many more dwords received
than what the elasticity buffer can accommodate for a clock skew mismatch. 
At the end of training, there are three identify frames sent and then a
address frame may be sent.  All of these occur in less than the 512 bytes
that determine when ALIGN for clock skew management shall be inserted.	The
case exists where the elasticity buffer is capable of holding the three
IDENTIFY address frames but then overflows during the first Address frame for
a destination phy.
I do not have a proposed fix for this, but unless I have missed something,
this needs to be addressed.
Bill Martin
Emulex
Office of Technology
Industry Standards
916 772-3658
916 765-6875 (Cell)
bill.martin@emulex.com