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

Re: [EFM] Re: [802.3ae] query -LayerMgmtReceiveCounters





Welcome to Ethernet.  What Shimon describes is the way Ethernet has
behaved for 29 years.  All he did was to accurately answer a frequently
asked question concerning the behavior of a specific error indication.

A review of the MIB attributes defined in clause 30 reveals additional
error statistics which provide additonal error detection capabilities. 
See for example 30.3.2.1.5 aSymbolErrorDuringCarrier, which is an attribute 
in the PHY. You should also read the description in 
30.3.1.1.6 aFrameCheckSequenceErrors, as well as 5.2.4.3 for the detailed 
description of LayerMgmtReceiveCounters.

Howard

Roy Bynum wrote:
> 
> Shimon,
> 
>  From what you are saying then is that bit errors in certain locations may
> not be recognized as bit errors.  This would mean that if the performance
> monitoring function is at the frame error level, it may not be 100%
> accurate.  Is that correct?
> 
> Thank you,
> Roy Bynum
> 
> At 11:54 AM 3/6/2002 -0800, you wrote:
> 
> > > Hello,
> > > Refer 4.2.9 section for frame reception in 802.3 2000.
> > >
> > > The LayerMgmtReceiveCounters  procedure is called when the receive frame
> > > succeeding is OK i.e the RecognizeAddress  procedure passes.
> > > The aFrameCheckSequenceErrors (refer section 5.2.2.1.6) is updated in
> > > the LayerMgmtReceiveCounters procedure.
> > >
> > > How is the counter update for FCS counter accounted, in the case of  FCS
> > > error due to Address corruption ?
> >
> >
> >A frame that encounters an error in the address field is not counted as a
> >CRC error. It is rejected by the receiver as a frame that was not addressed
> >to this station. The reason for that is that the receiver only counts errors
> >in frames that were sent to it, and it has no way of knowing where in the
> >frame the error ocurred.
> >
> >                                                 Shimon.