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

RE: Error handling in 64/66:




Birdy,

Proposal 2 matches what I think should be done. It is more
consistant with the way other 802.3 PMDs react to a coding
error.

Pat

-----Original Message-----
From: Bharadwaj Amrutur [mailto:amrutur@xxxxxxxxxxxxxxxxxxxxxxxx]
Sent: Thursday, September 21, 2000 10:47 AM
To: dgross@xxxxxxxxxxxxxxxxxx
Cc: stds-802-3-hssg@xxxxxxxx; pat_thaler@xxxxxxxxxxx;
richard_dugan@xxxxxxxxxxx; rick_walker@xxxxxxxxxxx
Subject: Re: Error handling in 64/66:





Hi David, 

I think I understand what you are proposing now. Your new variable is
decoupled from the current or past states, it merely tells what is the
type of the preceding frame. I think that should work. (proposal 1)

Just to compare:
(proposal 2)
> > We probably should modify the state diagram by allowing transitions
> > from E state to Z, D, or T states. (We need to disallow transition
> > from E to S to prevent a certain 3-bit error condition from
> > slipping through).
> >



Just to compare the behaviours:
D(S) means a 2 bit error falsifies a D frame into a S frame

--------------------------------------------------------------------------
input frames:      D   D    D   T   S   D   D   D   T   S   D(S)  D   D
error location:        ~                                ~

(proposal 1)
state              D   E    E   E   S   D   D   D   T   E   E     E   E
rx_prev              D    E   D   T   S   D   D   D   T   E     S   D


(proposal 2)
state              D   E    D   T   S   D   D   D   T   E   E     D   D
 

--------------------------------------------------------------------------
input frames:      D   D    D   T   S   D   D   D   T   S   D  D  D
error location:                 ~                       
(proposal 1)
state              D   D    D   E   E   E   E   E   E   S   D  D  D
rx_prev              D    D   D   E   S   D   D   D   T   S  D  D


(proposal 2)
state              D   D    D   E   E   D   D   D   T   S   D  D  D
 

--------------------------------------------------------------------------
input frames:      D   D    D   T   Z   S   D   D   D   T   S   D  D
error location:                     ~                   
(proposal 1)
state              D   D    D   T   E   E   E   E   E   E   S   D  D
rx_prev              D    D   D   T   E   S   D   D   D   T  D   D


(proposal 2)
state              D   D    D   T   E   E   D   D   D   T   S   D  D  D
--------------------------------------------------------------------------

In summary:
Both proposals handle the condition of back to back frames with
minimal loss of good packets.
proposal 2 allows for error rate monitoring at the frame level.


Hope that captures what you were saying.

regards,
birdy






>Hi Birdy,
>
>Please see comments below.
>
>Bharadwaj S Amrutur wrote:
>> 
>> Hi David,
>> 
>> Your pdf suggests that in the E state, check to see if the previous state
>> is a T before allowing a transition from E-> S.
>> This doesnt work. Consider the situation where,
>> DDDDTSDD has 1 bit error in S sync, and 2 bit error in the following D
and
>> gets converted to
>> DDDDTESD  due to a 3-bit error. What you proposed will let this through.
>
>This isn't true according to what I had in mind. The condition to go to
>the S state from the E state requires that the previous value is a valid
>T state. In this case (and the cases you mention below, the 1 bit error
>in sync causes the previous value to not be a valid word (T or
>otherwise) and the E->S transition is prevented.
>
>Just to clarify because I think there might be some confusion, in your
>example, for an E->S transition, the current state is what "appears" to
>be an S, and the previous state is what was actually the 1-bit sync
>error.
>
>> 
>> Other similar cases are:
>> ZZZZZSDDD getting converted to
>> ZZZZZESDD or:
>> 
>> DDDDDDDD getting converted to
>> DDDDESDD
>> 
>> If you really want to allow for a E->S transition, I would suggest:
>> In the E state, if (prev state was also E), then allow a transition
>> from  E to S. Because it takes atleast 2 bit errors to  be in E state for
>> two consecutive cycles (in the new state m/c where we allow
>> transitions from E to Z,T and D)  and it would take an additional 2bit
error
>> to falsify a D into an S giving 4bit protection. (Maybe this is what you
>> had in mind and your pdf has a typo ?) You can also do something similar
>> on the T end to preserve symmetry. i.e., accept a packet in situations
like
>> DDDTE(E+).. , whereas the current state m/c rejects it.
>> 
>> The question is what do we buy in return? If link bit error rates are low
>> enough,
>> the modified state m/c with E-> S transition will result in  a negligible
>> improvement
>> in the packet throughput. Also the link error monitoring is only
marginally
>> improved.

>My only concern was that if minimum IPGs are constantly being
>transferred to maximize the data rate then it is possible that it would
>take a significantly long period of time to exit the Error state using
>the current convention (no 64b/66b Z codeword will be found for a while
>if at all). By allowing a min IPG to be 9 and by allowing the T->S
>transition, it seems that the schematic also allows for the possibility
>that only T->S transitions are present (no T->Z->S) and thus even with a
>very low BER, even one error can cause a case where we are stuck in the
>Error state.
>
>I'd just like some reasurance that this can't happen, either because the
>state m/c won't allow it to, or because we can be reassured that it is
>impossible to ONLY receive min IPGs and T->S transitions. (I actually
>prefer modifying the state m/c rather than making a restriction like
>this...)
>
>Please let me know if this is a valid concern, or if I've neglected to
>account for something. Thanks.
>
>-Dave