Re: Annex 48A Jitter Test Patterns
Joel,
I think quite a lot of people will have quite a lot to say
about sending packets larger than 1518/1522, though many
implementations support longer packet sizes. These were the
2 sections that I found when parsing the standard for
maxFrameSize. I assumed it would be spelled out a bit more
plain but I think this is sufficient.
3.2.7
"The maximum possible size of the data field is
maxFrameSize - (2 x addressSize + 48)/8 octets."
4.2.4.2.1
"a) Maximum Frame Size. The receiving CSMA/CD sublayer
is not required to enforce the frame size limit, but it
is allowed to truncate frames longer than maxFrameSize
octets and report this event as an (implementation-
dependent) error."
Ben
Joel Goergen wrote:
>
> Ben
>
> This has come up before in logic track discussions, but the way I read the
> max packet length, there is nothing in the standard for 10gig that says a
> longer packet is 'not' legal. And there is no mechanism I am aware of that
> prevents a longer packet from coming through to the mac.
>
> Take care
> Joel
> -------------------
>
> Ben Brown wrote:
>
> > Tom,
> >
> > I trust that when you provide this pattern, it is intended to
> > occur on each lane. Is that correct? The problem is that would
> > result in a 1828 byte packet with FCS. This is beyond ethernet's
> > max packet size. Is there a way to trim it down? Could you
> > simply send the first half of the packet only but repeat it
> > often? IPGs will sometimes flip disparity and sometimes leave
> > it alone. Therefore, sometimes the packet will start with the
> > right disparity and other times it will start with the wrong
> > disparity. Either way, the packet is short enough to be a legal
> > length.
> >
> > Ben
> >
> > Tom Lindsay wrote:
> > >
> > > Rich - I mentioned a disparity "flipper" I used before. This allowed
> > > us to build a payload which was roughly twice as long, but the 2nd
> > > half of the payload began with opposing disparity from the 1st half.
> > > In this case, half the pattern was the desired disparity, but other
> > > was not. The half that was not still contains the low frequency
> > > transition density changes, but not the abrupt phase jumps.
> > >
> > > Using the previous pattern list, modify the 1st half to be:
> > > 167 7E's
> > > 1 74
> > > 1 7E
> > > 1 AB
> > > 51 B5's
> > > 1 5E
> > > 1 4A
> > > 5 7E's
> > > The 2nd half, following immediately, would be:
> > > 1 71
> > > 166 7E's
> > > 1 74
> > > 1 7E
> > > 1 AB
> > > 51 B5's
> > > 1 5E
> > > 1 4A
> > > 5 7E's
> > > The 71 is the "flipper".
> > >
> > > Tom
> > >
> > > Tom Lindsay wrote:
> > >
> > > > Folks - I would like to post a simple spreadsheet to the 10GE site,
> > > > but you'll have to tell me how to do it first... The spreadsheet
> > > > provides some analysis on CJTPAT (which stands for Compliant Jitter
> > > > Tolerance Test Pattern in Fibre Channel). If we understand how this
> > > > pattern was developed, it should be easier to adapt it to Ethernet
> > > > needs. I have a lot of additional 8B10B analysis, but it doesn't
> > > > seem appropriate for this discussion.
> > > >
> > > > For now -
> > > >
> > > > PURPOSE/BACKGROUND
> > > > Low frequency (within the passband of the CDR PLL) variations in
> > > > transition density may be combined with ISI jitter or mechanisms
> > > > internal to the CDR, such as phase detector offset. The CDR may
> > > > track these variations, and low frequency jitter can occur within
> > > > the CDR. CJTPAT was developed to test for such situations. After
> > > > each tracking due to a run of low or high transition density, the
> > > > CDR is hit with bit sequences associated with the opposing jitter.
> > > > Because of the tracking, the peak jumps in jitter are more severe
> > > > than if the tracking had not occured. This in turn may lead to
> > > > higher bit error rate.
> > > >
> > > > PATTERN CONTENT
> > > > CJTPAT includes:
> > > > 6x FC IDLEs (24 characters)
> > > > SOFn3- (4 characters)
> > > > Payload (228 characters, including header)
> > > > CRC (4 characters)
> > > > EOF (4 characters)
> > > >
> > > > For Ethernet, obviously the 6x IDLEs, SOF, and EOF will have to
> > > > change. The payload is really what we're after.
> > > >
> > > > The payload consists primarily of 7E's and B5's. However, transition
> > > > characters also exist. These transition characters are VERY
> > > > IMPORTANT to the pattern.
> > > > 167 7E's (30% transition density, minimum sustainable in 8B10B)
> > > > 1 74
> > > > 1 7E
> > > > 1 AB
> > > > 51 B5's (100% transition density, maximum sustainable in 8B10B)
> > > >
> > > > 1 5E
> > > > 1 4A
> > > > 4 7E's
> > > > 1 FE
> > > > Total = 228 characters (57 FC words)
> > > >
> > > > Looking at the attachment, there are particular bit sequences that
> > > > occur. These are highlighted in red.
> > > > The first is in the transition between the 167 7E's and the 51
> > > > B5's:
> > > > In the 74, a single 1 occurs after a string of 4 0's;
> > > > then a few more wide-spaced sequences occur;
> > > > in the AB, a single 0 occurs after a string of 4 1's.
> > > > The second transition sequence is after the 51 B5's:
> > > > in the 5E, 4 contiguous 0's occur after ...0101;
> > > > then a few more 1010... sequences occur;
> > > > in the 1st of the 4 7E's, 4 contiguous 1's occur after ...1010.
> > > >
> > > > These transitions are what make CJTPAT interesting. The long
> > > > repeating runs (167 7E's and 51 B5's) are used to move the CDR
> > > > alignment over, but then these particular bit sequences maximize the
> > > > phase jumps that give the sample and hold circuits their challenges.
> > > > So, don't attempt to build the pattern without these transitions.
> > > >
> > > > PATTERN LENGTHS
> > > > I assumed that one might design their CDR corner frequency to be as
> > > > low as DR/1667. If we convert that corner frequency into a time
> > > > constant (assuming a single pole model), the time constant is approx
> > > > 267 bits or 26.7 characters. The average transition density for
> > > > 8B10B code is approx 60%, so the time constant can be converted to
> > > > approx 160 data transitions.
> > > >
> > > > For CDR shifting to be complete (~95%), at least 3 time constants
> > > > are required for settling.
> > > >
> > > > (The next part may be controversial). Most CDRs show a straight
> > > > dependence between bandwidth and transition density - that is, time
> > > > constant is inversely proportional to transition density, or
> > > > settling is directly proportional to the number of data transitions.
> > > > If the CDR exhibits a "corner frequency" of DR/1667 at 160
> > > > transitions, then
> > > > 3 time constants at 100% transition density (the B5's) results in
> > > > 3 x 1bit/transition x 160 transitions = 480 bits = 48 characters.
> > > > 3 time constants at 30% transition density (the 7E's) results in 3
> > > > x 3.3bits/transition x 160 transitions = 1600 bits = 160 characters.
> > > >
> > > > After building up the pattern, I used a few more of each, mostly
> > > > because of additional constraints of least common multiples with FC
> > > > words and bytes for BER testers.
> > > >
> > > > If folks feel this relationship with CDR bandwidth and transition
> > > > density is not valid, then pattern lengths can be adjusted.
> > > >
> > > > OTHER NOTES
> > > > 1. Starting running disparity is important. The first 7E in the long
> > > > run MUST start with POSITIVE running disparity so the correct
> > > > character (1000011100) is taken from the table. Otherwise, the
> > > > transition sequences do not work.
> > > > 2. The last character is FE. This was chosen to determine a CRC that
> > > > ended in positive running disparity, so that the FC EOF used the
> > > > alternate disparity (1100000101) of the K28.5 (FC IDLEs and SOF all
> > > > use 0011111010). This is probably not critical (see below), but
> > > > provides both polarities of the comma.
> > > > 3. Worse case bit patterns are possible if K characters are allowed,
> > > > but CJTPAT was constrained to be a valid FC frame. K characters were
> > > > not allowed in the middle of the frame. For example, the 4 0's
> > > > followed by a single 1 is the worst case situation of this type
> > > > allowed with D characters. The 5 0's followed by single 1are
> > > > provided in the pattern at its ends, but these are less interesting
> > > > because the CDR's will be somewhat re-centered when they occur.
> > > >
> > > > Hope this is useful.
> > > >
> > > > Thanks, Tom Lindsay
> > > > Vixel
> > > > 425/806-4074
> > > >
> > > >
> > > > Boaz Shahar wrote:
> > > >
> > > >> Rich,
> > > >> In the last meeting (Jan 01), on Thursday, I presented simulation
> > > >> results
> > > >> that show the following:
> > > >>
> > > >> 1.A Random pattern creates a worst jitter then CJPAT for the XAUI
> > > >> compliance
> > > >> channel proposed
> > > >> 2.The existence of a "Killer Pattern" (Called there "MystiCom
> > > >> Killer
> > > >> Pattern") that generate much more jitter then the random pattern
> > > >>
> > > >> The presentation will be in the web soon.
> > > >>
> > > >> Both the random pattern and killer pattern are XAUI valid pattern
> > > >> that may
> > > >> occur during regular operation. It is true that Tom Lindsay
> > > >> explained that
> > > >> when both devices are AC coupled, the CJPAT generates higher
> > > >> amount of
> > > >> jitter (Our simulation was DC coupled). This may be true. Assuming
> > > >> that this
> > > >> is right, the jitter pattern may be a composition of the two.
> > > >>
> > > >> Anyway, the subject is still under study, and I think its too
> > > >> early to
> > > >> determine the pattern, especially due to the fact that in the XAUI
> > > >> Jitter
> > > >> meeting we agree to further study it.
> > > >>
> > > >> Boaz
> > > >>
> > > >> > -----Original Message-----
> > > >> > From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxx]
> > > >> > Sent: Monday, January 15, 2001 11:12 AM
> > > >> > To: HSSG
> > > >> > Subject: Annex 48A Jitter Test Patterns
> > > >> >
> > > >> >
> > > >> >
> > > >> > Ladies and Gentlemen,
> > > >> >
> > > >> > This note contains the XGMII source for Jitter Test Patterns for
> > > >> the
> > > >> > 10GBASE-X PHY. These patterns were approved by Task Force motion
> > > >> on
> > > >> > Friday in Irvine. An updated copy of Annex 48A, including the
> > > >> > proper CRC
> > > >> > values, has been sent for upload to the P802.3ae web site as
> > > >> well. All
> > > >> > patterns, with the exception the Continuous Jitter Tolerance
> > > >> Test
> > > >> > Pattern (CJTPAT) in 48A.5, are exactly the same as or correspond
> > > >> to,
> > > >> > Annex 36A patterns for 1000BASE-X. The CJTPAT is new and
> > > >> > recommended for
> > > >> > jitter testing by the MJS specification referenced in Annex 48A.
> > > >> The
> > > >> > following are the open issues Annex 48A that I'm aware of. I'd
> > > >> > appreciate the identification of any other issues as well as
> > > >> suggested
> > > >> > remedies for open issues:
> > > >> >
> > > >> > 1) The applicability of these patterns to XAUI. My sense is that
> > > >> they
> > > >> > are they are all directly applicable.
> > > >> >
> > > >> > 2) The number of times that the low/high data values are
> > > >> > repeated in the
> > > >> > CJTPAT frame may need to be adjusted to account for line rate
> > > >> > differences between Fibre Channel and 10GBASE-LX4/XAUI. For
> > > >> > example the
> > > >> > low high values are repeated twice within a maximum length
> > > >> > 802.3 frame.
> > > >> > A note in Annex 48A addresses this point.
> > > >> >
> > > >> > 3) Are any other patterns required? I have heard that mixed
> > > >> frequency
> > > >> > patterns which do not obey 8B/10B rules have been suggested.
> > > >> > Personally,
> > > >> > I don't believe that patterns worse than "worst case" patterns
> > > >> > observable in a system environment need be specified. If
> > > >> additional
> > > >> > patterns are required, please make those requirements known
> > > >> ASAP.
> > > >> >
> > > >> > 4) Are there any complaints about jitter compliance testing,
> > > >> > effectiveness of patterns, availability of parts supporting
> > > >> patterns,
> > > >> > etc. associated with 1000BASE-X? P802.3ae can benefit greatly
> > > >> form the
> > > >> > experiences of 1000BASE-X users in this area since the
> > > >> > 10GBASE-X PHY is
> > > >> > based on 1000BASE-X. 1000BASE-X users with jitter testing
> > > >> experience
> > > >> > should feel compelled to speak up now.
> > > >> >
> > > >> > 5) Annex 48A is now mandatory. This means that all 10GBASE-X PHY
> > > >>
> > > >> > components must support all test patterns described in Annex
> > > >> 48A. It
> > > >> > also means that Clauses 47, 48, 54 must all cross reference
> > > >> Annex 48A.
> > > >> >
> > > >> > Best Regards,
> > > >> > Rich
> > > >> >
> > > >> > --
> > > >> >
> > > >> > Ben Brown wrote:
> > > >> > >
> > > >> > > Rich,
> > > >> > >
> > > >> > > Attached are the XGMII sources for the patterns. Please verify
> > > >> that
> > > >> > > this is indeed the packets you want. The first column are
> > > >> > the control
> > > >> > > bits[3:0] in hex and the next column is the data bits[31:0] in
> > > >> hex
> > > >> > > format. There are a few bytes of IPG and a preamble before and
> > > >> some
> > > >> > > more IPG after the packet. The last row in both packets is the
> > > >>
> > > >> > > CRC you asked for. Remember, in the annex, you might want to
> > > >> > > write the bytes of the IPG in big endian format whereas they
> > > >> are
> > > >> > > in little endian format in these files.
> > > >> > >
> > > >> > > Thanks,
> > > >> > > Ben
> > > >> > >
> > > >> > > Rich Taborek wrote:
> > > >> > > >
> > > >> > > > Gentlemen,
> > > >> > > >
> > > >> > > > This note contains Annex 48A as presented to the
> > > >> > 10GBASE-LX4 Working
> > > >> > > > Group during Irvine, CA meetings of January 10-12.
> > > >> > > >
> > > >> > > > David Law: Please upload the file to the IEEE P802.3ae
> > > >> > web site as an
> > > >> > > > Irvine contribution. The title is: "Jitter test
> > > >> > patterns". The author is
> > > >> > > > me.
> > > >> > > >
> > > >> > > > Ben: Please calculate the CRC for the modified RPAT and
> > > >> > JTPAT frames
> > > >> > > > described in 48A.4 and 48A.5, respectively.
> > > >> > > >
> > > >> > > > Tom: Please take a look at the JTPAT patterns in 48A.5.
> > > >> > The number of
> > > >> > > > times that the low/high data values are repeated in the
> > > >> > frame may need
> > > >> > > > to be adjusted to account for line rate differences between
> > > >> Fibre
> > > >> > > > Channel and 10GBASE-X. For example the low/high values above
> > > >> are
> > > >> > > > repeated twice within a maximum length 802.3 frame. What's
> > > >> your
> > > >> > > > suggestion for the exact length of each low/high pattern
> > > >> > and how many
> > > >> > > > times it should be repeated?
> > > >> > > >
> > > >> > > > --
> > > >> > > >
> > > >> > > > Best Regards,
> > > >> > > > Rich
> > > >> > > >
> > > >> > > > -------------------------------------------------------
> > > >> > > > Richard Taborek Sr. Phone: 408-845-6102
> > > >> > > > Chief Technology Officer Cell: 408-832-3957
> > > >> > > > nSerial Corporation Fax: 408-845-6114
> > > >> > > > 2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
> > > >> > > > Santa Clara, CA 95054 http://www.nSerial.com
> > > >> > > >
> > > >> > > >
> > > >> > --------------------------------------------------------------
> > > >> > ----------
> > > >> > > > Name: anx48.pdf
> > > >> > > > anx48.pdf Type: Acrobat (application/pdf)
> > > >> > > > Encoding: base64
> > > >> > >
> > > >> > > --
> > > >> > > -----------------------------------------
> > > >> > > Benjamin Brown
> > > >> > > AMCC
> > > >> > > 2 Commerce Park West
> > > >> > > Suite 104
> > > >> > > Bedford NH 03110
> > > >> > > 603-641-9837 - Work
> > > >> > > 603-491-0296 - Cell
> > > >> > > 603-626-7455 - Fax
> > > >> > > 603-798-4115 - Home Office
> > > >> > > bbrown@xxxxxxxx
> > > >>
> > > >
> >
> > --
> > -----------------------------------------
> > Benjamin Brown
> > AMCC
> > 2 Commerce Park West
> > Suite 104
> > Bedford NH 03110
> > 603-641-9837 - Work
> > 603-491-0296 - Cell
> > 603-626-7455 - Fax
> > 603-798-4115 - Home Office
> > bbrown@xxxxxxxx
> > -----------------------------------------
>
> --
> Joel Goergen
> Force10 Networks
> 1440 McCarthy blvd
> Milpitas, Ca, 95035
>
> Email: joel@xxxxxxxxxxxxxxxxxxx
> Direct: (408) 571-3694
> Cell: (612) 670-5930
> Fax: (408) 571-3550
--
-----------------------------------------
Benjamin Brown
AMCC
2 Commerce Park West
Suite 104
Bedford NH 03110
603-641-9837 - Work
603-491-0296 - Cell
603-626-7455 - Fax
603-798-4115 - Home Office
bbrown@xxxxxxxx
-----------------------------------------