Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: SJTP: Minutes from 08-May meeting





Tim,

Your comments are focused on WAN testing. It sounds like
you're saying the payload content is irrelevant to the
testing being done. This would tell me that the option
we choose for WAN testing should be the one that is the
easiest to implement. Am I reading your comment correctly?

I think we're developing a system level jitter test. One
of the things we want to do is to run this test system to
system and be able to detect if the patterns comes through
with errors or without. One way to do this would be to use
the LAN pattern as the SONET payload. This payload is
irrelevant (from your comments) from a test perspective
but using this pattern allows the test to be valid
end to end.

Did I misinterpret your comment?

Ben

Tim Warland wrote:
> 
> DAWE,PIERS (A-England,ex1) wrote:
> 
> > Ben,
> >
> > Your slide set says "Motivations - Why not use the 1+x28+x31 PRBS?".  This
> > was useful because it helped clarify the issue of what we are trying to do.
> > The question I have been trying to bring before the group is not that, but
> > "Why wouldn't we measure (a DUT) in its normal mode of operation?"  And the
> > arguments I have heard are basically for convenience, not for
> > interoperability.
> >
> > I looked at SONET (GR-235) and didn't find anything relevant about test
> > patterns.  ITU-T's policy, I believe, is to restrict itself to specifying
> > the behaviour of the normal mode of operation at the available (optical)
> > ports only; a "black box" specification.  Presumably SONET systems are
> > tested with SONET frames running: loaded with what?  empty?  doesn't matter?
> > I guess it may be "can't matter", so that networks can be tested remote from
> > the terminal concerned (which may be owned by a different operator).  It's a
> > feature of our line code, even more than SONET carrying speech, that traffic
> > and idle/LF/RF all appear on the wire like random data with very predictable
> > statistics, so testing with any of these will give the same results, with
> > very predictable statistics or error bars.
> 
> (That should be GR-253. Look at section 5.6 as a starting point)
> 
> I have limited experience with SONET testing, however from my observations,
> the data pattern is always irrelevent. When testing a PLL, the concern is
> the ability to recover the clock from a data stream with induced jitter or
> wander.
> In all cases, the stabalized clock which is generated as the reference out of
> the CRU is the item to be measured. The data is discarded.
> 
> SONET test patterns are not defined in any of the specs I've read for jitter
> and
> wander. SONET framing and scrambling is always used.  I have observed
> lab tests where an all 1's data pattern is used for jitter and wander analysis
> (remember this is the input to the SONET framer, not the observed
> serial stream).
> 
> It is my assumption that the maximum and minimum frequency excursions
> out of the SONET framer are limited by the scrambler. So in essence
> they test the frequency range of the scrambler against the frequency
> range of the PLL in the unit under test. The recovered clock is then
> compared to MTIE plots which tests the margin in the PLL design.
> 
> We must ask ourselves if the ad-hoc is trying to develop a system level
> jitter test, or a PMD component level test. The answer to this question
> shall drive the task force forward. For instance, if we are looking at a
> PMD component test, we should not make the assumption that the
> test pattern is generated within the PCS block. The test pattern should
> in this case be generated externally. This is the difference between
> GR-253 and G.957.   I believe this echo's Pier's comments.
> 
> --
> Tim Warland     P.Eng.
> Hardware Design Engineer  Broadband Products
> High Performance Optical Component Solutions
> Nortel Networks                (613)765-6634


-- 
-----------------------------------------
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
-----------------------------------------