Re: More comments (clauses 49 & 46)
Louis,
Trashing a packet when an error comes logically after the EOP is not
new. It is a characteristic of the 8b/10b transmission code which
supports error control including the detection of propagated running
disparity errors. 8b/10b is used by 1000BASE-X as well as proposed for
10GE use.
With respect to the error probability, I don't have the exact number
either. However, it is clear that either or both CRC and transmission
errors exist in very close proximity to the end of a packet. As I said
before, I'd rather err on the side of caution in order to REDUCE the
possibility of an undetected packet error.
The 8b/10b EOP delimiter checking I'm proposed here is virtually
identical to that employed by 1GE. This delimiter checking was mandated
by Task Force motion in Tampa.
Are you suggesting an alternate proposal based on the false trashing of
packets due to error conditions in very close proximity to the end of a
packet? If so, you'll have to present a detailed analysis of the false
error rate.
Best Regards,
Rich
--
louis lin wrote:
>
> Hi Rich,
>
> I agree on that we need to keep the undetected packet error rate as low as
> possible. Before you guys decide to trash a packet when RS sees an error
> logically comes after the EOP( which is new ) , we need to know in what
> conditions this will happen as a result of packet data error? When it happens,
> what's the chance that those packets will pass CRC check?
>
> I don't have the exactly number here. But I believe the chance to pass
> error packets if we decide not to trash those packets is much lower than
> the chance to drop good packets if we decide to trash those packets, in this
> particular case. Unless we know that the /E/ coming after /T/ can only happen
> when there is an error in the packet data.
>
> Regards,
>
> Louis
>
> Rich Taborek wrote:
>
> > Louis,
> >
> > I don't agree. I believe that the MAC must trash the packet regardless
> > of good CRC because the MAC has no clue as to whether or not an 8b/10b
> > or 64b/66b or combination or multiples of the above are present. I
> > maintain that in all cases, it's NOT OK for the RS to treat it as a good
> > packet in order to keep the undetected packet error rate down. Note that
> > we're splitting hairs here since for 8b/10b in most cases, both 8b/10b
> > and the MAC's CRC check will call the packet bad.
> >
> > Best Regards,
> > Rich
> >
> > --
> >
> > Louis Lin wrote:
> > >
> > > Hi Rich,
> > >
> > > In your case of
> > >
> > > lane 0: DD
> > > lane 1: DT
> > > lane 2: DI
> > > lane 3: DE
> > >
> > > or all the case of /E/ been seen in the same column as /T/ but after /T/.
> > >
> > > If it's from 64/66B PCS, I don't think we need to declare it as a
> > > bad packet. If it's from 8B/10B PCS and the /E/ is a result of the
> > > data. I think the FCS checker in the MAC will trash the packet.
> > > In either case, it's ok for RS to treat it as a good packet.
> > >
> > > Regards,
> > >
> > > Louis
-------------------------------------------------------
Richard Taborek Sr. Phone: 408-845-6102
Chief Technology Officer Cell: 408-832-3957
nSerial Corporation Fax: 408-845-6114
2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
Santa Clara, CA 95054 http://www.nSerial.com