RE: Error handling in 64/66: Was Re: (Another) Question Regarding Open-Loop
Hi David,
In addition to what Birdy says, we also need to protect against burst
errors. Many errors are burst errors rather than single bit hits especially
at these speeds. Also, our error rates are are suppose to be low.
If a packet's framing is questionable, we should not be trying to recover
it. We should discard it.
Pat
-----Original Message-----
From: Bharadwaj S Amrutur [mailto:bharadwaj_amrutur@xxxxxxxxxxx]
Sent: Wednesday, September 20, 2000 9:57 AM
To: David Gross
Cc: stds-802-3-hssg@xxxxxxxx; pat_thaler@xxxxxxxxxxx;
richard_dugan@xxxxxxxxxxx; rick_walker@xxxxxxxxxxx
Subject: Re: Error handling in 64/66: Was Re: (Another) Question
Regarding Open-Loop
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.
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.
Regards,
Birdy
David Gross wrote:
> Hi Birdy,
>
> I've thought about this case some more, and I beleive we can go from the
> E state to the S state without allowing a 3-bit error condition to occur
> by simply adding a variable to the TX and RX processes respectively. If
> we have a variable which stores the previous input (eg: rx_prev <=
> rx_tobe_decoded) then we can use it as a qualifier to know whether or
> not the transition from the E state to the S state is valid. In the case
> of the 3-bit error you mentioned where a preamble error causes a jump to
> the E state, and a 2 bit error in preamble causes data to look like S,
> then the qualifier will catch this and not allow the E to S transition.
> I've attached a pdf to further descibe the implementation I was thinking
> of. The actual modifications needed are shown in red. Please let me know
> what you think, I think this may work.
>
> -Dave
>
> Bharadwaj (Birdy) Amrutur wrote:
> >
> > >Yes you're right, I must have been looking at an older slide deck. But
> > >now that I see the new TX process and RX process, I have another
> > >question. If you allow for the sequence TZZZZZZZ ZZZZSDDD, what happens
> > >if you get an error somewhere. It would appear as if the condition to
> > >get out of the error state is to wait for ZZZZZZZZ, but this won't
> > >appear between frames given the above circumstance and the next frame
> > >will also be "errored". Perhaps I'm mistaken, but it would seem as if
> > >the next perfectly good frame will be trashed? Is this correct?
> > >
> > >-Dave
> >
> > Dave, Your observation is correct. The way the state m/c is right
> > now, if there is a error, it doesnt get out of the E state till
> > a clean Z frame. A problem with this is if you have back to back
> > packets with min IPG spacing, you might end up with a S frame
> > immediately following a T frame and there wont be any intermediate
> > Z frame for a while.
> >
> > 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).
> >
> > Regards,
> > Birdy Amrutur
>
> ------------------------------------------------------------------------
> Name: SeqProcSug.pdf
> SeqProcSug.pdf Type: Portable Document Format (application/pdf)
> Encoding: base64