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