Once upon a time in an FC Standard long long ago we used to specify TX Jitter as DJ, RJ, and Total jitter.



And they all added up quite neatly until one day someone made the observation that we where over-limiting the jitter. He observed that if one did better on one component of jitter (DJ or RJ), shouldn't he be allowed exceed the other parameter as long as he didn't exceed Total jitter. At the time, we had the choice of specifying "DJ and Total" or "RJ and Total". Which ever was chosen, the opposite jitter attribute would be allowed to exceed the limit then applied by specifying the three components of jitter: DJ, RJ, and Total jitter.   If "DJ and Total" were chosen, receivers would have to tolerate RJ up to near the Total jitter number if someone designed a near perfect DJ transmitter. If "RJ and Total" were chosen, a receiver would have to tolerate DJ up to near the Total jitter number if someone came up with a transmitter with exceedingly low RJ.  After a lot of discussion, "DJ and Total" was chosen because the consensus at that time was that a receiver could tolerate a little more RJ in the presence of well controlled DJ, but that well controlled RJ did not guarantee that a receiver could tolerate DJ that was a larger proportion of Total jitter.
The current version of 07-063 uses an "RJ and Total" jitter specification at 6Gbp/s.  While receivers have improved dramatically, I still do not think that they have improved to the point that the transmit device's DJ should not be specifically limited by a "DJ and Total" methodology. If receivers can provably tolerate more DJ at the transmitter than is currently specified, then we should increase it.  However, I think it should still be intentionally limited within TJ, leaving RJ as the jitter component that can be increased in the presence of better DJ.  After all, we are going to be faced with closed, or near closed eyes and the primary component of this 'closing' will be ISI, which is DJ. The ISI basically shrinks the amplitude of high transition bits that follow a low transition region.  DJ from other sources, such as the transmitter, basically time skew these same low amplitude high transition bits from the center of the eye, further smearing the eye.  We need not only limit the eye closure allowed by ISI, we need also to intentionally limit the displacement of these amplitude challenged bits from the center of the eye.  The ‘channel’ that interconnects the transmitter to the receiver creates additive DJ to the transmit signal from such sources as ISI (mentioned above), imperfect terminations, impedance discontinuities at connectors, via’s, packages, crosstalk, etc.   These DJ sources also skew the low amplitude high transition bits from the center of the eye.  The effects of the majority of these sources of DJ on a signal are not easily quantified, and the universe of creatively intermixing these sources of DJ onto a signal in a ’channel’ is certainly not contained in a single S-parameter file of an external 10meter SAS cable.   To then allow a transmitter without ‘clearly defined DJ limits’ to drive such a channel is ill advised.  The hope of developing a 6G standard that specifies all parts of the TX-RX link in a manner that results in achieving the near-zero bit error rate desired by storage system developers necessitates keeping a "DJ" jitter specification on the transmitter.  
It may even require retuning to the method of long ago: intentionally limiting “RJ” and “DJ”, since I assume we did not change from a “DJ and Total” jitter specification (that has been used to successfully develop several generations of near-zero bit error rate storage systems) to an “RJ and Total” specification unless this change addressed a known problem.  Recovering signals that are ‘closed’ is after all, a new endeavor in near-zero bit error rate storage systems, and may require specifying both RJ and DJ along with Total Jitter (i.e. the limit on RJ and DJ do not necessarily have to add up to Total Jitter; the three attributes {RJ, DJ, Total} just need to constrain the measured transmitter performance in a manner that increases the opportunity for building a new generation of near-zero bit error rate storage systems).

Regards,
Al
************************************
Allen Kramer                        
  Phone: 952-402-2624          
   Fax: 952-402-3471              
    Seagate Confidential
************************************