[802.3ae_Serial] SJTP: Minutes from today's meeting.
All,
Let's try this again. I clicked the SEND button a bit
prematurely...
Attached are the minutes from today's conference call. A
good discussion on the WAN patterns. The LAN info that
John Ewen sent out didn't make it to the reflector so
other attendees couldn't comment on it. I'll send this
info out shortly.
The call next week is on the eve of a US holiday. If your
plans allow, please intend to dial in:
* Conference Name: SJTP
* Start Time: 01:00 PM EDT
* End Time: 2:30 PM
* PARTICIPANT CODE: 770794
* Toll Free Dial In Number: (800)886-9041
* International Access/Caller Paid Dial In Number: (865)525-3420
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@amcc.com
-----------------------------------------
Conference call of the Serial Jitter Test Pattern ad-hoc
26-June-2001, 1:00pm EDT
Attendees:
Ben Brown
Pat Thaler
Don Alderrou
Piers Dawe
Tim Warland
Bill Reysen
Proposed Agenda:
Discuss the WAN pattern in regards to whether to require
a SONET framing BERT or a bit-based BERT. Then select some
of the options we outlined.
Discuss the seeds and waveforms that John Ewen sent out.
Discussion:
Attendees of last week's call showed a preference for
bit-based BERTs not SONET-based BERTs.
As an implementor, this is less convenient.
Pat's comments:
1) Drop jitter from the name
2) The receiver SHALL receive the mixed frequency pattern and
report errors. This is not optional.
3) The annex should not require what test uses what pattern.
This should be part of clause 52.
4) The PRBS value specified is not clear. This should be the seed.
(Did I miss one here?)
5) There are a few overhead bytes that must be defined differently
for working with a bit-based BERT (J0, K1, K2, G1 ...)
6) 2 SONET frames seems long for bit testers. Why is it that
this pattern can't use a SONET based tester?
Only the payload goes to the payload part of the tester. This
won't work without a free-running PRBS. You get an error every
frame while the PRBS within the tester has to resynchronize.
Can it be programmed to look for a fixed pattern in the payload?
7) There seems to be interest in having neutral disparity across
the pair of frames. Not sure this is interesting for patterns that
are this long. The components where this is interesting have much
less "memory" than the length of these patterns. Also, given the
scrambling, the disparity is likely pretty neutral, anyway. The
9 byte CID on its own does not affect the disparity of this 155k
byte disparity neutral frame. This should not be a concern.
8) If we want to focus on bit testers, we should reconsider the
use of a full SONET frame.
Framer already knows how to make a frame.
Are there lower end testers that don't have enough memory?
Probably not, at least that can run this fast.
Can the BERT sync on these quickly? Some concern that it can't.
The WIS receiver should sync up quickly. A bit-based tester
can certainly have this problem. Unless it has the capability
to sync on a particular bit pattern (NxA1+MxA2).
Future proof:
Make seed programmable
Make CID invert
Given that PRBS is scrambled, what's the advantage of making
it programmable.
J1 will be a constant but should be something that is used to
verify the CID. This is different from normal operation. Another
possibility is to use a value that holds some meaning to the
receiver that this isn't normal 10GE operation.
Fixed stuff will need to be checked on receive because this is
where the stress is (after the CID). The J1 alone is not enough.
If the CID loses sync, the J1 will be bad. If you simply lost
some tolerance on your eye, the J1 may be okay but there would
be errors in the fixed stuff.
Could move the transmit alignment so fixed stuff doesn't
follow CID (and so it doesn't need to be checked) but that makes
life more difficult for the transmitter.
Need to make sure it is clear that the SONET scrambler is NOT
turned off.
Is the squarewave in the same range as for LAN? Yes.
Is there a problem with AC coupled interfaces? No, LVDS is DC
coupled. This problem doesn't exist or the A1 & A2 wouldn't
work.
This should probably not be in an Annex. Clause 49 has it in
the general text.
LAN patterns from John Ewen:
These did not get on the reflector.
Piers gave a short description since no one else on the call
has access to them.
Provide the transmission data for both pattern and the invert.
Provide the waveforms for both the pattern and the invert.
I'll send a note to John telling him about this.
Thanks to all for attending!
Call ended at 2:05 EDT