AW: [802.3ae] XAUI Rj TR comment
Appologies from my side, as well for not having also come in on this subject at an earlier date, but for those following the current financial situation in Europe, you will know we have been worrying about other things for the last few weeks.
After reading through the 20..30 emails on this subject, I would like to get back to the original problem that Howard is putting forward, and to make some statements about this and about the current Annex 48B.
- The Annex 48B, currently refers to the MJS documents.
- We have agreed this annex would be updated to remove the references and remove inconsistencies, and I will in the next week, once I recieve some inputs from Michael Debie (Wavecrest) about TIAs, have this ready. Anyone intersted in commenting on it before the next interim, please email me.
- The Annex 48B, defines, based on MJS what is meant by RJ and DJ i.e effective RJ and effective DJ
- Effective DJ/RJ is a valid/easy/understandable and safe method for defining jitter.
- Effective DJ/RJ can at high BER show a high inaccuracy to other methods of measuring or defining DJ/RJ, but the question is "Who cares?". We are interested in defining a model that allows confirmation of a working channel at 1e-12 BER. At this BER the variance of the gaussian tail and it´s offset (or effective DJ) are what defines this.
- There is currently an ambiguity during receiver tolerance testing that someone can set all the DJ to RJ, which of course is wrong. Some of the DJ comes from the driver (normally DCD or high frequency DJ), some from the bandlimiting of the channel (DDJ), and the rest from crosstalk or other phenomina in the channel (high frequency DJ). Please note that we treat the RJ of the channel as "other" DJ, to add margin in the design.
- If one tries to set up a jitter tolerance test with a high amount of RJ, this can lead to problems, as Howard is explaining.
- If someone tries to use receive equalisation, in conjunction with a receive signal that contains either high amount of random jitter OR high amounts of HF DJ this will also give problems (We do not try to define anything concerning receive equalisation, however the specification does allow for the use of receive equalisation; a receiver should be allowed to equalise out the DDJ from channel if it wants to).
- Adding large amount of RJ at the clock input to a BERT, with no bandlimitation will give problems, as the RJ is a rotation vector of amplitude and time, and will lead to the problem that Howard is describing. (However, the question is should we add so much RJ.... we come back to this)
- The RJ as it is seen be the receiver is sampled and does therefore show the appropriate spectrum associated with a sampled signal. The data is sampling the random bandlimited noise (not random white noise, otherwise one would not see any sampling effect), and is therefore giving rise to bandlimitation at half the sampling rate, plus up and down converstion (one reason for not increasing the bandwidth of the receiver must higher than the currently defined 1/1667.)
- One main concern in the test setup is that the RJ is above the 1/1667 corner frequency in the test setup. If the correct test method is used, i.e. with a "Golden PLL" for the calibration of the signal, then bandlimiting of the RJ at the input to the BERT is not a problem. Obviously from a test setup point of view, it is a good idea to make sure that the RJ has a low pass filter with a corner frequency above half the baud rate.
- It is clear that the driver should be allowed to have all of it´s deterministic jitter converted to random jitter, as the DJ is in anycase high frequency. However, this has nothing to do with receive tolerance testing. Testing with HF DJ is worse case, in comparison to RJ.
- The channel introduces DDJ, and this should not be allowed to be converted into RJ
- The channel introduces HF DJ, and this can be converted into RJ, but again has nothing to do with receive tolerance testing. Again DJ is worse case for testing, in comparison to RJ.
- For the purpose of testing, we need to possibly do some small modifications. The calibrated signal, could therefore consist of
SJ = Driver DJ + Channel Other (introduced with the SJ source)
DJ = Channel DDJ (introduced through bandlimiting of the signal
RJ = Driver RJ (introduced using bandlimited RJ noise at input to BERT generator)
This is a little different to before, but would be more accurate for taking into account receive equalisation, and also the trade off of DJ to RJ.
I hope this is reasonably acceptable to everyone, it doesn´t agree with everyone comments, but is in my view pretty close to reality. Howard, could you inform me if this is acceptable.
Appologies in advance for any loss of grammer in the above email, it got a bit longer than I wanted.
Anthony Sanders
Principal Engineer
Infineon Technologies
-----Ursprüngliche Nachricht-----
Von: Mike Li [mailto:mpeng@xxxxxxxxxxxxx]
Gesendet am: Freitag, 10. August 2001 21:48
An: 'Jonathan Thatcher'; HSSG_reflector (E-mail)
Betreff: RE: [802.3ae] XAUI Rj TR comment
Can anyone kindly tell me where is the current XAUI jitter
document and the agenda/plan for the future activities?
Thanks !
Mike
Wavecrest
> -----Original Message-----
> From: Jonathan Thatcher
> [mailto:Jonathan.Thatcher@xxxxxxxxxxxxxxxxxxxx]
> Sent: Thursday, August 09, 2001 4:32 PM
> To: HSSG_reflector (E-mail)
> Subject: RE: [802.3ae] XAUI Rj TR comment
>
>
>
> Kesling,
>
> Thanks for the redirection. Regarding the activity to define
> these terms,
> please be aware that the jitter test methodology being used
> in clause 52 is
> substantially different than the prior art referenced here from Fibre
> Channel and Gigabit Ethernet. Most of the concepts are the
> same (from a
> theoretical perspective), but much of the similarity ends there.
>
> I do not recommend that the XAUI group use this new method
> (though it should
> provide some advantages). But, please be aware and understand
> it during the
> course of refining the definitions.
>
> jonathan
>
> > -----Original Message-----
> > From: Kesling, Dawson W [mailto:dawson.w.kesling@xxxxxxxxx]
> > Sent: Wednesday, August 08, 2001 12:03 PM
> > To: HSSG_reflector (E-mail)
> > Subject: RE: [802.3ae] XAUI Rj TR comment
> >
> >
> >
> > All,
> >
> > I've been watching the reflector discussion but have been too
> > busy to reply.
> > I'd like to quickly give some background to help clarify the
> > situation.
> > Please don't shoot me - I'm only the editor giving some history!
> >
> > It has been universally understood in the XAUI group (until
> > recently) that
> > DJ is everything bounded and RJ is everything unbounded.
> > Furthermore, RJ has
> > been assumed to be Gaussian for the purspose of calculations.
> > Sinusoidal
> > jitter (SJ) is a subset of DJ. XAUI does not treat it
> > differently from DJ,
> > but only calls out an explicit level for the SJ component of
> > DJ. Jitter that
> > is bounded but not correlated to the data is also
> deterministic by the
> > working definition. XAUI does not call this out explicitly,
> but other
> > clauses may.
> >
> > Many people came into XAUI from different backgrounds, but
> > agreed to these
> > definitions for the sake of normalization and communication.
> > The work done
> > in MJS was helpful to XAUI and was the basis for these common
> > definitions.
> > Those who have more recently become active in XAUI seem to be making
> > different assumptions about the definitions of these jitter
> > terms. Other
> > definitions may be valid, but we should not change the underlying
> > definitions agreed to by dozens of participants and approved
> > in several
> > draft ballots at this late stage. There is nothing wrong
> with the XAUI
> > definitions as long as they are defined. The real problem is,
> > as Pat pointed
> > out, that they are not well defined in the document. This has
> > always been
> > intended to be done in Annex 48B but has not been finished
> > yet. I belive
> > that Anthony Sanders and Tom Lindsay are still working on it.
> > This annex
> > needs to be finished and submitted in the upcoming ballot
> > cycle so that
> > newcomers and standard readers can understand the meaning of
> > DJ and RJ as
> > used in XAUI (and the other clauses).
> >
> > In summary, I do not think there is anything inherently
> wrong with the
> > definitions assumed by XAUI and being written into Annex 48B
> > (based on MJS).
> > We should all use these definitions and get on with the
> > HOward's real issue
> > of limiting the RJ as the term has been defined by the group.
> > Please forgive
> > me that I probably won't be able to reply to any further
> > e-mails on this
> > topic. I only hoped to refocus us on the important issue
> > while I had a spare
> > minute between fires.
> >
> > -Dawson
> >
> >
> > -----Original Message-----
> > From: THALER,PAT (A-Roseville,ex1) [mailto:pat_thaler@xxxxxxxxxxx]
> > Sent: Monday, August 06, 2001 4:58 PM
> > To: Dennis Petrich; THALER,PAT (A-Roseville,ex1); Lindsay,
> Tom; Howard
> > A. Baumer; HSSG_reflector (E-mail)
> > Subject: RE: [802.3ae] XAUI Rj TR comment
> >
> >
> >
> > Dennis,
> >
> > The MJS document is referenced from an informative part of
> > our draft and it
> > is a TR. The terms are used in normative specifications in
> > our draft. The
> > definitions should be added to our draft because a
> > specification doesn't
> > mean anything if the quantity being specified is left ambiguous.
> >
> > Regards,
> > Pat
> >
> > -----Original Message-----
> > From: Dennis Petrich [mailto:dpetrich@xxxxxxxxxxxxx]
> > Sent: Wednesday, August 01, 2001 2:11 PM
> > To: 'THALER,PAT (A-Roseville,ex1)'; Lindsay, Tom; Howard A. Baumer;
> > HSSG_reflector (E-mail)
> > Subject: RE: [802.3ae] XAUI Rj TR comment
> >
> >
> >
> > Pat,
> >
> > The NCITS "TR-25-1999" MJS document provides definitions that can be
> > referenced for XAUI use to distinguish between the various
> > jitter types such
> > as RJ, DJ, DDJ, SJ and so on.
> >
> > Also, FC crosstalk work was done a while back and can be viewed at
> > T11/00-064v0 and T11/99-759v0. In the tests crosstalk showed
> > up as DJ. But
> > I'm sure these results would vary as a function of the
> > crosstalking data
> > rate and frequency content.
> >
> > Dennis
> >
> > -----Original Message-----
> > From: THALER,PAT (A-Roseville,ex1) [mailto:pat_thaler@xxxxxxxxxxx]
> > Sent: Wednesday, August 01, 2001 1:43 PM
> > To: Lindsay, Tom; Howard A. Baumer; HSSG_reflector (E-mail)
> > Subject: RE: [802.3ae] XAUI Rj TR comment
> >
> >
> >
> > Tom,
> >
> > Jitter always seems to be a difficult subject to sort out and
> > your remark
> > below caused me to do some checking on RJ vs. DJ.
> >
> > I've looked all through the 802.3 standard and our draft.
> > There doesn't seem
> > to be any definition of RJ or DJ. Processes can certainly be
> > random without
> > being random or Gaussian. Deterministic means if a set of
> > conditions is set
> > up we know what will result. The roll of a die is random
> > though the result
> > is bounded.
> >
> > If we are using dictionary words with a different or more
> > restricted meaning
> > such as random = Gaussian (or truncated Gaussian where the
> truncation
> > happens past 1E-12) then we should define our terms. Since
> we specify
> > deterministic jitter and total jitter, we should at least
> > have a reasonably
> > rigorous definition of "deterministic jitter."
> >
> > I also notice that in some places jitter is divided into RJ
> > and DJ, but in
> > other places in 47 it is RJ, DJ and sinusoidal. 52.9.10.4 (and the
> > equivalent subclause of 53) divide jitter into random,
> > deterministic and
> > bounded.
> >
> > Crosstalk is deterministic in that given a fixed adjacent
> > signal and a fixed
> > coupling function one can determine the crosstalk. However,
> > the crosstalk at
> > a receiver is often the result of multiple disturbers
> > coupling in each with
> > its own function and the signals aren't correlated to the
> > received signal.
> > Therefore, the sum of the crosstalk looks like a truncated
> > Gaussian. Even if
> > the definition of RJ is Gaussian up to at least 1E-12, it
> > isn't clear to me
> > that crosstalk would fall outside that definition. I don't
> > recall seeing any
> > studies on the distribution of crosstalk for XAUI or for our optical
> > receivers.
> >
> > I would expect crosstalk to be part of RJ rather than DJ.
> >
> > Regards,
> > Pat
> >
> > -----Original Message-----
> > From: Lindsay, Tom [mailto:tlindsay@xxxxxxxxxxxxxxxxxxxx]
> >
> > See below, Tom
> >
> > -----Original Message-----
> > From: Howard A. Baumer [mailto:hbaumer@xxxxxxxxxxxx]
> > Sent: Tuesday, July 31, 2001 11:36 AM
> > To: Lindsay, Tom; HSSG_reflector (E-mail)
> > Subject: Re: [802.3ae] XAUI Rj TR comment
> >
> > >>>>snip<<<<<
> > - We're still confused on how you would ever get 0.55UI of RJ. If
> > crosstalk adds so much jitter,
> > **TL - crosstalk is expected to be bounded, and therefore more
> > effectively deterministic (the definition of RJ is
> > unbounded/Gaussian to
> > least below 1E-12, and DJ is all other stuff).
> >
>