RE: PRBS23 test pattern -- RE: [802.3ae]802.3ae PRBSsareupsided own
You could be correct, although the SONET/SDH testers that I have used you
would ordinarily define the mux structure to be tested (i.e. VC4, VC3, VC12,
VC11, ...). These testers them demultiplex the payload from this mux
structure (i.e. remove all frame overhead), and then test the underlying
payload for a pre-programmed data structure (i.e. PRBS). Once the multiplex
is defined the testers that I have worked with would expect a continous PRBS
sequence to exist within the payload of the selected multiplex. Again, I
would be concerned because periodically resetting the the PRBS would tend to
disrupt this sequence.
[mailto:owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx]On Behalf Of THALER,PAT
Sent: Thursday, March 07, 2002 4:59 PM
To: jirwin@xxxxxxxxxxxx; 'Tim Warland'; 'Nepple, Bruce'
Subject: RE: PRBS23 test pattern -- RE: [802.3ae]802.3ae PRBSs
Even if you don't reset the PRBS each frame, frame overhead itself disrupts
the PRBS. This will happen nine times per frame because overhead is sent at
the beginning of each frame row. Therefore, the BERTs that the Framed PRBS
is useful to are Sonet/SDH BERTs. The ones I've looked at expect the defined
SONET/SDH test frames and in those the PRBS is reset at the beginning of
Therefore, they should reset the PRBS each frame. It is what SONET/SDH
testers expect. Non-SONET/SDH testers will lose synchronization to the
stream when the overhead starts so it doesn't matter that the PRBS is also
reset after the overhead in row 1.
The PRBS31 which is not framed (but which is optional) will be better for
use with non-SONET/SDH BERT testers.
From: John Irwin [mailto:jirwin@xxxxxxxxxxxx]
Sent: Thursday, March 07, 2002 8:23 AM
To: 'Tim Warland'; 'Nepple, Bruce'
Subject: RE: PRBS23 test pattern -- RE: [802.3ae]802.3ae PRBSs areupside
To make the PRBS most useful you should not reset the PRBS each frame. The
PRBS is a free-running, self-synchronous data stream. Once the down-stream
device has locked onto this sequence it will forever be locked (as long as
there is no disruption to the sequence). A 23rd order PRBS monitor can lock
onto the PRBS sequence once it has accumulated 23 bits. From there it can
sync to the bit-stream and accumulate BER statistics. Reseting the PRBS
each frame is not a good ideal, and would cause inter-operability problems
(it creates disruptions). The PRBS polynomial that I have seen used be some
x(n) = 1 + x(18) + x(23)
Hope this helps,
[mailto:owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx]On Behalf Of Tim
Sent: Thursday, March 07, 2002 5:56 AM
To: Nepple, Bruce
Subject: Re: PRBS23 test pattern -- RE: [802.3ae]802.3ae PRBSs areupside
When we were developing the test patterns, we said that we would put
a stake in the ground, and allow the user community to provide feedback
on whether these test patterns were effective. I know this work has
been done for the mixed signal test pattern in clause 49, I don't know
if anyone has validated the test pattern for clause 50.
From discussions I had yesterday, I can see that there is confusion with
regards to the PRBS23 generator inside the WIS test pattern. I would
propose changing the test pattern description such that we drop the
to O.172. Then we can either explicitly define the PRBS23 or use the
PRBS31 (since it's already there) and furthermore, not invert the SPE
in alternate frames. (Somewhat simpler)
However, this section of the text is not really open to edit on the current
ballot cycle, and we still haven't validated whether the test pattern is
relatively painless to generate and sufficiently stressful. Furthermore, it
is a disservice to those who have implemented the current definintion.
What are your thoughts, Bruce? Anyone?
"Nepple, Bruce" wrote:
> I agree that the PRBS23 uses "inverted data". I think
> O.150 is clear on this.
> I also maintain that the PRBS23 output should be taken from the
> MSB of the register, as implied in O.150 section 4. In section 4
> it refers to the "output of the shift register" as opposed
> to the input to the shift register (which we are using as the output
> in the optional PRBS31).
> The payload data will differ between implementations since
> we reset the prbs every frame. If a vendor wants to build in
> the pattern, and we are not concise about where in the shift register the
> output is located, and whether it is inverted,
> they better build in both sequence starting
> points, and both polarities with respect to the CID.
> > -----Original Message-----
> > From: Tim Warland [mailto:twarland@xxxxxxxxxxxxxxxxxx]
> > Sent: Wednesday, March 06, 2002 10:53 AM
> > To: Nepple, Bruce
> > Cc: ieee
> > Subject: Re: [802.3ae]802.3ae PRBSs are upside down
> > "Nepple, Bruce" wrote:
> > > <snip>
> > >
> > > My issue is that when you apply this to the PRBS23 (which
> > is reset every frame),
> > > you end up with incompatible payloads in WIS test mode.
> > This means that if
> > > test equipment vendors build in patterns (not required by
> > the specification),
> > > they need to have all the combinations of inverted and
> > delayed available.
> > > Seems unnecessary. It's not really important how it is
> > done, just so it
> > > is specified consistantly and everyone does it the same way.
> > The PRBS in the WIS test pattern is separate from the PRBS31
> > we are discussing
> > for both clause 49 and 50.
> > The WIS test pattern was designed specifically for bit based
> > BERT testers. This
> > test pattern will not work in any other kind of tester
> > because the payload PRBS
> > is reset and truncated every frame. The PRBS23 is specified
> > in accordance
> > O.172 (Annex A.2) which references O.150 for the PRBS23 pattern.
> > From O.150, the PRBS23 has the inverter for (what we call)
> > the normal frame, and
> > does not have the inverter for (what we call) the inverted
> > frame. In retrospect, I
> > see that there is no real advantage in inverting the entire
> > SPE, only inverting
> > the CID would have been sufficient. It's one of those things
> > where there is no
> > compelling argument to change it.
> > Is that the answer you were looking for?
> > --
> > Tim Warland P. Eng.
> > Applications Engineer
> > Quake Technologies (613)270-8113 ext 2311
> > Tough Times don't last, tough people do
Tim Warland P. Eng.
Quake Technologies (613)270-8113 ext 2311
Tough Times don't last, tough people do