SJTP: Minutes from 24-April meeting
All,
Attached are the minutes from the conference call that was
held on 24 April. Thanks to all for attending. I've also
attached the latest feature list which now encompasses a
few more high level items that we all agreed to. I'm still
working on the proposal comparison. I'll try to have that
out today. The call for tomorrow is at the same time and
number as the past 2 weeks. Please see the attached minutes
for the details.
Tom, Paul, Norival, Tim,
The current attendees simply don't have the expertise to try
to make decisions regarding a WAN pattern. We feel there are
3 options that can be used for this, items 1, 2 & 4 below.
It seems that there has been some strong consensus that the
A1/A2 pattern is sufficiently stressful that any test pattern
must include it. For this reason, we feel that item 3 below
is not a viable option. It is included here for completeness,
only.
1) No modifications to the WIS, use the LAN pattern as the
WIS payload
2) Use the A1/A2 pattern for framing with no other overhead
bytes and do not restrict the frame duration to 125 usec
3) Use the LAN pattern directly, in a similar fashion to what
is currently defined in D3.0 (i.e., no A1/A2 framing)
4) Do nothing and inform WIS implementors about the pattern
specified in ITU-T G.957.
Without increased participation from WAN advocates, as an ad-hoc
all we are willing to do in May is present what we (hope to)
come up with for a LAN pattern then ask for feedback from the
group at large what to do with the WAN.
Specifically, (Tom!) there are references to a Clause 50 WAN
pattern in Clause 52.8.11 that will not exist. This somehow
needs to be addressed.
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
-----------------------------------------
Second conference call of the Serial Jitter Test Pattern ad-hoc
17-April-2001, 1:00pm EDT
Attendees:
Ben Brown
Anthony Sanders
Tom Lindsay
Jonathan Thatcher
Gareth Edwards
John Ewen
Piers Dawe
Jennifer Evans
Don Alderrou
Pat Thaler
Bill Reysen
Proposed Agenda:
Review the feature list that I updated last week.
Continue with Jonathan's list
Add any that are missing
Unless we're done early, I'd like to push out specific
proposals until next week so we all have a chance to
review the features and the proposals one more time.
Discussion:
Tom Alexander's & Jonathan's emails were discussed.
If PMA/PMD spec doesn't change between WAN and LAN then
it is likely that we need different patterns.
Using the same methodology, it might not be too difficult
to have different thresholds for WAN and LAN specs for
PMA/PMD. This might be too much work. Though these
thresholds might exist, we don't know how to quantify
them.
The result of this means that the patterns need to be
different.
This leaves options 1, 2 & 4 from my list:
1) No modifications to the WIS, use the LAN pattern as the
WIS payload
2) Use the A1/A2 pattern for framing with no other overhead
bytes and do not restrict the frame duration to 125 usec
3) Use the LAN pattern directly, in a similar fashion to what
is currently defined in D3.0 (i.e., no A1/A2 framing)
4) Do nothing and inform WIS implementors about the pattern
specified in ITU-T G.957 (as described in the minutes and
the attached email from Piers Dawe - CID_pattern).
Direction might be to select between 1 & 2 then offer that
to the group against option 4. Let the larger group decide.
These patterns are not essential for interoperability,
rather they are a convenience. Does the lack of WAN
interest mean they are happy with the ITU G.957 or do
they not know that a problem exists (if one indeed does).
Let's focus on the LAN, allowing this pattern to be
put in the payload of a WAN.
We could make all the information available in the
presentation without a recommendation.
We have established that A1/A2 is statistically
unusual. If the WAN pattern has both the A1/A2 and
"anything else", we have a comprehensive pattern. The
stress is generated from the A1/A2, not necessarily
from the random stream.
Can we simply use the SONET scrambler as the WAN pattern?
We need to let Tom know
Pattern is expected in clause 50
You choose one of the 3 options
we don't have enough input to recommend
Next Issue:
It would be nice to have a simple methodology to get an
inverted pattern. Can we invert the seed and data in to
get an inverted pattern or simply invert the output of
the generator?
Info from John Ewen late in this phone call determines that
if the seed and data input are inverted, you do indeed get
an inverted pattern.
List of what the point of this process is about:
1) Guard oneself against substandard PLL designs
2) Shorten measure times
3) Make measurements more consistent
4) Do diagnostics
5) Fill a hole in the standard :)
One more step before we look at proposals:
Need a short list of tests that must be supported by the
patterns;
Jitter
OMA - Optical power measurement
Extinction Ratio
Mean Power
Spectral Width
Rise & Fall time
Encircled flux (?)
Side Mode Suppression Ratio
More???
Average Optical Power
Dispersion
Patterns to affect these tests:
square wave
random/jitter (LAN Pattern)
Average optical power - 2^23-1 pattern - might need to
be changed - This is likely to be pattern independent so
changing this might allow for test houses to require
less equipment.
Dispersion also uses 2^23-1 but only because we didn't
have a LAN pattern
Do we need multiple square waves?
Longer period - preferred for pretty much everything
5 1s & 5 0s as opposed to 1 1 and 1 0
Eye Mask testing - problem is low sample rate and long pattern
length, mask testing can be impracticle.
If we can control the reset rate, the length can be fully
controlled.
Do we need a unique pattern for this or can we do this with
the existing pattern.
Question:
How do we handle the situation when we select a pattern
today that results in some devices passing the test and
being sold into the market. We later find a more agressive
pattern and this breaks optics in the field.
This has some history with CRPAT/CJTPAT - this came out
after FIbre Channel devices existed and started breaking
devices in the field.
This is perhaps more common with block codes and less common
with scrambled codes. This is the point of using a scrambled
code. Given unusual patterns occur very rarely where in
block codes, tough patterns can be repeated as often as
the particular bit pattern occurs in a packet.
It is more likely that, as we learn more about these
devices, we find that these difficult patterns are not
particularly necessary and we can actually get away with
using simpler ones.
With high margins and low volumes, more time is spent
making sure a design works. If volumes increase and
designers learn how to push the envelope, more devices
are closer to the spec limit and have less margin than
those earler devices.
JT #11) Pattern flexibility
Some were against flexibility in the proposals. Is this
because we are going to ask people to improve them?
When we find something better, will we get maintenance
requests? Could this result in obsolete parts in the field
because existing parts no longer pass?
As a standards body, the question we must ask ourselves
is "Are potential changes really solving a problem or is
this a tweak that doesn't really fix anything?".
The point of our effort is not to spec multiple patterns
but rather to spec a design that enables multiple patterns.
The difference is subtle but real.
Action:
I will review the proposals and list differences
When I do a comparison between proposals, also provide
difference between how it works in mission mode?
Why do we need a different pattern between how it works
in mission mode?
Biggest reason is repeatibility.
I'm not good at comparing actual patterns. What is the
mission data that should be compared against? With a
pattern, you can test a pattern that should only occur
once per day. To get this with mission data, you need
to test for a full day...
If Piers can provide a potential pattern, Pat and John
might be willing to review it.
The agenda for next week will be to review the list of
differences between the proposals on the table and,
using the features that we've been discussing as our
reference, begin the process of reconciling those
differences.
Thanks to all for attending!
Next conference call is set for next week at the same time
and number:
CONFERENCE INFORMATION:
----------------------
* Start Date: 04/17/01 TUE
* End Date: STANDING
* Start Time: 01:00 PM EDT
* End Time: 2:30 PM
* Duration: 001 hr 30 min
* Conference Host: BENJAMIN BROWN
* Conference Name: SERIAL JITTER TEST PATTERN
* Conference Arranger: BENJAMIN BROWN
* Arranger Phone Number: (603)641-9837
PARTICIPANT INFORMATION:
-----------------------
All Participants should use the following information
to reach the conference call:
* PARTICIPANT CODE: 221497
* Toll Free Dial In Number: (800)851-1769
* International Access/Caller Paid Dial In Number: (775)324-0362
Call ended at 2:35 EDT
30-April-2001
Objectives of the Ad-Hoc:
Guard against substandard PLL designs
Shorten measure times
Make measurements more consistent
Perform diagnostics
Fill a hole in the standard :)
Types of tests that need to be supported by the patterns:
Jitter
OMA - Optical power measurement
Extinction Ratio
Mean Power
Spectral Width
Rise & Fall time
Encircled flux
Side Mode Suppression Ratio
Average Optical Power
Dispersion
Types of patterns required:
square wave(s)
random/jitter (LAN Pattern)
The intent is to focus on a pattern for LAN Serial testing
only. Without more participation from WAN advocates, we don't
have the expertise required to develop a WAN pattern.
Features of an Ideal Pattern:
High Priority
* A Pattern needs to be short enough to fit into BERT memory
(#1 from JT list)
MAX memory depth is 1 MByte
TYP memory depth is 64-128 kByte
Pattern length should be (much?) less than this
* Pattern Contents
(#2,#3 & #4 from JT list)
1) Long run lengths with no transitions
44 bit lengths statistically occur every ~ 1/2 hour
48 bits occur once per day
50 bits provides the order of magnitude margin we need
2) Long run lengths of low transition density
3) Rapid change in transition density
low to high is more stressful
2 is a subset of 3
4) Extreme running disparity
5) Rapid change in running disparity
6) Polarity biased, stressing a particular data edge
Stresses PLL that only uses 1 clock edge, rather
than both
This could be picked up as a subset of number 4
* Ability to generate and check the pattern in the same device at
the same time
(#6 from JT list)
Implementers should not use the same logic for both generation
and checking, eliminating any possibility of a loopback test
* Error counter attributes
(#8 from JT list)
The counter be sticky at max value
This counter must have the ability to reset for a new measurement
* Ability to synchonize in the presence of bit errors
(#10 from JT list)
This should be very possible at BER of 10^-5 or perhaps
even higher (10^-3?)
For the purpose of discussion, a bit error is defined
as any error in a 66-bit block
Medium Priority
* Ability to generate low and high frequency square wave patterns
(#5 from JT list)
This allows for transmitter measurements such as OMA and E/R
A receiver need not be capable of capturing these patterns
Non-Essential but "nice to have"
* Ability to measure the BER "down" to a particular value
(#7 & #9 from JT list)
The existing 8-bit counter in the spec covers 10^-8 BER
when read once per second.
To detect higher BERs, this could be read more often or
an implementation could provide a wider counter
* Stressful, but reasonable, for EMI testing
(#14 from JT list)
Not Yet Qualified:
11. Pattern flexibility.
12. Technique works for both the WAN and LAN phy (WAN must include the A1/A2
sequence; LAN must not).
13. TBDs are based on an probability of occurrence equal to once per day for
single bit errors.