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

SJTP:Phantom sync headers




All,

Jonathan brought up an interesting point that I have
elaborated upon below. Those who have begun or are
interested in beginning to search for patterns should
probably keep this in mind.

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


Ben,

Good insights. I hadn't taken my thought process this far. This is clearly a
bit more complicated than I originally thought.... I guess this further
underscores my comments about our ability to pick the right pattern in the
next several months....

jonathan

> -----Original Message-----
> From: Ben Brown [mailto:bbrown@xxxxxxxx]
> Sent: Thursday, May 10, 2001 9:43 AM
> To: Jonathan Thatcher
> Cc: John F. Ewen Ph. D. (E-mail)
> Subject: Re: Test pattern generation requirements....
> 
> 
> 
> Jonathan,
> 
> I would be more than happy to add this to the presentation.
> If the people actually selecting the seed want to provide a
> white paper to cover their approach, that would be great.
> This would certainly be a component to add to such a white
> paper as it must be part of the selection process.
> 
> I'll make the following available to the reflector to
> make sure the pattern searchers are aware of the exact
> requirements:
> 
> Our pattern has been selected to be 8448 bits long or 128
> 66-bit blocks long. The PCS sync machine only requires 64
> proper sync headers to get into alignment. If we chose a
> pattern with 64 good phantom sync headers followed by fewer
> than 16 bad phantom sync headers in the next 64 blocks, we
> would gain a phantom sync and have errors in every block. 
> 
> We need to make sure there are never 64 contiguous good
> phantom sync headers or, if there are, that there are at
> least 16 bad phantom sync headers in the next 64 blocks
> to make sure that this phantom lock is lost and a slip
> occurs to push the alignment towards the proper lock
> location.
> 
> Ben
> 
> Jonathan Thatcher wrote:
> > 
> > Ben,
> > 
> > Perhaps we should document the requirement first, and then 
> solicit input to
> > see what the conditions are that guarantee we can't have a phantom
> > synchronization. Certainly there is a pattern length 
> dependency. Is it
> > strictly statistical or is there some kind of deterministic 
> characteristic?
> > Testing after the fact isn't very hard. The question will 
> be where do we
> > document this?
> > 
> > In the standard, we don't have to document what the 
> criteria were for
> > selecting the pattern (seed / data).  But somewhere, we 
> need to be able to
> > find this information for future reference. Would this be your
> > presentation(s) on the our reflector? Should there be a white paper?
> > 
> > jonathan
> > 
> > > -----Original Message-----
> > > From: Ben Brown [mailto:bbrown@xxxxxxxx]
> > > Sent: Wednesday, May 09, 2001 6:16 PM
> > > To: Jonathan Thatcher
> > > Cc: John F. Ewen Ph. D. (E-mail)
> > > Subject: Re: Test pattern generation requirements....
> > >
> > >
> > >
> > > Jonathan,
> > >
> > > I knew there was a reason we kept you around :)
> > >
> > > This is a good point. Unless someone is willing to develop
> > > the mathematical proof (would Pat be a good one for this?),
> > > I suggest that it is probably easier to simply test each
> > > pattern that we develop for this feature (or preferably for
> > > the lack of it).
> > >
> > > Ben
> > >
> > > > Jonathan Thatcher wrote:
> > > >
> > > > We have a requirement for the pattern that we may have 
> forgotten to
> > > > think document.
> > > >
> > > > We need to verify that there are no bit positions in 
> our subpatterns
> > > > can can behave as though it were the synchronization bit
> > > (only for LAN
> > > > PHY).
> > > >
> > > > Or, we need to demonstrate mathematically that given the way the
> > > > scrambler works, that this cannot occur.
> > > >
> > > > jt
> > > >
> > > > Jonathan Thatcher
> > > > Principal Engineer, World Wide Packets
> > > > Chair, IEEE P802.3ae Task Force
> > > > Office: 509.242.9228  Fax: 509.242.9001
> > > > jonathan@xxxxxxx
> > > >
> > > >
> > >
> > >
> > > --
> > > -----------------------------------------
> > > 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
> -----------------------------------------
>