Re: From serial PMD call 5 June
See within, Tom.
----- Original Message -----
From: "Jonathan Thatcher" <Jonathan.Thatcher@worldwidepackets.com>
To: "'Lindsay, Tom'" <tlindsay@stratoslightwave.com>; "DAWE,PIERS
(A-England,ex1)" <piers_dawe@agilent.com>; "802.3ae Serial"
<stds-802-3-hssg-serialpmd@ieee.org>
Sent: Friday, June 08, 2001 10:37 AM
Subject: RE: From serial PMD call 5 June
> Tom,
>
> You have asked a great question here. Of course, the question I read might
> be different than the one you asked :-).
>
> I see this is a derivative question to the one Piers asked (and has been
> asking for a while) at the last meeting: are we writing a component or a
> system level specification. From the perspective of the standard, we are
> writing a system level specification. This leaves unresolved how the
> component manufacturers and the system integrators are to negotiate the
> margin needed for a successful implementation. I have more than sufficient
> lab results to prove that FC and GbE did not resolve this issue.
>
TAL - I take this to be an example that jitter is not the only signal
quality that matters? I often think jitter is overemphasized relative to
other factors.
> From the perspective of the system integrator, using the new test methods
> with the virtual embedded BERT (VEB?), there is no need to represent
"other"
> jitter that would be inherent in a system since the "other" jitter is
> already in the system. I would propose that the only reason to add margin
> would be to compensate for systematic measurement error (potentially due
to
> effects that are a result of the simplifying assumptions of our models,
for
> example) or to compensate for variations in temperature and other
> uncontrolled "environmental" factors (power and ground noise; EMI from
> adjacent equipment, etc).
>
TAL - the other uncontrolled "environmental" factors are exactly what FC
meant by other jitter. FC systems are to be fully running during tests so
that terms like crosstalk and environment are already included. Right or
wrong, measurement error has always been assumed to be zero...
> The system company and system company's customer would probably be more
> interested in seeing extra system-level margin represented as margin in
the
> BER curves.
>
> There remain four corners to the question: [System specification/test,
> Component specification/test] X [Tx, Rx]
>
> To add to Anthony's comments, we seem to have (at least) two places where
we
> are adding margin:
> 1. Intentional addition of the SJ.
> 2. Measurement error.
>
> The problem with the measurement error is that these will vary. If the
> errors were constant (consistent), these would add margin. If not
> consistent, these could subtract margin. Unfortunately, I don't know if
our
> test specification bounds this problem or not.
>
TAL - I fear that measurement error will be significant for early
developers. As the group has discussed, ignoring measurement error will most
likely cause Tx's to fail unncessarily, and Rx units to be tested with less
stress than intended due to under-calibration. If we were truly consistent,
then measurement error would result in simple shifting of the budget.
However, I suspect most folks will try to quantify measurement error and
compensate for it in their results. The accuracy in doing so will be a
challenge, leading to residual uncertainty.
All this is a growing pain from pushing the state of the art. I certainly
have no resolution, and sincerely apologize for asking more questions than
providing answers.
Tom
> We, therefore, have several reasons why margin is a good idea. But, we
also
> have several ways to add or to display the margin.
>
> So, can we reduce all of this to a method that supports both the standard,
> the system developers, and the component manufacturers?
>
> jonathan
>
>
> > -----Original Message-----
> > From: Lindsay, Tom [mailto:tlindsay@stratoslightwave.com]
> > Sent: Friday, June 08, 2001 8:17 AM
> > To: DAWE,PIERS (A-England,ex1); 802.3ae Serial
> > Subject: RE: From serial PMD call 5 June
> >
> >
> >
> > The minutes below represent the ideas very clearly, and I
> > agree with the
> > differences in probability distribution. For DDJ, this is especially
> > true for the randomized data that results from scrambling. So, I agree
> > that testing with SJ will enforce some margin.
> >
> > In FC, SJ above the corner frequency was intended to represent "other"
> > jitter that may occur in a real system that would not be seen in a
> > compliance test. So, what quantity of other jitter we expect to occur?
> > I'm not quite ready to think this is 0.
> >
> > These 2 points tend to contradict. Do they perfectly offset (per
> > Anthony's proposal)? Obviously a supplier would rather not
> > have to test
> > with "other" jitter, but a system customer may be glad to
> > have it there.
> >
> > Tom
> >
> > -----Original Message-----
> > From: DAWE,PIERS (A-England,ex1) [mailto:piers_dawe@agilent.com]
> > Sent: Friday, June 08, 2001 6:02 AM
> > To: '802.3ae Serial'
> > Subject: From serial PMD call 5 June
> >
> >
> >
> > Jitter spec numbers
> > -------------------
> > Opinion on the call was that:
> >
> > 0.35 UI of DJ was too much; nearer 0.3 UI would be fairer
> > 0.015 UI of sigma_RJ was too little; 0.016 suggested
> > The extra 0.05 UI of sinusoidal jitter in the stressed
> > sensitivity test
> > was
> > a significant burden.
> > Some believed that our draft jitter requirements are more
> > demanding than
> > SONET.
> >
> > Anthony Sanders suggested that the stressed eye should contain the
> > sinusoidal jitter as a component of the deterministic jitter, rather
> > than in
> > addition to it. SJ is more stressful than "regular" DJ as its
> > probability
> > distribution is concentrated towards the extremes. As these
> > minutes may
> > not
> > represent the ideas correctly, Anthony would put some slides on the
> > reflector for discussion. Also Ali Ghiasi may be able to offer some
> > information on CDR requirements (how many UI of eye opening needed).
> >
> > Next Draft
> > ----------
> > Is expected 11 June.
> >
> > Piers
> >
>