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

Re: SJTP: Minutes from 08-May meeting





Piers,

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

If we use programmable seeds and fixed data inputs, we're
really just using a subset of the normal mode of operation.
In our search for patterns, we're trying to find short,
repeatable representations of normal mode data that provide
some amount of stress.

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

See my response to Tim's email...

> 
> More comments on slide 2:
> 
> "Use existing logic (1+x39+x58 scrambler)" and "One that is easy to
> generate" should be grouped together.

Ok

> 
> "Find a robust test pattern"  Does this mean anything?

I don't know, but it sounds great, doesn't it? No, really.
It is likely that this is covered adequately with the
"sufficiently stressful" bullet. I'm willing to remove it.

> 
> Slide 3:
> 
> Tests requiring the Jitter Pattern
> 
> Not "requiring".  We decided that eye mask didn't and we are debating the
> others.  Could you say "Tests with mixed frequency pattern"?  Then
> elsewhere, when presenting "two seeds" say that one seed is to emphasise the
> unlikely, the other is to represent the typical.

That's fine with me.

> 
> Rise/Fall Time measurement is in OFSTP-4A: "Unless otherwise specified in
> any product-specific documentation, a 2^23-1 PRBS pattern is recommended."
> This is the same standard as defines eye measurement.  As we discussed in
> that context, a pattern which does not emphasise the unlikely would give
> fewer rogue measurements.
> 
> Return loss can be done with the optics switched off: no pattern.

So I should remove this completely or make a new category?

> 
> RIN is a two part measurement: modulated and not.  We haven't specified any
> pattern, probably "Either way" is the right category for now.

Ok

> 
> Slide 7:
> 
> Second thoughts on "Ability to generate and check the pattern in the same
> device at the same time".  This wouldn't apply to a jitter measurement which
> is either tester -> DUT or DUT -> tester, and probably not to a sensitivity
> measurement for the same reason.  It might be nice for a field test of link
> margin, but you could do that with test packets and CRC checks anyway.  When
> else would you be looking at DUT -> DUT, whether loopback or between two
> modules?

I believe the intention here is to require a repeatable
pattern that can be urn in the lab to verify the devices
then again in the field to verify the link. Others with
opinions on this?

> 
> I am looking through D3.0 to see what we have written down, after several
> discussions and reviews, for each of the optical tests.  It's quite varied
> and I hope to report more later, but you wanted feedback today.

Thanks for your thoughts. I'll incorporate these changes
and get them to David Law and on the web site. Please
continue this discussion either here or at next week's
meeting.

Regards,
Ben

> 
> Thank you,
> 
> Piers
> 
> > -----Original Message-----
> > From: Ben Brown [mailto:bbrown@xxxxxxxx]
> > Sent: 08 May 2001 21:19
> > To: serialpmd
> > Subject: SJTP: Minutes from 08-May meeting
> >
> >
> > All,
> >
> > Thanks for your participation. Attached are the minutes from
> > today's conference call. Also, attached is an updated copy of
> > the presentation. Please review before Thursday evening as I
> > intend to make it available to the task force at that time.
> >
> > Thanks,
> > Ben
> >
> > --
> > -----------------------------------------
> > 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
-----------------------------------------