Re: AW: [802.3ae] XAUI Rj TR comment
Rich,
See comments below labeled HAB>
Rich Taborek wrote:
>
> Anthony,
>
> I agree with all of your analysis. However, I disagree with the basic
> premise that you make about receive equalization. IEEE P802.3ae does not
> support receive equalization in any form for any interface. More
> specifically, XAUI does not support receive equalization. Therefore, no
> changes should be made to the D3.2 in response to any outstanding
> comments which claim an inability to support XAUI receive equalization.
> All such comments must be rejected in the interest of meeting P802.3ae
> objectives.
HAB> No change is being requested to facillitate receiver equalization.
There is no outstanding comment that claims XAUI has an inability to
support receive equalization. XAUI does not prohibit nor enforce any
type of
signal conditioning. It only defines a near-end and far-end eye plus
jitter
budgets.
The outstanding comments are: #1) return loss of -10dB is to tight (no
mention
of any equalization type, transmit or receive)
#2) Rj limit is an implied limit and the jitter tollerance testing is
broken.
(again no mention of any equalization type, transmit or receive)
What P802.3ae objectives are not met by hashing out these comments and
comming to more resonable specifications?
>
> I believe that receive equalization is the basic premise for all XAUI Rj
> comments. If I am wrong, then any argument for supporting XAUI receive
> equalization in any manner must be purged from any discussion of XAUI Rj
> comments. I strongly urge all 802.3 voters to consider this argument.
> The purpose of the following background material is to explain XAUI
> operation in the presence or absence of equalization:
>
HAB> Receive equalization is not the basic premise for the XAUI Rj TR.
The premis for the Rj TR is that when you go by the letter of the
standard the testing of jitter tollerance is broken! Since anyone
developing and testing for compliance to the standard has to go by what
is written this must be fixed. That is to say at some point in time
(now as we develope and finalize the standard or later through a
maintance cycle) a clarification will have to be made as to the test
conditions for jitter tollerance. Does the receiver need to tollerate
55% Rj and no Dj? Most seem to think no this isn't the case. If this
isn't the case then we have to spell out what the cases are. From all
the prior discussions on this topic it has been shown that you cannot
setup this test condition with today's test equipment. The only way to
get Rj above 50% onto the signal is to have a transmit source that
inherently generates that much jitter (unless somebody sells a
signal/clock
generator with a wideband FM modulating input, has anyone seen one).
> --
>
> The reason is that supporting receive equalization would be an
> interoperability nightmare with negative cost/performance implications
> and no apparent advantage in meeting XAUI objectives.
HAB> What "negative cost/performance implications" are there with
receive equalization? The standard should define the system such
that it will work first and not care about nickel and dime cost
implications
or any other implementation related issues.
> Consider that the
> Clause 47 XAUI spec already supports either no equalization or transmit
> equalization.
HAB> The Clause 47 XAUI spec does not support or limit any type of
equalization, be it transmit or receive. In fact all the modeling, the
near end specs, the compliance test channel, the far end spec have been
developed without any equalization what so ever! Whether a particular
transmitter provides some pre-equalization or a reciever provides some
post-equalization is not even taken into account in testing for
compliance or interoperability. The transmitter has to meet one of two
sets of specifications and the receiver has to tollerate a given set of
signal conditions. No where in the draft is there mentioned a specific
specification for any type of equalization. Yes, one might think that
the near end / far end specs are created for transmit pre-equalization
but Clause 47 does not state that if you have transmit equalization you
have to meet the far end and if you don't you have to meet the near
end. It just says meet one of them. So if someone is testing a
transmitter why even bother with the near end spec just connect up a
compliant test channel and test to the far end spec.
> Simulation, theoretical calculations and actual operation
> all clearly show that simple transmit equalization, more accurately
> described at transmit de-emphasis, yields a reach improvement of >>50%
> over a XAUI compliant channel (e.g. XAUI PCB traces, etc.). It should be
> noted that XAUI objectives of 20" over common FR-4 have been proven to
> be met with no equalization at the transmitter or receiver.
>
> XAUI specified transmit equalization simply enables additional XAUI
> reach in a cost effective manner compatible with XAUI receive
> specifications. Permitted XAUI configurations currently include:
>
> 1) DTE XGXS Tx - No Tx Eq -----XAUI-----> PHY XGXS Rx - No Rx Eq
> DTE XGXS Rx - No Rx Eq <---Channel---- PHY XGXS Tx - No Tx Eq
>
> 2) DTE XGXS Tx - Tx Eq -----XAUI-----> PHY XGXS Rx - No Rx Eq
> DTE XGXS Rx - No Rx Eq <---Channel---- PHY XGXS Tx - No Tx Eq
>
> 3) DTE XGXS Tx - No Tx Eq -----XAUI-----> PHY XGXS Rx - No Rx Eq
> DTE XGXS Rx - No Rx Eq <---Channel---- PHY XGXS Tx - Tx Eq
>
> 4) DTE XGXS Tx - Tx Eq -----XAUI-----> PHY XGXS Rx - No Rx Eq
> DTE XGXS Rx - No Rx Eq <---Channel---- PHY XGXS Tx - Tx Eq
>
> All four configurations above must support at least 20" over common
> FR-4. My sense is that virtually all XAUI implementations will utilize
> configuration 4 which supports transmit equalization on both XGXS sides
> in order to keep power at a minimum while meeting or exceeding XAUI
> objectives. It is my experience that most if not all XAUI vendors
> support transmit equalization at no cost premium over no equalization.
>
> XAUI transmit equalization simply de-emphasizes lower frequency signals
> with respect to higher ones. Since XAUI signals are 8B/10B based, the
> highest frequency signal is at 1/2 Baud (1.5625 GHz) and the lowest
> frequency is 1/10 Baud (312.5 MHz). The de-emphasis is with respect to
> signal amplitude. Transmit equalization implementation is not specified
> by Clause 47 only either transmit and receive or receive only templates
> must be met. However, one of the simplest, cost effective and time
> tested approaches to transmit equalization is the reduce the amplitude
> of lower frequency signals with respect to higher frequency signals. The
> following example illustrates one of the simplest forms of transmit
> equalization, reducing the amplitude of the 2nd consecutive signaled bit
> of the same value (i.e. zero or one). Please use a fixed width font to
> display anything meaningful.
>
> --+ +---+ +--+ +-//
> | | | | \ | //
> | | | | +------+ | //
> | | | | | | //
> | | | | | | //
> | | | | | | //
> | | | | | | //
> | | | | | | //
> | | | +--+ | | //
> | | | / | | //
> +---+ +--+ +---+ //
> 1 0 1 0 0 1 1 1 0
>
> Note that the signaling above is logical and not representative of the
> physical differential signaling over XAUI.
>
> Receive equalization was rejected as unnecessary in meeting XAUI
> objectives, not cost effective and not interoperable during XAUI
> development. If receive equalization were to be allowed at this late
> point in P802.3ae development the permitted XAUI configurations would
> include:
>
> 1) DTE XGXS Tx - No Tx Eq -----XAUI-----> PHY XGXS Rx - No Rx Eq
> DTE XGXS Rx - No Rx Eq <---Channel---- PHY XGXS Tx - No Tx Eq
>
> 2) DTE XGXS Tx - Tx Eq -----XAUI-----> PHY XGXS Rx - No Rx Eq
> DTE XGXS Rx - No Rx Eq <---Channel---- PHY XGXS Tx - No Tx Eq
>
> 3) DTE XGXS Tx - Tx Eq -----XAUI-----> PHY XGXS Rx - Rx Eq
> DTE XGXS Rx - No Rx Eq <---Channel---- PHY XGXS Tx - No Tx Eq
>
> 4) DTE XGXS Tx - No Tx Eq -----XAUI-----> PHY XGXS Rx - Rx Eq
> DTE XGXS Rx - No Rx Eq <---Channel---- PHY XGXS Tx - No Tx Eq
>
> 5) DTE XGXS Tx - No Tx Eq -----XAUI-----> PHY XGXS Rx - No Rx Eq
> DTE XGXS Rx - No Rx Eq <---Channel---- PHY XGXS Tx - Tx Eq
>
> 6) DTE XGXS Tx - Tx Eq -----XAUI-----> PHY XGXS Rx - No Rx Eq
> DTE XGXS Rx - No Rx Eq <---Channel---- PHY XGXS Tx - Tx Eq
>
> 7) DTE XGXS Tx - Tx Eq -----XAUI-----> PHY XGXS Rx - Rx Eq
> DTE XGXS Rx - No Rx Eq <---Channel---- PHY XGXS Tx - Tx Eq
>
> 8) DTE XGXS Tx - No Tx Eq -----XAUI-----> PHY XGXS Rx - Rx Eq
> DTE XGXS Rx - No Rx Eq <---Channel---- PHY XGXS Tx - Tx Eq
>
> 9) DTE XGXS Tx - No Tx Eq -----XAUI-----> PHY XGXS Rx - No Rx Eq
> DTE XGXS Rx - Rx Eq <---Channel---- PHY XGXS Tx - Tx Eq
>
> 10)DTE XGXS Tx - Tx Eq -----XAUI-----> PHY XGXS Rx - No Rx Eq
> DTE XGXS Rx - Rx Eq <---Channel---- PHY XGXS Tx - Tx Eq
>
> 11)DTE XGXS Tx - Tx Eq -----XAUI-----> PHY XGXS Rx - Rx Eq
> DTE XGXS Rx - Rx Eq <---Channel---- PHY XGXS Tx - Tx Eq
>
> 12)DTE XGXS Tx - No Tx Eq -----XAUI-----> PHY XGXS Rx - Rx Eq
> DTE XGXS Rx - Rx Eq <---Channel---- PHY XGXS Tx - Tx Eq
>
> 13)DTE XGXS Tx - No Tx Eq -----XAUI-----> PHY XGXS Rx - No Rx Eq
> DTE XGXS Rx - Rx Eq <---Channel---- PHY XGXS Tx - No Tx Eq
>
> 14)DTE XGXS Tx - Tx Eq -----XAUI-----> PHY XGXS Rx - No Rx Eq
> DTE XGXS Rx - Rx Eq <---Channel---- PHY XGXS Tx - No Tx Eq
>
> 15)DTE XGXS Tx - Tx Eq -----XAUI-----> PHY XGXS Rx - Rx Eq
> DTE XGXS Rx - Rx Eq <---Channel---- PHY XGXS Tx - No Tx Eq
>
> 16)DTE XGXS Tx - No Tx Eq -----XAUI-----> PHY XGXS Rx - Rx Eq
> DTE XGXS Rx - Rx Eq <---Channel---- PHY XGXS Tx - No Tx Eq
>
> I trust that the above clearly portrays the interoperability nature of
> adding receive equalization to XAUI at this late juncture. Note also
> that the addition of receive equalization to XAUI must be considered a
> major technical change to P802.3ae and must be considered out of order
> as the cut off for last P802.3ae feature was November 2000 and the cut
> off for the last P802.3a technical change was May, 2001.
HAB> This does not clearly portray the interoperability nature of having
any equalization put in anywhere. This just shows how complicated you
can view something that is simple. The only interoperability testing
that need be done is:
Part A from Vendor A Tx -----XAUI-----> Part B from Vendor B Rx
Part A from Vendor A Rx <---Channel---- Part B from Vendor B Tx
With N vendors creating M parts we get a whole lot of combinations.
This is why we all support and then submit our products toan
interoperability lab.
>
> In conclusion, any development or changes to XAUI or Rj methodology must
> not consider receive equalization.
HAB> This is where I agree. Rj should be changed only to clarify and
solidfy a working test for XAUI receiver jitter tollerance. What I
would like to propose is to change the Far End Rj limit from Rj(max) =
Tj(max) - Dj(measured) to Rj < 0.35UIp-p (=8ps RMS) with a band bass
limit of 20Mhz to 1.5625GHz. I can't see anything wrong with these
limits. The current test equipement works fine with these limits. This
is loose enough that there shouldn't be any problem developing product
to meet these limits. In actuality these limits should always be met
with good margin as anyone would be hard pressed to create a transmitter
with Dj = 0.
>
> Best Regards,
> Rich
>
> --
>
> anthony.sanders@xxxxxxxxxxxx wrote:
> >
> > 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).